Visual C ++ 2010：对MSVC运行时部署的更改（不再有带清单的SxS） [英] Visual C++ 2010: Changes to MSVC runtime deployment (no more SxS with manifest)

问题描述

在哪里可以找到一些官方注释，kb文章或其他文档描述Visual Studio 2010 C / C ++运行时链接和部署策略的更改？

在Visual Studio 2008（使用VC90运行时），一个清单嵌入在本机映像中，并且运行时库被部署为并行程序集（WinSxS）。这在使用VS 2008 SP1重建本机exe或库时会导致问题，因为嵌入的清单需要更新版本的C ++运行时。

对于VS 2010和

1. 文件msvcr100.dll和其他C / C ++运行时库没有


2. 在VS2010下编译时，没有运行时依赖项被添加到嵌入式清单中，这意味着任何版本的msvcr100.dll都可能在运行时被加载。 / li>
   
3. 在安装了.NET 4的计算机上，匹配的运行时名为msvcr100_clr0400.dll，并且不会由本机代码加载，虽然副本重命名为msvcr100.dll工作正常。我认为这意味着任何具有C / C ++代码的进程将总是有两个版本的相同的C / C ++运行时加载。

是一个重大的政策变化，从SxS部署回溯和我们在VS 2008下的清单依赖。任何人可以更多地阐明什么改变，也许指向一些文档，自述或博客文章描述这些变化，动机和相关的影响？

它认为这是更好的方式 - 强版本清单和SxS部署是一个噩梦 - 但我惊讶的这些意外和看似无证的更改VS 2010。

补充问题：如何在VS 2010下编译我的C ++ / CLI库以链接到msvcr100_clr0400.dll而不是msvcr100。 dll？这个想法是，C ++ / CLI程序集应该运行没有除了由.NET 4安装的依赖项（没有静态链接）。

解决方案

你已经回答了大部分的问题，CRT的并行部署是一个噩梦，让太多的程序员陷入麻烦。微软同意并放弃了VS2010版本。它回到一个DLL在c：\windows \system32，命名为msvcr100.dll。和msvcp100.dll，vcomp100.dll，atl100.dll，mfc100.dll，mfcm100.dll，其他运行时支持DLL。 VS2003和早期版本的方式。现在，它再次是用户的负担来整理DLL地狱问题。这个人最不可能这样做，但他们往往有预算支付支持。与需要从免费网站获得帮助的程序员不同：）

但您可以帮助，应用程序本地部署现在再次启用，您可以部署msvcr100.dll与您的主EXE相同的目录。这在以前的版本中被明确检查和禁止。 App-local有一些美好的，它隔离了你的意图，但不幸的更新，打破了你的应用程序。虽然你现在自己负责获取更新部署，修复一个安全漏洞。如果这不舒服，然后部署并依靠系统目录中的副本。

不要 尝试链接到msvr100_clr0400.dll，这是一个私人复制供CLR使用。就像msvcr.dll是一个私人副本供Microsoft DLL使用。您没有.lib文件，您需要链接到这些DLL。

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.

1. The file msvcr100.dll and the other C/C++ runtime libraries are no longer install as SxS assemblies.
2. 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.
3. 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).

解决方案

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.

这篇关于Visual C ++ 2010：对MSVC运行时部署的更改（不再有带清单的SxS）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！