Is the default for "useLegacyV2RuntimeActivationPolicy" in ASP.Net contrary to the MSDN documentation?

Question

According to Microsoft's documentation, false is the default value for the "useLegacyV2RuntimeActivationPolicy" configuration:

http://msdn.microsoft.com/en-us/library/bbx34a2h.aspx

Use the default activation policy for the .NET Framework 4 and later, which is to allow legacy runtime activation techniques to load CLR version 1.1 or 2.0 into the process. Setting this value prevents mixed-mode assemblies from loading into the .NET Framework 4 or later unless they were built with the .NET Framework 4 or later. This value [false] is the default.

This appears to be the case for desktop applications, and any configuration files that are automatically or manually added to a project. It also makes sense that it's not set to true by default, since Microsoft was seeking to keep .Net 4.0 non-impactful

Cite: http://www.marklio.com/marklio/PermaLink,guid,ecc34c3c-be44-4422-86b7-900900e451f9.aspx).

I expected this to equally apply to web applications, but it doesn't appear to be the case; the web.config looks as expected, but the aspnet.config file (i.e., the global settings file located in the Microsoft.NET directory) actually sets this value to true.

Does anyone know the rationale behind this decision? That is, the decision to prevent in-process SxS for ASP.Net.

I greatly appreciate any insight into this. (Especially after banging my head against the wall over it, for the last day.)

Answer 1

[My answer is from the perspective of a member of the runtime team working with partners to help make sense of how in-proc SxS would shape their product]

Making the .NET Framework in-proc SxS compatible was a rather large undertaking that involved updating tons of internal calls through mscoree (either explicit or implicit like COM activation patterns). Teams had to choose a default that made sense both from a scenario perspective as well as a cost perspective. As a hosted platform that already had rich support for choosing which runtime to host a site with, ASP.net made a choice to stay in the single-runtime world. Desktop apps gain benefit by being flexible to a composition of different technologies (3rd party extensions, plugins, etc) and benefit from the high compatibility in-proc SxS mode of new runtime releases, which makes the downside of in-proc SxS not so bad (and you can always opt back into single runtime if it is bad). For web sites, these flexibilities come at the cost of performance and scalability (bringing in another runtime pulls in another managed memory heap, with another GC, lost virtual address space due to multiple versions of FX assemblies/native images, etc), and the scenarios that benefit from the flexibility and compatibility just aren't as significant in that environment.

For many teams, the most helpful framing of the choice was "what behavior do we want when we find ourselves in an accidental in-proc SxS scenario". For ASP.net, the answer was, We want to stay as performant and scalable as possible, and the fact that that decision frees up more of our resources in this release to focus on great ASP.net improvements is icing on the cake.