19

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?

Reed Copsey
  • 554,122
  • 78
  • 1,158
  • 1,373
  • http://stackoverflow.com/questions/1604663/what-does-uselegacyv2runtimeactivationpolicy-do-in-the-net-4-config – Fredou Feb 13 '10 at 00:40
  • 1
    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 Feb 13 '10 at 00:52

2 Answers2

12

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.

Steffen Opel
  • 63,899
  • 11
  • 192
  • 211
Mark Miller
  • 1,545
  • 1
  • 9
  • 6
4

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.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536