Problem using ‘useLegacyV2RuntimeActivationPolicy’ & supportedRuntime in an application

I've modified a couple of different applications' .config file like this:

<startup useLegacyV2RuntimeActivationPolicy="true">
   <supportedRuntime version="v4.0"/>
</startup>  

When I did this for devenv.exe.config (VS 2005 - don't ask :) ), things work great - most of the Visual Studio used .NET 2.0 but I was able to make use of an assembly targeting .NET 4.0 framework.

开发者_运维百科I tried to do the same thing for a custom .exe, which happens to be based on MS CAB (slightly modified) and has a hybrid mix of WPF and WinForms content. As soon as I modified this application's app config file, I started getting this exception, sometime during application startup:

The Undo operation encountered a context that is different from what was applied in the corresponding Set operation. The possible cause is that a context was Set on the thread and not reverted(undone). System.InvalidOperationException: The Undo operation encountered a context that is different from what was applied in the corresponding Set operation. The possible cause is that a context was Set on the thread and not reverted(undone).

There's a big long stack trace that doesn't show anything in my application code directly (just a bunch of MS assemblies).

If I modify the application's .config file to this:

<startup useLegacyV2RuntimeActivationPolicy="true">
</startup>

i.e.I remove the supportedRuntime element, then the application doesn't throw this exception. But when I go to the point in my code where I try to load my .NET 4 assembly, if fails with this:

System.BadImageFormatException: Could not load file or assembly '' or one of its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded.

I guess this is expected.

I have two questions:

1) Any idea why I'm getting the System.InvalidOperationException exception when I modify this application's configuration file to include the supportedRuntime element, adding .NET 4 support and any suggestions on what I can do about it?

2) If the answer is "no idea why/don't know what you can do about it", then is possible for my .NET 3.5 SP1 code (C#) to provide more fine grain support for conditionally adding .NET 4 runtime support for a certain assembly(ies) without converting my entire application to target .NET 4, or without using the declarative config file approach? At some point I would convert the entire application to target .NET 4, but for the short term this is daunting task and I'm hope for some short term solution/hack.

Thank you very much for any advice you can give!

I'm not sure exactly what behavior you're seeing for VS2005, but it shouldn't be the case that "most of the Visual Studio used .NET 2.0 but I was able to make use of an assembly targeting .NET 4.0 framework". That config should cause everything in the process to run on v4. If this is not the case, I'd certainly like to know about it because it's likely a bug. (BTW, I'm sure you realize that you're outside a supported scenario by rolling VS2005 forward to v4.)

As to the invalid operation exception, my guess would be that you're hitting some kind of incompatibility between frameworks. I'm sure we'd like to get a bug on that as well. Can you share the stack trace at the exception?

As far as taking an incremental upgrade approach... There is not really a good answer. The CLR supports in-proc SxS activation automatically for COM components, so if your app is implemented in a way where you can extract modules as COM components, then you could leverage that. The problem is that most apps are not written in this way, and simply upgrading everything to v4 is less work that re-architecting the app.

Individual assembly loads occur in the runtime that triggered the load. There's no in-proc SxS activation for normal assembly loads.