Velocity Reviews - How do I debug COM+ objects?

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" <qzvyyre@n-1erybpngvba.pbz.ROT13> wrote in message
news:ecHgp$IZDHA.2284@TK2MSFTNGP10.phx.gbl...
> 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.
>
>
>
>