Debugging Interoperable Components

There does not appear to be a direct way to simultaneously debug both COM and .NET source code at the same time. However, you can debug .NET-to-COM and COM-to-.NET Interop relationships by debugging the library and using the client as the hosting application. For example, if you want to debug a COM library that is being consumed by a .NET client, you can debug the COM client by using the .NET client as the hosting application. Similarly, you can debug a .NET library by using the COM client as the hosting application.

Debugging a COM Library by Using a .NET Host

For example, suppose we want to debug the Address.cls class defined in AddressProject.vbp (VB6). This is a class library. We can't run the class library unless we do so in the context of a hosting application. Let's say we just happen to have the VB6.ConsumeEvent.exe , a .NET client that consumes instances of AddressProject.Address objects. To debug the Address class in VB6 using the .NET host, we would follow these steps.

1. Start VB6.

2. Open the AddressGroup.vbg project group in VB6.

3. In VB6, select ViewProject Explorer.

4. Click on AddressProject. Right-click the project and select Set as Start Up.

5. Right-click again and select AddressProject Properties.

6. Still in VB6, in the Project Properties dialog (Figure 7.10), click the Debugging tab.

   Figure 7.10. The Project Properties dialog can be used to indicate host applications for debugging libraries, which works with COM Interop too.

   

7. Select the Start radio button and browse to the VB6.ConsumeEvent. exe .

8. Click OK.

9. Press F5 to begin debugging.

If you follow the steps above to begin debugging the VB6 COM library, you will see the host application start up. Set breakpoints in the COM library code ( Address.cls ) so that when the host application calls into the COM source, the VB6 debugger will stop on those breakpoints. Unfortunately, you can see only one side of the COM Interop relationship at a time, but you can successfully debug both client and server in this manner.

To debug both the COM component and the .NET assembly at the same time, specify the VS .NET IDE ( devenv.exe ) as the startup host program and the solution file ( .sln ) as the parameter. For example, in VB6 set the start program to C:\Program Files\Microsoft Visual Studio .NET\Common7\IDE\devenv /run c:\ solution .sln . When you start the VB6 project, the VS .NET IDE will start, loading and running the .NET solution too, resulting in debug control over both the VB6 COM code and the VS .NET code.

Debugging a .NET Library by Using a COM-Based Host

Suppose now that we have a .NET library with types exposed to COM. We could test the .NET library with a COM host by opening the .NET library and attaching the debugger to the COM-based client host. To try debugging a .NET library from a COM host, follow these steps.

1. Start Visual Studio .NET.

2. Open TemperatureConverter.sln .

3. Start the ImportedFromDotNet.exe client application that we implemented in VB6.

4. Go back to Visual Studio .NET.

5. Select DebugProcesses.

6. In the Processes dialog, select ImportedFromDotNet.exe .

7. Click Attach.

8. Click OK in the Attach to Process dialog.

9. Click Close in the Processes dialog.

10. Still in Visual Studio .NET, set some breakpoints in the Converter class.

11. Select DebugStart.

When you interact with the COM host and request something from the .NET server that hits one of your breakpoints, the .NET IDE will pause execution at that breakpoint. You can inspect and evaluate your .NET library as if it were any other running code. Again, you are not debugging COM-based and .NET code simultaneously, but this will get the job done.

I experimented with trying to get the debuggers to bounce back and forth. Perhaps this is possible or will be made to work in the future. For now it appears as if we will have to debug the pieces separately when using COM Interop. The good news is that ideally you are using only well- tested and debugged COM code and not writing any new COM code. If so, the debugging chore should be relegated to debugging the new .NET code only.