The other day I got a question about how to start a process under the debugger and there are quite a few different ways to do that. I thought I’d discuss them all because the information about how to do each of these is scattered around various spots in the Visual Studio documentation. As the title says, this article is about starting processes, if you want to attach to processes in Visual Studio that’s a matter of the Debug, Attach to Process, or Tools, Attach to Process menu items. Finally, these techniques work for both managed and native development.
Obviously, if you have a single console or GUI program (i.e. not a service application), you know that pressing F5 will debug your process, which is the simple case. Things get a little more interesting if you have a DLL-type project, such as a class library or COM object. Say for example you are working on a MMC Snap-in written in C#, which means your code runs inside the Microsoft Management Console (MMC.EXE). To set up debugging for your DLL, you’d go to the project properties, Debug tab, and choose the “Start external program” button and enter “C:Windowssystem32mmc.exe” as the program to debug.
If you had the opposite situation where you have a native DLL project that loads into a managed EXE, in the project properties for the native DLL, you’d navigate to the Configuration PropertiesDebugging node. In the Command edit control you would type the complete name to the managed EXE that loads your DLL. Since you’ve got both managed and native code in the same process, you’ll also want to set the Debugger Type field to “Mixed” so you can single step between managed and native. Now that Visual Studio 2010 has full x64 mixed debugging support, there’s no excuse not to upgrade.
Where things get much more interesting is if you have a two EXE processes that you need to debug. Let’s say I have a client/server solution that’s got those two EXEs and I need to debug the startup of both of those projects. What I’ve seen most people do to accomplish this is open up two instances of Visual Studio, one for each project, and press F5 in both. That works, but there’s a hidden trick in Visual Studio where you can put both EXE projects in the same solution. After combining the two projects in the solution, right click on the Solution and select Properties.
In the Solution Property Pages dialog, navigate to the Common PropertiesStartup Project node. The default option selected will be the “Single startup project.” The trick is to select the “Multiple startup projects:” radio button and for each project, set the Action to Start for all projects.
Note that the default action for multiple EXE projects is None so other than the non-selected project in the Solution Explorer won’t run. As you can see from the dropdown above, you can choose to start the project without debugging so your client or server won’t stall.
As the multiple start option is a solution level option that means your settings are saved to the hidden .SUO file in the same directory as the solution itself. If you delete the .SUO file, you’ll need to go update the solution options to have the multi process startup execute your multiple EXE programs.
For a final bonus tip, what if you have the situation where one of the processes you need to ensure is started you don’t have the source for like a program from a third party or Microsoft? You can still start the other program with your particular EXE project, by right clicking on your solution, selecting Add, Existing Project from the context menu. In the Add Existing Project dialog, browse to the directory with the particular EXE file, select the EXE file, and click the Open button. In the screen shot below I’ve added NOTEPAD.EXE as a third EXE file.
With that EXE added you can treat it just like one of your projects in the Solution Property Pages dialog as I’ve shown above.
Ladies and gentlemen, go start your EXEs! As always, let me know if you have any questions.