Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > ASP .Net > How do I debug COM+ objects?

Reply
Thread Tools

How do I debug COM+ objects?

 
 
DJ Miller
Guest
Posts: n/a
 
      08-17-2003
If I put an assembly in COM+ (and the GAC, apparently an essential part
although I can't fathom why it has to be registered in TWO centralized
catalogs, but I digress), I am unable to step through the code. Why? In
VB6 this was trivial; I could open the source code for a COM+ object, select
"Run", and whenever that object was called, it would step through the
running VB6 instance. VB.Net won't allow me to start an object without
specifying some start project, and even if I have said COM+ source code in
the same solution as a start project, when the object is called, it calls
the COM+ compiled version ignoring the source code (can't step into it,
can't set breakpoints in it). What's up with this?

I've been told I have to attach to the DLLHost process to get it to work
<insert rant about how I never had to do that with VB6 here>, but it's not
working. I start my test application and have a break right after the
component is created (so that I can get a process to attach to). I go to
Debug, Processes, and attach to the DLLHost process that corresponds to my
object (matching process IDs with what's displayed for that application in
Component Services). I have a list of options for debugging (CLR, T-SQL,
and Script -- I choose CLR). Then I hit "Step Into" as it calls a method on
that object. (I've put stops in the component, and have it throwing an
ApplicationException, to try to force an issue to kick off the debugger.
Nothing happens, except that ApplicationException gets caught by the test
app. I never see the component's code.




 
Reply With Quote
 
 
 
 
DJ Miller
Guest
Posts: n/a
 
      08-18-2003
For anyone who might be having this problem (hey, maybe it's only me), I
think I figured it out.

Step 1: Compile objects.
Step 2: Register the debug objects in the GAC (objects in <project
path>\obj\Debug\) -- this is important, because even though <project
path>\bin\ also contains an exact duplicate, only the one in obj\Debug\
works, I'm guessing because the .pdb debug file is there and isn't copied to
bin\
Step 3: Open the executable and the source code for the object. Set a
break point in the object's code.
Step 4: Run the project, with a breakpoint where the first COM+ object is
created (right after creation, actually).
Step 5: Open Component Services to verify the object got registered in
there (I'm using lazy registration for now, since at this point there are
three identical .dll files floating around and I'm not entirely certain
which one's key -- maybe obj\Debug\, but it might be
C:\WinNT\assembly\gac\<object name>\<strong name>\ -- in theory, in future
iterations, since the object will already be in COM+, I could skip setting a
breakpoint on its creation and manually start the COM+ app in Component
Services), and check which PID corresponds to the application you want to
debug.
Step 6: Debug menu, attach to the DLLHost process with the same PID.
Step 7: Step through the code. Even though you may say "Step Into" when
making the COM+ call, it won't step until it hits a breakpoint.
Step 8: Beware of creation of other COM+ objects. For some reason, I
noticed one point in my code created a new object, and when I hit F11 to
step through that step, the code then took off and ran to completion; I had
to set a breakpoint immediately after this object creation step to catch it
again.

I am noticing some interesting bits, too. I had two COM+ objects in
particular, registered under two COM+ applications (and therefore with two
different PIDs), and I did the above procedure with a mondo solution file
that contained all my objects. I then closed that and opened a solution
file that had my test application and one *other* COM+ object. Just for
kicks, I set the debugger to debug both the PID of this COM+ object and the
former COM+ object (whose source I did not have loaded), and the execution
stopped and let me step through the code of the other COM+ object from where
I had previously set a breakpoint. ::shrug::

There may be an easier way, but this is working for me. Sure wish I had
some help figuring it out, though, as I'm having to spend precious
development time just trying to set things like this up.

"DJ Miller" <(E-Mail Removed)13> wrote in message
news:ecHgp$(E-Mail Removed)...
> If I put an assembly in COM+ (and the GAC, apparently an essential part
> although I can't fathom why it has to be registered in TWO centralized
> catalogs, but I digress), I am unable to step through the code. Why? In
> VB6 this was trivial; I could open the source code for a COM+ object,

select
> "Run", and whenever that object was called, it would step through the
> running VB6 instance. VB.Net won't allow me to start an object without
> specifying some start project, and even if I have said COM+ source code in
> the same solution as a start project, when the object is called, it calls
> the COM+ compiled version ignoring the source code (can't step into it,
> can't set breakpoints in it). What's up with this?
>
> I've been told I have to attach to the DLLHost process to get it to work
> <insert rant about how I never had to do that with VB6 here>, but it's not
> working. I start my test application and have a break right after the
> component is created (so that I can get a process to attach to). I go to
> Debug, Processes, and attach to the DLLHost process that corresponds to my
> object (matching process IDs with what's displayed for that application in
> Component Services). I have a list of options for debugging (CLR, T-SQL,
> and Script -- I choose CLR). Then I hit "Step Into" as it calls a method

on
> that object. (I've put stops in the component, and have it throwing an
> ApplicationException, to try to force an issue to kick off the debugger.
> Nothing happens, except that ApplicationException gets caught by the test
> app. I never see the component's code.
>
>
>
>



 
Reply With Quote
 
 
 
 
cod_ferrow cod_ferrow is offline
Junior Member
Join Date: Oct 2011
Posts: 1
 
      10-17-2011
I actually created an account here to thank you for posting this. It has helped me quite a lot.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
netvmini.sys still not working on Windows 7 even after driver signing disabled ?! (Windows debug mode necessary for debug drivers ???) Skybuck Flying Windows 64bit 3 08-09-2009 05:54 AM
debug="false" in web.config and <%@ debug="true" ...%> in aspx file => true or false? André ASP .Net 3 08-28-2006 12:02 PM
Config Mgr Debug/Release and Web.config Compilation debug=true RonL ASP .Net 0 04-08-2006 03:50 PM
Debug (DLL MFC) -> Debug (Static MFC) ringos75 C++ 0 04-14-2005 01:50 PM
[Howto] Compiling debug Python extensions for non-debug Python Mike C. Fletcher Python 3 10-12-2003 09:37 PM



Advertisments