How do I debug COM+ objects?

Discussion in 'ASP .Net' started by DJ Miller, Aug 17, 2003.

  1. DJ Miller

    DJ Miller Guest

    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.
    DJ Miller, Aug 17, 2003
    #1
    1. Advertising

  2. DJ Miller

    DJ Miller Guest

    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" <13> wrote in message
    news:ecHgp$...
    > 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.
    >
    >
    >
    >
    DJ Miller, Aug 18, 2003
    #2
    1. Advertising

  3. DJ Miller

    cod_ferrow

    Joined:
    Oct 17, 2011
    Messages:
    1
    Much appreciated

    I actually created an account here to thank you for posting this. It has helped me quite a lot.
    cod_ferrow, Oct 17, 2011
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. RonL
    Replies:
    0
    Views:
    731
  2. ringos75
    Replies:
    0
    Views:
    943
    ringos75
    Apr 14, 2005
  3. Mike C. Fletcher
    Replies:
    3
    Views:
    970
    =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=
    Oct 12, 2003
  4. André
    Replies:
    3
    Views:
    1,562
  5. 7stud
    Replies:
    11
    Views:
    674
    Dennis Lee Bieber
    Mar 20, 2007
Loading...

Share This Page