COM+ Programming with Visual Basic

Debugging COM+ Applications

Because the Visual Basic 6 debugger is very limited, debugging COM+ applications is not a trivial task. The biggest limitation is that the debugger cannot attach itself to a running process; it only knows how to debug code that is being interpreted and running under the VB 6 process. This means that you cannot debug COM+ server applications in Visual Basic, since these applications run inside DllHost.exe. A second limitation is that it can debug only single-threaded processes, which means that you cannot debug things like the STA thread pool. Note that you can debug all these things using the Visual C++ debugger. Therefore, one option for debugging VB COM+ code is to use the Visual C++ debugger, which is discussed as the second of the following debugging options; another option is to use trace messages by calling the Win32 OutputDebugString API.

Option 1: Use the VB Debugger

VB offers you limited debugging support for COM+ applications by simulating a COM+ library application environment. In order to offer you debugging support, VB does the job of DllHost.exe and acts as a surrogate process. Because VB treats your application as if it were a library application, debugging support is limited to features for library applications—you cannot debug server-only application features (see Chapter 7 for a complete list of server-only services). You also cannot debug the way your objects are created in different threads. This means that if you mark a component ...