views:

694

answers:

1

Hello,

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!

+2  A: 

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.

marklio
Mark - thank you for your reply. Yes, I guess I understand that everything somehow runs with the .NET 4 runtime, but I understand that useLegacyV2RuntimeActivationPolicy starts things in "the .NET 2 runtime way" (whatever exactly that means).Also, I realize that rolling VS 2005 forward to V4 is unsupported. My main problem was not with VS 2005 but with my own custom CAB application, which was built against .NET 3.5 SP1. When I tried to apply the above startup element in the app config file, that's when I ran into problems.
Notre
With MS help, I found a workaround, using the COM layer as an intermediate:http://social.msdn.microsoft.com/Forums/en/netfxappcompatprerelease/thread/a181e9b0-9d67-4d3c-80c4-11529196d3bcThe purpose of this exercise is a short term patch; definitely, the whole application suite (several products), would be later (fairly soon, I hope) converted to target .NET 4 runtime. Using a workaround just gives me some breathing room, and allows me to do some work in parallel with converting the applications to target .NET 4.
Notre
I put the full stack trace on your blog, as the stack trace was too long to fit into a comment on this site.http://www.marklio.com/marklio/CommentView,guid,ecc34c3c-be44-4422-86b7-900900e451f9.aspx#commentstart
Notre
Notre - Thanks for the info. Sorry I didn't see your comment on my blog. Evidently my comment notifications aren't working. I'm glad Karel was able to help you on the forums. I'll look into the stack and see if there's a breaking change that needs to be documented.
marklio
For the possible benefit of anyone else reading this, the problem in my custom app is related to a custom synchronization context we're using in place of the standard WPF synchronization context. This custom synchronization context did some strange things that .NET 4 runtime doesn't like, so I'll be revisiting that later. Once the custom synchronization context was removed, then the problem disappears.
Notre