Visual C++ 2010: Changes to MSVC runtime deployment (no more SxS with manifest)

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 embe开发者_JAVA技巧dded 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.

---

Just a couple of links about the topic – I hope someone will find them useful:

• Visual Studio 2010 changes for VC++ (part 5)
• Visual C++ Application: How to use manifests and re-distributable assemblies?