If you're going to build enterprise solutions, some of your assemblies are bound to be hosted by other applications. A huge part of knowing how to code is having good debugging skills, but hosted assemblies can be challenging to debug unless you know that Visual Studio .NET supports debugging hosted applications by attaching to the host directly. This tip from InformIT, explains how to debug hosted applications.
Attaching to the Host Application
Our focus is on testing the serviced component rather than the client application. To accomplish the testing with the client and service in the same assembly, we can set the client as the startup project but start without debugging by selecting Debug, Start Without Debugging. This step will start the client, leaving the debugger available to debug the hosted application.
After the client is running, click the button in the application to create and load an instance of the host process, dllhost.exe. When the host process is running, we can use the available integrated debugger—because we started the client without debugging—and attach the debugger to the host process. To attach to the host process, follow these steps (using the associated figures as a visual guide):
- Select Debug, Processes to display the Processes dialog box.
- Navigate to the dllhost.exe process, click it, and click the Attach button.
- In the list called Choose Program Types That You Want To Debug, check only the Common Language Runtime option, and click OK.
- Click the Close button in the Process dialog box. The dllhost.exe host will be shown in the Debugged Processes list in the Processes dialog box.
You may run into a bit of trouble if several instances of your host are running. For example, if an instance of dllhost.exe is running on behalf of some other, non-managed service, you'll get an error indicating that the host needs to be running managed code to debug with the .NET debugger. Additionally, if you select more than the Common Language Runtime option—for example, if you select Native—the debugger takes a lot longer to load.
After you've attached to the host process and have clicked Close, the integrated environment will load the required assemblies and modules needed to debug your hosted application. In our example, these will be the binaries needed to support the LuckyNumberGenerator.
Debugging and Testing Your Hosted Assembly
After the debugger has attached to your assembly's host application, you can debug in .NET as you would debug anything else. You can set breakpoints and watches; examine the stack or memory; view and switch between threads, if applicable; and use the Immediate/Command window to run and explore code while in break mode.
To try out debugging a hosted assembly, set a breakpoint in the GetLuckyNumber method in the service. Switch focus to the client and click the button we placed in the form. If everything is pieced together correctly, the IDE will break at the point you indicated.
At this point, you can perform any of the operations you might normally perform when debugging an executable or DLL that's not hosted by another process.
Finished Debugging?
When you're finished debugging, you can select Debug, Stop Debugging or Debug, Detach All. Selecting Stop Debugging may kill the host process. If you want to continue running the host application, attach to another host, or attach another service to the same host, select Detach All, which will detach the debugger from the host, leaving the host intact.
You can prevent the IDE from killing the host process by changing the When Debugging Is Stopped option. If you want the host to terminate when debugging stops, select Terminate This Process. If you want the host to remain intact, select Detach from This Process.
Read more about the creating COM+ serviced components in the complete article at InformIT.
