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 the method with a 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  - it’s as if .NET is debugging the wrong runtime version and so failing to see the .NET 2.0 breakpoints.

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.

[updated 6/8/2010 with feedback from comments]

The Solution – provide a Runtime Hint

Thankfully David in the comments pointed at an MSDN forum post in the comments that addresses the problem. The issue is that the debugger needs to decide which version of the .NET runtime to use before the runtime is loaded. IOW, the debugger has no way to guess what version you are actually loading and so it loads the latest version.

The workaround to this problem is to temporarily provide a hint in the form of a .config file. In my test scenario I’m testing in the Visual FoxPro dev environment (vfp9.exe) and so I can create vfp9.exe.config in the install directory and specified the desired runtime load order (depending on availability on the machine):

<?xml version="1.0"?>
<configuration>
   <startup>
     <!--supportedRuntime version="v4.0.30319"/-->
     <supportedRuntime version="v2.0.50727"/>
     <supportedRuntime version="v1.1.4322"/>
     <supportedRuntime version="v1.0.3705"/>
   </startup>
</configuration>

To debug .NET 2.0 I have to explicitly set the  2.0 .NET runtime as highest version in the list. Originally I had added V4 to the list because I do actually want to allow V4 to be found and loaded by some of my applications. The debugger uses the config file as a hint to decide which runtime version to attach to when managed code fires up.

Note that on my machine having all those runtime versions in the config is not really necessary since I know the latest is there. But on deployed apps having a list of runtimes like above can be helpful in forcing the highest available version to load. Oddly it looks like some of the runtime hosting APIs like CorBindRuntimeEx() no longer respect these settings with .NET 4.0 when no explicit runtime version is specified and they fail to load the highest runtime version instead using 2.0. <shrug> There are new hosting APIs which kind of defeats the ability to specify version numbers since .NET 2.0 installs don’t have those new APIs.

The above config settings fixes my problem above nicely, although I’m pretty sure I will forget this in the future and hit this issue again - maybe this post will help me jog my memory or at least find it in a search. Love my blog as a crutch :-)