Visual C++ 2010：MSVC 运行时部署的更改（不再带有清单的 SxS）
在哪里可以找到描述 Visual Studio 2010 C/C++ 运行时链接和部署策略更改的官方说明、知识库文章或其他文档？
在 Visual Studio 2008（带有 VC90 运行时）下，清单嵌入到本机映像中，并且运行时库被部署为并行程序集 (WinSxS)。当使用 VS 2008 SP1 重建本机 exe 或库时，这会导致问题，因为嵌入式清单需要更新版本的 C++ 运行时。
对于VS 2010和MSVCR100运行时版本，该策略似乎完全改变了。
- 文件 msvcr100.dll 和其他 C/C++ 运行时库不再作为 SxS 程序集安装。
- 在 VS2010 下编译时，不会将运行时“依赖项”条目添加到嵌入式清单中，这意味着任何版本的 msvcr100.dll 都可能在运行时加载。
- 在安装了 .NET 4 的计算机上，匹配的运行时名为 msvcr100_clr0400.dll，并且不会由本机代码加载，但重命名为 msvcr100.dll 的副本可以正常工作。我认为这意味着任何具有 C/C++ 代码的进程将始终加载同一 C/C++ 运行时的两个版本。
这似乎是政策上的一个重大变化，从我们在 VS 2008 下的 SxS 部署和清单依赖性的回溯。任何人都可以更详细地说明发生了什么变化，也许可以指出一些描述这些变化的文档、自述文件或博客文章，动机和相关影响？
它认为这样更好 - 强版本清单和 SxS 部署是一场噩梦 - 但我对 VS 2010 中这些意外且看似未记录的更改感到惊讶。
额外问题：我如何编译我的 C++ VS 2010下的/CLI库链接到msvcr100_clr0400.dll而不是msvcr100.dll？这个想法是，C++/CLI 程序集运行时不应依赖于 .NET 4 安装的依赖项（无静态链接）。
Where can I find some official note, kb article or other documentation describing changes to the Visual Studio 2010 C/C++ runtime linking and deployment policy?
Under Visual Studio 2008 (with the VC90 runtime) a manifest was embedded in native images, and the runtime libraries were deployed as side-by-side assemblies (WinSxS). This caused problems when rebuilding a native exe or library using VS 2008 SP1, in that an updated version of the C++ runtime was required by the embedded manifest.
For VS 2010 and the MSVCR100 runtime version, the policy seems to have changed completely.
- The file msvcr100.dll and the other C/C++ runtime libraries are no longer install as SxS assemblies.
- When compiling under VS2010, no runtime 'dependency' entry is added to the embedded manifest, meaning that any version of msvcr100.dll might be loaded at runtime.
- On machines with .NET 4 installed, the matching runtime is named msvcr100_clr0400.dll, and won't be loaded by native code, though a copy renamed to msvcr100.dll works fine. I think this means any process with C/C++ code will always have two versions of the same C/C++ runtime loaded.
This seems to be a significant change in policy, backtracking from the SxS deployment and manifest dependencies we had under VS 2008. Could anyone shed more light on what changed, and perhaps point to some documentation, a readme or blog post that describes these changes, the motivation and related impact?
It think it's better this way - the strong version manifest and SxS deployment was a nightmare - but I'm surprised at these unexpected and seemingly undocumented changes in VS 2010.
Bonus question: How can I compile my C++/CLI library under VS 2010 to link to msvcr100_clr0400.dll instead of msvcr100.dll? This idea is that the C++/CLI assembly should run with no dependencies other than that installed by .NET 4 (without static linking).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您已经回答了大部分问题，CRT 的并行部署是一场噩梦，让太多程序员陷入困境。 Microsoft 同意并在 VS2010 版本中放弃了它。它又回到了c:\windows\system32 中的一个DLL，名为msvcr100.dll。还有msvcp100.dll、vcomp100.dll、atl100.dll、mfc100.dll、mfcm100.dll等其他运行时支持DLL。 VS2003 及更早版本的情况也是如此。现在，解决 DLL Hell 问题又成为用户的负担。最不可能做到这一点的人，但他们往往有预算来支付支持费用。与需要从免费网站获取帮助的程序员不同:)
但是您可以提供帮助，应用程序本地部署现在再次启用，您可以将 msvcr100.dll 部署在与主 EXE 相同的目录中。这在以前的版本中被明确检查和禁止。 App-local 有一些优点，它将您与善意但不幸的破坏您的应用程序的更新隔离开来。尽管您现在自己负责部署修复安全漏洞的更新。如果这不舒服，那么部署并依赖系统目录中的副本。
不要尝试链接到 msvr100_clr0400.dll，这是供 CLR 使用的私有副本。与 msvcr.dll 非常相似，它是供 Microsoft DLL 使用的私有副本。您没有链接到这些 DLL 所需的 .lib 文件。
You already answered most of your question, the side-by-side deployment of the CRT was a nightmare that got way too many programmers in trouble. Microsoft agreed and gave up on it for the VS2010 release. It's back to a DLL in c:\windows\system32, named msvcr100.dll. And msvcp100.dll, vcomp100.dll, atl100.dll, mfc100.dll, mfcm100.dll, the other runtime support DLLs. The way it was for VS2003 and earlier editions. Now it is again the user's burden to sort out a DLL Hell problem. The person least likely to be able to do so but they do tend to have a budget to pay for support. Unlike programmers that need to get help from a free web site :)
But you can help, app-local deployment is now again enabled, you can deploy msvcr100.dll in the same directory as your main EXE. That was explicitly checked and forbidden in previous versions. App-local has some niceties, it isolates you from well-meant but unfortunate updates that break your app. Albeit that you are now yourself responsible for getting updates deployed that fix a security hole. If that's uncomfortable then deploy and rely on the copy in the system directory.
Do not try to link to msvr100_clr0400.dll, that's a private copy for use by the CLR. Much like msvcr.dll is a private copy for use by Microsoft DLLs. You don't have the .lib file you need to link to these DLLs.
只是关于该主题的几个链接 - 我希望有人会发现它们有用：
Just a couple of links about the topic – I hope someone will find them useful: