Click here to Skip to main content
13,356,787 members (61,304 online)
Click here to Skip to main content
Add your own
alternative version


21 bookmarked
Posted 19 Jul 2007

Debugging COM+ Applications (Part II)

, 19 Jul 2007
Rate this:
Please Sign up or sign in to vote.
How to debug COM+ components from ASP, ASP.NET and test project


Debugging is what probably takes most of the developer's time. That doesn't mean that I introduce too many bugs, rather mostly debugging is required for code enhancements, business development or transition to new technology. As this is part II of .NET and COM+, we will focus on the debugging aspect.


In the first part, I have explained how to use .NET COM+ components with ASP applications.

Jump In

There are many ways to debug these days and everybody chooses tools based on their own preference and comfort level. Visual Studio 2005 had opened another new way to debug without leaving Studio. It is not really new and very similar to nUnit open source code.

In process libraries are easy to debug as code runs in the same process and step into (or F11 function key) can take you inside the server side code. With components, there are many confusing options like debug with devenv or iexplorer, etc. or attach to which process in process list.

Let's look at the various options available to debug .NET server component and how to debug the component.

Test Project

Test project is a very cool way to debug without getting out of Studio and is available in Visual Studio 2005. Open your solution and right click on solution and choose add new project. Select project type as test project and you will see a test class is added to the test project with a test method. You can add your test code here and I'll suggest at least one test method for each method of the component you would like to test.

The test method typically has some parameter initialization, followed by lines to create the object of the class and the call to the method of the class.

In case your component is started, you can select the component to debug by clicking on debug menu and then selecting Attach to Process option as shown in the figure below. You have the option to select checkboxes to see all processes for all users and all processes in all sessions and if you are debugging your own session, then you can uncheck both checkboxes.

Screenshot - AttachDebug.jpg

Screenshot - AttachProcess.jpg

The list of processes running will appear. Select the dllhost.exe entry for your component, if you are not sure of your component process the open component services and under running processes you will see your component with process id. If the component has not started, then it will not appear in the running processes, in that case start the process in COM+ Applications by right clicking on the component and then select start. I'll leave the dllhost.exe for another day to explain and you need to know that your component is hosted in dllhost.

That's it, open your server component project and set the breakpoints. From the test explorer window, select the test method and click debug method.

I sometimes wait till createobject creates the object for attaching to a process because by this time, the component is started and you can see the process in the process list.

Another option to debug is by creating a test/real Web Application: Sooner or later you want to test with Web application to test integration or routine maintenance.

The process here is similar to the test project and if you have ASP.NET application, the process is exactly the same as the test project; both are .NET projects so the debugging is the same.

If you have Visual Interdev 6.0 project, you can still attach to a process by clicking on Debug menu and select Processes… option.

Here is the scoop. You can open Visual Interdev 6.0 solution with Visual Studio 2005, there are few easy steps and I hope most of you can figure it out, otherwise put your request in and I'll be happy to put it together. It's so much better to use Visual Studio 2005 with ASP application and you can use VSS (or try Team System source control).

I mostly work with Visual Studio 2005 and what I remember is that debugging with Visual Studio 2003 should be the same. Let me know if there is something that I am missing.


  • 19th July, 2007: Initial post


This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


About the Author

United States United States
I am a software architect/developer, having 15 years of design/development experience. Currently working in large financial corporation, architecting .NET applications and coding using C#, ASP.NET, Java Script etc..

MS Computers, MCP, MCTS: .NET Framework 2.0 Web Applications.

You may also be interested in...


Comments and Discussions

GeneralGood word. Pin
yulinxie24-Oct-10 3:28
memberyulinxie24-Oct-10 3:28 
Questiondoes this work in windows 2008 x64 with VS 2008?? Pin
niqing16-Apr-09 8:21
memberniqing16-Apr-09 8:21 
QuestionVS edition Pin
jhexp10-Aug-07 8:56
memberjhexp10-Aug-07 8:56 
AnswerRe: VS edition Pin
tomcat119-Oct-07 6:58
membertomcat119-Oct-07 6:58 
well, the information is provided on top right corner of the article.


General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

Permalink | Advertise | Privacy | Terms of Use | Mobile
Web03 | 2.8.180111.1 | Last Updated 19 Jul 2007
Article Copyright 2007 by tomcat1
Everything else Copyright © CodeProject, 1999-2018
Layout: fixed | fluid