启用 useLegacyV2RuntimeActivationPolicy 的影响？
对于我当前的项目，我们使用一些基于 CLR 2 的混合模式程序集。
为了在 .NET 4 目标程序集中使用这些，我知道您必须将 useLegacyV2RuntimeActivationPolicy=true 添加到
据我所知，这会更改激活策略，导致使用受支持的最高版本的 CLR 加载这些混合模式程序集。
但是，这样做有副作用吗？启用非默认激活策略时应注意哪些潜在问题？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
汉斯·帕桑特是部分正确的。我尝试在此博客条目中解释这个神秘的属性： http://www.marklio.com/marklio/PermaLink,guid,ecc34c3c-be44-4422-86b7-900900e451f9.aspx
其影响本质上是您使用 v4 之前的运行时锁定了进程内 SxS。这在迁移场景中通常是可以接受的。
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.
嗯，当然，您将使用从未经过测试的 CLR 版本来运行该应用程序。微软在保持向后兼容方面做得很好。但 Microsoft 经理在 .NET 升级后几天无法访问电子邮件的案例是众所周知的。线程池计时略有不同，暴露了实习生编写的程序中的线程竞争。现在无法通过谷歌搜索链接。
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.