是“的默认值”；使用Legacyv2RuntimeActivationPolicy“；在ASP.Net中是否与MSDN文档相反？

根据Microsoft的文档，false是“useLegacyV2RuntimeActivationPolicy”配置的默认值：

使用.NET Framework 4及更高版本的默认激活策略，即允许传统运行时激活技术将CLR版本1.1或2.0加载到进程中。设置此值可防止混合模式程序集加载到.NET Framework 4或更高版本，除非它们是使用.NET Framework 4或更高版本生成的。此值[false]是默认值

桌面应用程序以及自动或手动添加到项目中的任何配置文件似乎都是如此。默认情况下，它没有设置为true，这也是有道理的，因为微软一直在寻求保持.Net 4.0的非影响力

引用：）

我希望这同样适用于web应用程序，但事实似乎并非如此；web.config看起来与预期的一样，但aspnet.config文件（即位于Microsoft.NET目录中的全局设置文件）实际上将该值设置为true

有人知道这个决定背后的理由吗？也就是说，决定阻止ASP.Net的进程内SxS

---

我非常感谢对这方面的任何见解。（特别是在最后一天我的头撞在墙上之后。）

[我的回答是从运行时团队的一名成员的角度出发，与合作伙伴合作，帮助理解in-proc SxS将如何塑造他们的产品]

使proc SxS中的.NET Framework兼容是一项相当大的任务，需要通过mscoree（显式或隐式的COM激活模式）更新大量内部调用。团队必须选择一个从场景角度和成本角度都有意义的默认值。作为一个托管平台，ASP.net已经对选择托管站点的运行时提供了丰富的支持，因此ASP.net选择留在单一运行时的世界中。桌面应用程序通过灵活地组合不同的技术（第三方扩展、插件等）而获益，并受益于新运行时版本的高兼容性in-proc SxS模式，这使得in-proc SxS的缺点不那么糟糕（如果不好，您可以随时选择返回单一运行时）。对于网站来说，这些灵活性是以性能和可伸缩性为代价的（引入另一个运行时会引入另一个托管内存堆，使用另一个GC，由于FX程序集/本机映像的多个版本而丢失虚拟地址空间，等等），而从灵活性和兼容性中获益的场景在这种环境中就没有那么重要了

---

对于许多团队来说，最有帮助的选择框架是“当我们发现自己处于一个意外的in-proc-SxS场景中时，我们想要什么行为”。对于ASP.net，答案是，我们希望保持尽可能高的性能和可扩展性，而这一决定在本版本中释放了我们更多的资源来专注于伟大的ASP.net改进，这一事实是锦上添花。

非常感谢您富有洞察力的回复。默认情况下，ASP.Net团队可能会选择性能而不是灵活性，这是有道理的。（尽管如此，如果在MSDN中的某个地方记录这一点会很好，因为它可能会导致一些意外的行为。但我意识到这是ASP.Net团队提出的。）