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

Question

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).

Bayberry

Answer 1

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.

Cascarilla

Thanks for confirming - that's how I understand it. (Though msvcrt100_clr0400.dll is basically the same version as the RTM version of msvcrt100.dll).But is there any documentation, blog post or anything about this? This is a big change from the previous version!? – Bayberry

"Basically the same" doesn't not count. Microsoft has no obligation to keep the private CLR copy compatible with your code. I'm sure it is documented somewhere, you can google it as well as I can. The VC++ team blog is good for background info. – Cascarilla

I understand 'their' copy of MSVCRT100 will be serviced separately, and shouldn't be targeted. I was just hoping for some dynamic-linking configuration that uses something already installed on with .NET. While the previous manifest-story was a mess, at least there was some version of the MSVCRT90 runtime guaranteed to be installed on the machine. And I really couldn't find much relevant to this change in policy on the VC++ team blog, or anywhere. That's my question here - Where's the blog post, note, read.me entry or anything about this change? I clearly missed it. How did you learn of this? – Bayberry

No, there was no guarantee that mscrt90.dll was installed. Not with a .NET install, not with Windows. If you never made an installer that either used the merge modules from c:\program files\common files\merge modules or ran vcredist_x86.exe then you had a lot of luck or astute customers. Much less need now with app-local deployment, xcopy can do the job. PDC talk, I think. It's been a while. – Cascarilla

Sorry - the .NET 2.0 framework ensured that MSVCR80.dll was installed, and .NET 3.5 ensured that MSVCR90.dll was installed. It's kind of funny that there is no sensible way to deal with the standard C/C++ runtime library on Windows. Installing the 'official' runtime redistributable is no longer good enough for the .NET team, and a private version with my app would need to be serviced privately. I think SxS made some sense.... at least it tried to really fix the problem of versioning shared libraries. – Bayberry

No, sorry, it doesn't work that way. .NET only ensures that a copy of the CRT is installed, the version that it was bound to. It has no obligation to provide the version of the DLLs that your app needs. Which is the key point of WinSxS deployment, the side-by-side cache stores multiple versions of the DLLs. And your manifest says which version you require. If you allowed Windows Update to deploy security patches on your machine then the version you need is much higher than the one that .NET deployed. – Cascarilla

I have totally given up on dynamic linking to the MSVC runtime. For small libraries or applications in C/C++, I see no reasonable alternative to static linking. In contrast, small .NET applications and libraries are great, since the underlying infrastructure is responsibly packaged and serviced. – Bayberry

App-local SxS, including with the 8.0 and 9.0 runtimes, was always possible and fully supported. – Selectman

Answer 2

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?

Plymouth