I’ve run into a serious snag trying to debug a .NET 2.0 assembly that is called from unmanaged code in Visual Studio 2010. I maintain a host of components that using COM interop and custom .NET runtime hosting and ever since installing Visual Studio 2010 I’ve been utterly blocked by VS 2010’s inability to apparently debug .NET 2.0 assemblies when launching through unmanaged code.
Here’s what I’m actually doing (simplified scenario to demonstrate):
- I have a .NET 2.0 assembly that is compiled for COM Interop
- Compile project with .NET 2.0 target and register for COM Interop
- Set a breakpoint in the .NET component in one of the class methods
- Set debugging to point at unmanaged application (Visual FoxPro dev environment in this case)
- Instantiate the .NET component via COM interop and call method with breakpoint
The result is that the COM call works fine but the debugger never triggers on the breakpoint.
If I now take that same assembly and target .NET 4.0 without any other changes everything works as expected – the breakpoint set in the assembly project triggers just fine. So it appears the debugging failure is specific to .NET 2.0 debugging.
The easy answer to this problem seems to be “Just switch to .NET 4.0” but unfortunately the application and the way the runtime is actually hosted has a few complications. Specifically the runtime hosting uses .NET 2.0 hosting and apparently the only reliable way to host the .NET 4.0 runtime is to use the new hosting APIs that are provided only with .NET 4.0 (which all by itself is lame, lame, lame as once again the promise of backwards compatibility is broken once again by .NET). So for the moment I need to continue using the .NET 2.0 hosting APIs due to the application requirements and runtime availability.
I’ve been searching high and low and experimenting back and forth with the hosting options, posted a few questions on the MSDN forums but haven’t gotten any hints on what might be causing the apparent failure of Visual Studio 2010 to debug my .NET 2.0 assembly properly when called from un-managed code. Incidentally debugging .NET 2.0 targeted assemblies works fine when running with a managed startup application – it seems the issue is specific to the unmanaged code starting up.
Curious if anybody has any ideas on what could be causing the lack of debugging in this scenario?
Incidentally the VS2010 install also killed debugging for me in VS 2008. Running the same project and trying to launch the debugger from the .NET 2.0 assembly project results in Invalid Debugger Target. Really? Oh yeah, the promise of side by side installations – for the .NET runtime AND Visual Studio really are working out great. Not!
