How to debug component written in VS2003 in a VS2005 application

[HairlipDog58]

I have a component that was developed in VS2003 that I need to debug in a
VS2005 application.

Basic steps are:

Build the component for Debug in VS2003.
Set the following VS2003 project properties for the component:
Project > Configuration Properties > Debugging > Debug Mode = Program
Project > Configuration Properties > Debugging > Start Application = <path
to application built in VS2005>

When I select Menu > Debug > Start, I get the following message:

Error while trying to run project: Unable to start debugging
Unable to start program 'c:\<path to application built in VS2005>'

Same setup works fine if a VS2003 application is specified for Start
Application.

Any ideas?

 

[Jon Skeet [C# MVP]]

I have a component that was developed in VS2003 that I need to debug in a
VS2005 application.

Basic steps are:

Build the component for Debug in VS2003.
Set the following VS2003 project properties for the component:
Project > Configuration Properties > Debugging > Debug Mode = Program
Project > Configuration Properties > Debugging > Start Application = <path
to application built in VS2005>

When I select Menu > Debug > Start, I get the following message:

Error while trying to run project: Unable to start debugging
Unable to start program 'c:\<path to application built in VS2005>'

Same setup works fine if a VS2003 application is specified for Start
Application.

Any ideas?

Why don't you just debug in VS2005, but still debug the component which
happens to have been built in VS2003? That should work fine - but
VS2003 won't be able to interact with the v2 CLR.

 

[HairlipDog58]

I need to set breakpoints in the VS2003 component, not the VS2005 application.

 

[Jon Skeet [C# MVP]]

I need to set breakpoints in the VS2003 component, not the VS2005 application.

Yes, but you can still do that in VS2005. Just load up the source file
for the VS2003 component, set the breakpoint, and run.

 

[HairlipDog58]

That's what I'm doing, but it's clunky.

If I hit a breakpoint and find that i need to make a change in the
component, you need to switch over to VS2003, make change, rebuild, then
rebuild VS2005 project and run.

Why does VS2003 care what type of application it is being told to run?

In VC++ 6 you can run any type of app from the debugger.

 

[Jon Skeet [C# MVP]]

That's what I'm doing, but it's clunky.

If I hit a breakpoint and find that i need to make a change in the
component, you need to switch over to VS2003, make change, rebuild, then
rebuild VS2005 project and run.

That doesn't sound *very* clunky. You can easily have both apps open.

Why does VS2003 care what type of application it is being told to run?

Because it needs to instruct the CLR with debugging instructions,
understand the IL etc.

In VC++ 6 you can run any type of app from the debugger.

Can you debug an ARM executable from the debugger, without a specific
emulator? That's close to what we're trying to do here. The virtual
machine it would be launching (CLR v2) has some different instructions
which VS2003 doesn't understand, and wouldn't be able to cope with.

What's more annoying is that VS2005 won't let you (easily) build a 1.1
application. That really *could* have been handled better, admittedly
with significant work. Fortunately VS2008 allows targetting of .NET
2.0, 3.0 and 3.5 (which is easier as they all use the same CLR).

 

[HairlipDog58]

Ok, so the answer is that I need to switch back and forth between compilers,
correct?

I guess I'm spoiled. Since I can launch a VS2003 or VS2005 app from VC++ 6.0
to debug an ActiveX Control in a .NET application, I expected the same from
VS.NET.

Thanks for the info.

 

[Jeffrey Tan[MSFT]]

Hi,

Thanks for your feedback. I see your concern.

Actually, .Net debugging is a bit different from the Win32 native code
debugging. Win32 native code debugging uses the debugging API of the
Windows OS, while .Net debugging uses the debugging service of the
underlying CLR instead of the OS. Internally, there is a dedicate debugger
thread running in the CLR(also in every .Net process) for debugging
purpose. The debugger team chooses this design to improve performance(the
debugger thread runs in the same process of the debuggee) of the debugging
and many other reasons. If you are curious, please refer to the links below:
"Implications of using a helper thread for debugging"
http://blogs.msdn.com/jmstall/archive/2004/10/13/241828.aspx

So every .Net debugger(except windbg) needs the support of the CLR debugger
thread for debugging. This means that the debugger is CLR dependent. When
the VS.net2003 debugger is released, the CLR2.0 is not released yet, so the
VS.net2003 debugger can not debug .Net2.0 application. We have to use a
newer debugger.

Regarding VC6.0 debugger, it only deals with the pure native code; it only
needs the support of the underlying OS and CPU. So far as we are using
Windows and the x86 compitable CPU, the debugging experience is the same
regardless of the compiler is VC++ 6.0, 2003, 2005 or 2008. For the VC
native debugger, all it sees is x86 binary machine code. Even if you are
debugging an .Net application from the VC6.0 debugger, it just deals with
the JITed machine code instead of .Net code, it needs no support of the
CLR. For example, you may use VS.net2003 debugger to attach a .Net2.0
application using pure native debugging. This will eliminate the support
from the CLR.

Finally, using windbg+SOS.dll for managed or interop debugging works on all
Net versions, since it is a pure native debugger while uses SOS.dll to
understand the CLR internal structures. You only need to load correct
version of SOS.dll for targeting CLR version.

Hope this helps.

Best regards,
Jeffrey Tan
Microsoft Online Community Support

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Jeffrey Tan[MSFT]]

Additionally, I am not sure if I have understood you completely. Since you
have the VS2005 tool, why can't you just re-build your VS.net2003 component
in VS2005 compiler and IDE? .Net2.0 has good forward compatibility of
..Net1.1, so your VS.net2003 component shoud run without any problem after
compiling under VS2005.

Thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
=========================================
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).

This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Jeffrey Tan[MSFT]]

Hi,

Have you reviewed my last replies to you? Does it make sense to you? If you
need any help or have any concern, please feel free to tell me, thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
=========================================
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).

This posting is provided "AS IS" with no warranties, and confers no rights.