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?Read more: Rick Strahls Weblog
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?Read more: Rick Strahls Weblog
Posts
0 comments:
Post a Comment