Repercussions of enabling useLegacyV2RuntimeActivationPolicy?

19
votes

For my current project, we're using some CLR 2 based mixed mode assemblies.

In order to use these from within a .NET 4 targetted assembly, I know you have to add useLegacyV2RuntimeActivationPolicy=true to the <startup> element within app.config.

I understand that this changes the activation policy, causing these mixed-mode assemblies to be loaded using the highest supported version of the CLR.

However, are there any side effects to doing this? What potential issues should I watch for when enabling the non-default activation policy?

2
.net.net-4.0clr4.0
stackoverflow.com/questions/1604663/… – Fredou
Not a duplicate of that - I understand what it's doing - and tried to explicitly state that. I'm wondering if there are any other side effects from enabling this behavior, since it's application (not assembly) wide... – Reed Copsey

2 Answers

12
votes

Hans Passant is partially correct. I attempt to explain this enigmatic attribute in this blog entry: http://www.marklio.com/marklio/PermaLink,guid,ecc34c3c-be44-4422-86b7-900900e451f9.aspx

The repercussions are essentially that you lock out in-proc SxS with pre-v4 runtimes. This is typically acceptable in a migration scenario.

4
votes

Well, sure, you'll be running the app with a CLR version it has never been tested against. Microsoft does a great job keeping it backwards compatible. But the case of Microsoft managers losing email access for a few days after a .NET upgrade is famous. The threadpool timing was slightly different, exposing a threading race in a program written by an intern. Can't google the link right now.