Is it possible to dynamically change the CLR runtime that activates legacy assemblies (BindAsLegacyV2Runtime)?

Here is my problem:

I have to do a plugin hosted by a third-party application. That application is an MFC app and to do my plugin, I have to implement a COM object. My COM ob开发者_C百科ject is in C# and needs to interop with .NET 4 assembly (so, my C# project targets .NET 4).

When I tested that, it didn't work... I received the exception: Mixed mode assembly is built against version 'v2.0' of the runtime and cannot be loaded in the 4.0 runtime without additional configuration information...

Now, since I am doing an integration to a third-party app, adding an App.exe.config file with the useLegacyV2RuntimeActivationPolicy set does not seem to be an acceptable solution (or is it?).

I have tried to add an extra layer of C++ between the MFC app and my .NET code. This layer implements the COM object and forward all calls to the C#. I resolved my mixed-mode exception by using the ICLRRuntimeInfo::BindAsLegacyV2Runtime() method. This worked fine. However, if another plugin using .NET 2.0 only is loaded prior to mine, this method fails (since the .NET 2.0 runtime started by the other plugins manages legacy loading policies).

Long story short, I am stuck. Is there a way to dynamically change the runtime in charge of legacy loading policies?

Thanks for the help.

---

Because you are a loaded component of a different application, you will always face the issue of load order causing different runtimes to load. What you can do is try to use .net 4s In-process side by side guidance to make sure you load what you want.

And while it's generally a bad idea to add an application config for a app you don't control, sometimes it's the only way around a problem. I can certainly see adding the app.exe.config and testing - however if you are distributing your plugin to a wide audience, this could prove to be problematic.

If all else fails, you may have to do what we did - run the parts of the plugin that must use your .net 4 assemblies in a separate process, and create a COM addin "shim" that communicates with that process. It's not a good solution if you are using UI from the .net assemblies, but it works acceptably well for many other cases.