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).
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?
Related
I'm writing a simple C++ application in Visual Studio. It also has a setup project.
It works well on my development machine, but when I'm installing this application on user's machine it requires Visual C++ Redistributable Package. I'm wondering why does my application require C++ Redistributable? Standard C++ runtime library is shipped with Windows, isn't it?
The only version of the C runtime library which is shipped by Microsoft with most of 32 bit Windows versions is msvcrt.dll. This library provides a typical set of library functions required by C and C++ programs. These include string manipulation, memory allocation, C-style input/output calls, etc.
Visual Studio 6.0's compiler links against this library, so if you are developing in VS 6.0 you shouldn't encounter any problems on most users' machines.
However, if you are developing in VS 2005, VS 2008, VS 2010, VS 2012, VS 2013 or VS 2015, you have to distribute additional C runtime libraries along with your application. This is because their compilers link against msvcrt80.dll, msvcrt90.dll, msvcrt100.dll, msvcrt110.dll, msvcrt120.dll and msvcrt140.dll respectively, which are not shipped with Windows.
Solutions:
Possible solution is to link statically with runtime library, but it may cause a lot of problems in case you have both .exe and .dll in your application. Don't do that.
To be more specific, I'll allow myself to quote a part of this answer:
Using /MT is risky if you create DLLs as well as an EXE. You'll end up
with multiple copies of the CRT in your program. This was especially a
problem with earlier versions of VS where each CRT would get its own
heap, not so much with VS2012. But you can still have ugly runtime
problems when you have more than one "errno" variable for example.
Using /MD is highly recommended to avoid such lossage.
Another possible solution is to require an appropriate Microsoft Visual C++ Redistributable package to be installed on the user's machine.
It may be done by specifying this requirement in prerequisites property in your setup project.
Also, you can distribute the runtime dll by including in your setup project the appropriate "merge module". In this case don't forget to add the appropriate "policy merge module" to avoid errors caused by incorrect runtime version.
Finally, you can just put required DLLs in the same folder in which your application is installed.
Further reading:
"Redistributing Visual C++ Files" - Official MSDN documentation
Even though some comments said that «link statically with runtime library, but it may cause a lot of problems when you have both .exe and .dll in your application.» this is NOT TRUE. First we DON'T statically link DLLs! We statically link OBJs and LIBs. LIBs are static libraries; DLLs are dynamic libraries, and you may choose to use LIBs (static) or DLLs (dynamic). It's entirely up to you to choose. The ONLY drawback (for the DLL fans) is that if you want to update one library, you need to compile and link again. I personally deploy ALL my software static linked and because of that I earn the bonus of don't even need installers. The software I develop is 100% portable (a feature that in the pre-installer era was general procedure), and the final user is free to simple COPY from one folder to another or even from the hard drive to flash drive (or vice-versa). The error message «DLL not found.» simply doesn't exist ... NEVER.
Some folks think of statically linking as toy software: WRONG! I can write a full featured application that connects to a DBMS (Oracle, SQL Server, ...) or any other kind of application.
I'm about to begin a project for building a plugin to a large simulation system built with MSVC6, and offering instructions for compiling DLL's using MSVC6.
I have MSVC10 and 2012 available, and I'm wondering if it's even possible to configure these to build "down" to MSVC6 compatibility. Seems last time I dug into this, the answer was a resounding "No". Do I have to find an old MSVC6 install?
Update: There's also a 64-bit Visual Studio 2008 version of this that I could develop against, so same question: Can I configure a "new" visual studio (like 2012 or so) to compile down to VC6 or 2008 compatibility?
You can take an alternative approach, if you create your new project as a COM dll you can interact with it from MSVC6 however you will need to deliver any new linked runtime dlls as well in your resulting setup.
I've browsed around StackOverflow but couldn't find any pratical solution to something that would seem to have such an easy solution: I had a bunch of .Net projects that were developed back in VS2005 or VS2008 and I imported them into VS2010. One of them is a C++ project, which currently targets framework 4.0 (not by my choice). One of our clients is having a problem running this application, the lack of a MSVCP100D.dll. I checked this thread what is MSVCP100D.dll? and the most accepted answer is simple: having the client install Microsoft Visual C++ 2010 Redistributable Package. However, the client is stubborn enough not to install it and I know for a fact that they have Microsoft Visual C++ 2008 Redistributable installed. So, if I'm correct in my conclusions and MSVCP100D.dll is new to VS2010, I could just target a previous framework version, rebuild the project in VS2010 and I'd be good to go. The problem is: how do I chance a VC++ target framework? I could find several guidelines to change C# and VB projects, but none about VC++. Any pointers?
Edit: To you guys who suggested that I compile it in Release mode: I am! It's been pointed out that the "D" stands for debug, which is rather strange.
Actually, you are using the debug version of the runtime (That's the "D"). Did you try compiling with a non-debug version?
Another possibility to consider would be to statically link with the runtime library. Your program will be larger, but will not have the DLL dependency.
Go into the project's properties.
On the lefthand side, go into Configuration Properties > General.
Look at the Platform Toolset value. Select v90 from the drop down list to target 2008.
See here for further details:
Visual C++ 2010 compatibility with VC 2008
See here for yet even more details:
http://blogs.msdn.com/b/vcblog/archive/2009/12/08/c-native-multi-targeting.aspx
Also as Dark Falcon mentions, that's the debug version of the runtime.
I know this has been asked in other places and answered, but I'm having issues with MS Visual Studio 2010. I've developed a C++ executable but if I run the Release version on a machine that doesn't have the VC++ runtime library (ie, msvcr100d.dll), I get the "program cannot start because msvcr100d.dll is missing from your computer" error.
This is weird for two reasons:
Why is it trying to link with the debug version of the redistributable?
I tried applying this fix, setting the runtime library setting to /MT instead of /MD (multi-threaded DLL), but that only made the problem worse (if I manually copied msvcr100d.dll, it then said it couldn't find msvcp110.dll).
How can I package the runtime library with my executable so that I can run it on machines that don't have MS VC 2010 or the redistributable installed?
I know it's considered a security risk to include a copy of the DLL since it won't ever be updated, but my goal is just to send this executable to a few friends in the short term.
You definitely should not need the debug version of the CRT if you're compiling in "release" mode. You can tell they're the debug versions of the DLLs because they end with a d.
More to the point, the debug version is not redistributable, so it's not as simple as "packaging" it with your executable, or zipping up those DLLs.
Check to be sure that you're compiling all components of your application in "release" mode, and that you're linking the correct version of the CRT and any other libraries you use (e.g., MFC, ATL, etc.).
You will, of course, require msvcr100.dll (note the absence of the d suffix) and some others if they are not already installed. Direct your friends to download the Visual C++ 2010 Redistributable (or x64), or include this with your application automatically by building an installer.
For me the problem appeared in this situation:
I installed VS2012 and did not need VS2010 anymore.
I wanted to get my computer clean and also removed the VS2010 runtime executables, thinking that no other program would use it.
Then I wanted to test my DLL by attaching it to a program (let's call it program X).
I got the same error message.
I thought that I did something wrong when compiling the DLL.
However, the real problem was that I attached the DLL to program X, and program X was compiled in VS2010 with debug info. That is why the error was thrown.
I recompiled program X in VS2012, and the error was gone.
This problem explained in MSDN Library and as I understand installing Microsoft's Redistributable Package can help.
But sometimes the following solution can be used (as developer's side solution):
In your Visual Studio, open Project properties -> Configuration properties -> C/C++ -> Code generation
and change option Runtime Library to /MT instead of /MD
Usually the application that misses the .dll indicates what version you need – if one does not work, simply download the Microsoft visual C++ 2010 x86 or x64
from this link:
For 32 bit OS:Here
For 64 bit OS:Here
I got the same error.
I was refering a VS2010 DLL in a VS2012 project.
Just recompiled the DLL on VS2012 and now everything is fine.
Debug version of the vc++ library dlls are NOT meant to be redistributed!
Debug versions of an application are not redistributable, and debug
versions of the Visual C++ library DLLs are not redistributable. You
may deploy debug versions of applications and Visual C++ DLLs only to
your other computers, for the sole purpose of debugging and testing
the applications on a computer that does not have Visual Studio
installed. For more information, see Redistributing Visual C++ Files.
I will provide the link as well : http://msdn.microsoft.com/en-us/library/aa985618.aspx
I have developed a Win32 Console app DLL and a small tester application for it. As far as I know neither uses MFC, .COM, .NET or dot-anything else. Development platform is VS2009 on WinXP/SP3
When I give the DLL and EXE to someone else, they are unusable. Attempting to use them generates errors similar to "Application cannot be used, the application configuration is wrong." and "cannot find xxx.dll" (not exact wording on these error messages).
I have learned from reading that there are dependencies that must ship with the EXE and DLL. These dependencvies seem to be specific to VS 2009 abd should include the MSVCRT09, etc.
When I followed MS's instruction to make a setup.exe/MSI installer for a Setup and Deployment Project (http://msdn.microsoft.com/en-us/library/ms235317%28v=VS.90%29.aspx) I add the dll to the project, move it to the "MyLibrary" folder and no dependencies are found or listed in the Solution Explorer. Yet, I know there are dependencies, DEPENDS.EXE says so.
Can anyone walk me through this or name a better site with instructions. Once again, MS's help isn't all that helpful.
thanks,
Wes
Visual Studio 2008 is version 9.0. A program built with Visual C++ 2008 normally does have dependencies on the C run time library MSVCRT09, as you discovered. If the C run time library is not installed on the destination PC (either already installed or as part of your setup project) then your application fails, as you discovered. It is no surprise that DEPENDS.EXE displays the dependency. The only question seems to be why Visual Studio 2008 doesn't display the dependency in its Solution Explorer window.
Before building your Visual Studio setup project (MSI and setup file), Visual Studio might not have had any reason yet to search for dependencies. But after the setup project is built, in my experience the Solution Explorer does show the dependencies it found, next to other dependencies that you set explicitly. If those don't show up after building, something is weird.