So here’s some oddity in COM Interop. I have an Interop Assembly that I built: The wwReflection class that I use in Help Builder to retrieve all type info for .NET type parsing. It's a class wrapper around Reflection to parse .NET objects into more easily consumable and pre-parsed objects members that can be accessed via COM interop, because Reflection is not easily accessible that way. Today I decided I need to change the way this class works by using a separate AppDomain to load the assemblies so that I can unload them when the parsing is done. If this isn’t done, the Assemblies stay loaded which means that if you’re working on these assemblies while you’re developing with them they won’t recompile. Obviously not a good thing... Loading AppDomains is always tricky business so I needed to debug the code to see why the Assembly wasn’t loading properly into the AppDomain.

So, I’m doing COM interop with Visual FoxPro and I’m unable to debug my .NET COM object. Normally this is a snap – you select your .NET assembly project, add Debug Program, point at the Executable (VFP9.EXE) and the start directory, press F5 to run and off you go.

Unfortunately not today. Everytime the object gets instantiated .NET shuts down VFP and the running assembly. Sorry, no debugging for you!

Yet if I run the code on its own (assuming the code works) it works fine. I always add a method to my COM interop components that give me a tiny bit of information about the environment:

public string GetVersionInfo()

{

      return Environment.Version.ToString() + "\r\n" + Assembly.GetExecutingAssembly().CodeBase+ “\r\n“ + Directory.GetCurrentDirectory();

}

and low and behold it turns out that .NET is loading V 2.0 of the .NET runtime, not V1.1.4 which it should be using.

A quick check in the registry for the COM object correctly shows:

RuntimeVersion – v1.1.4322

Yet .NET goes ahead and loads the wrong version anyway.

So, the $64,000 question is: How do I get .NET to load the correct runtime here?

Now I can get my code to work just fine by rearranging my AppDomain Setup paths without debugging, but I guess I need to figure out how to get back to debugging my VS 2003 applications without uninstalling VS 2005. What determines how .NET uses load order if it's obviously not looking at the RuntimeVersion key in the registry when instantiating the COM object.

(Later) Here's the Answer:

By default the .NET framework will load the latest version of the .NET runtime for COM interop, so it makes sense it's using Version 2.0. To work around this you can provide a specific version of the runtime that gets loaded with a .CONFIG file for the application hosting the .NET COM component(s). So in this case the application I was working with was Visual FoxPro so I created:

d:\programs\vfp9\vfp.exe.config

with the following:

<?xml version="1.0"?>
<configuration>
 <startup>
 <supportedRuntime version="v1.1.4322"/>
 <supportedRuntime version="v1.0.3705"/>
 <requiredRuntime version="v1.1.4322"/>
 </startup>
</configuration>

This forces VFP to use version 1.1.4322 if available or 1.0 if not.

Incidentally I've been running and testing Help Builder for quite some time using wwReflection in Version 2.0 apparently and it works fine. For the moment it looks that a config file for wwHelp.exe is not required unless I need to debug from within Help Builder which I never do.