Debugging an ATL COM object in VB.NET

[Simon Jefferies]

Hello,

I've created an ATL component in C++, but wish to debug it when its called
from .NET. I've placed it on a form and have set the component as the
startup project. But the breakpoints never get called.

TIA
Cheers
Simon

--
Regards
Simon Jefferies
Tools Programmer, Headfirst Productions
mailto:[email protected]
-

 

[Scott]

The first thing to do is to make sure that both projects are set to "Debug"
mode. However, this may not be the problem. I had some similar problems
trying to debug an ATL component in Visual Studio, but mine usually involved
the VB.NET application crashing when I tried to debug the application with
the ATL component. You can debug only the ATL project by using one of the
following methods.

1. Launch the VB.NET executable and then from the ATL project choose
Debug --> Process, find the VB.NET executable and choose "Attach". You can
then debug the ATL component whenever it's methods are called.

2. From the ATL component project, choose Project --> Properties. From the
tree at the left choose Configuration Properties --> Debugging. For the
"Command" property on the right, enter the path to the VB.NET executable.
When you press "F5" to debug the ATL project, the VB.NET executable will be
launched and you can debug the ATL component.

 

[Simon Jefferies]

Thanks for your reply, the method I have been using is your method [2] but
this doesn't appear to work in my case. I have toggled the debug unmanaged
code check box as well, but didn't help.

--
Regards
Simon Jefferies
Tools Programmer, Headfirst Productions
mailto:[email protected]
-

 

[Yan-Hong Huang[MSFT]]

Hi Simon,

Based on my understanding, now the problem is: You are developing a ATL
component in VC 6.0 and a VB.NET client in .NET. Now you want to debug this
ATL component from VB.NET, right?

In VS.NET, you can debug managed and native code by going to your project's
properties page (right click on your project in solution explorer). From
there, select configuration in the left pane, and then debugging. In the
right pane set "Enbable Unmanaged Debugging" to True. (You probably already
have ASP.NET debugging enabled unless you're manually attaching to
inetinfo.exe). With this enabled, you can step from your VB.NET code to
your ATL DLL and back again. You need to make sure you have full remote
components installed on the machine you're debugging (if it's a remote
machine).

Please note that the call to ATL from VB.NET client is done on same
thread. if the call is invoked between two different thread, "step into"
does work like "step over". it is currently by design.

For details on it, you can also refer to this newsgroup thread:

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=uyVB4Xwv
BHA.1652%40tkmsftngp03&rnum=9&prev=/groups%3Fhl%3Den%26lr%3D%26ie%3DUTF-8%26
oe%3DUTF-8%26q%3Ddebug%2Bunmanaged%2Bcode%2BATL%26sa%3DN%26tab%3Dwg

Does that answer your question?

Best regards,
Yanhong Huang
Microsoft Community Support

Get Secure! ¨C www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Simon Jefferies]

Thanks for your reply,

I have written the (C++) ATL component in .NET 2003. I have one solution
that contain the component project and the VB .NET project.

I have tried the Enable Unmanaged Debugging option checked.

I am trying to enter the ATL component code, it doesn't go inside or hit a
breakpoint. I have tried both VB and ATL component as the startup project,
but doesn't make any difference.

Is there anything else I can try?

--
Regards
Simon Jefferies
Tools Programmer, Headfirst Productions
mailto:[email protected]
-

 

[Scott]

I did a little more testing with the project I had been using and finally
managed to step back and forth between the projects. I'm using VS 2002 with
both projects in a single solution and set to debug mode. I had to run the
executable without debugging (Ctrl + F5) and then choose Debug --> Processes
from the main menu. When you find the running process click "Attach" and
then be sure to choose both "Common Language Runtime" and "Native" from the
"Choose the program types you want to debug" list. Of course this is an ATL
dll and I'm using VS 2002 so it may be different or may not work for you.
Plus it seems to run very slowly taking several seconds to step from one
line of code to the next. It's something to try though.

 

[Simon Jefferies]

Cheers for the info,

I've just tried my project with Whidbey Community version thats available in
MSDN subscriptions, and the debugging works now!

I was trying to get it to run under .Net 2003 previously so not sure whats
happening there. I didn't try anything different settings etc.

--
Regards
Simon Jefferies
Tools Programmer, Headfirst Productions
mailto:[email protected]
-

 

[Yan-Hong Huang[MSFT]]

Hi Simon,

And so the problem is resolved, right?

The steps seems right already, since I have used it for a long time. It
seems something wrong in the installation of debug component.

Thanks very much for participating the community.

Best regards,
Yanhong Huang
Microsoft Community Support

Get Secure! ¨C www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Simon Jefferies]

H,

I've resolved it by upgrading my project to the Whidbey release.

With regards .NET 2003 I am concerned that I might not be able to debug any
other COM components as mentioned in my posts earlier. Is there any
information relating to fixing this issue as in "installation of the debug
component"?

Best Wishes
Simon

--
Regards
Simon Jefferies
Tools Programmer, Headfirst Productions
mailto:[email protected]
-

 

[Yan-Hong Huang[MSFT]]

Hi Simon,

You can try repairing VS.NET 2003 first. The ways that we introduced,
including "attaching to process" and "stepping into ATL COM component
directly" are OK for VS.NET 2003.

Anyway, I am glad that you can work on the project now. If there is any we
can do for you, please feel free to post here.

Best regards,
Yanhong Huang
Microsoft Community Support

Get Secure! ¨C www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.