Should I redistribute msvcrt.dll with my application and use the private dll if some of the application's libs dynamically depend on msvcrt.dll? I.e. are any incompatibility issues possible with the system's msvcrt.dll (dll hell)? Application is targeted for Windows Server systems.
msvcrt - is a dynamic library for the Microsoft Visual C++ runtime.
There are two options for using the C runtime in Windows:
link with static runtime libs.
Use either the /MT
or the /MTd
option to cl.exe. In this case, you will have no dependency on the msvcrt DLL, and therefore you will not have to redistribute it. In Visual Studio, right click on the Project or Solution, Properties > C/C++->Code Generation->Runtime library use Multithreaded and Multithreaded debug respectively. This is the easier way. The downside is that the resulting executable is larger.
link with the dynamic C Runtime library.
You will use either the /MD
or the /MDd
option to cl.exe.
In Visual Studio, right click on the Project or Solution, Properties > C/C++->Code Generation->Runtime library use Multithreaded Dynamic Link and Multithreaded Dynamic Link debug respectively. This results in a smaller EXE, but the downside is that you must install the required MSVCRT when installing your application.
Each release of the VC++ compiler ships with a version of the C runtime (CRT). Visual Studio 2005 shipped with v8 of the compiler, and v8 of the CRT. The actual DLL for v8 was msvcrt80.dll. For VS2008, it was v9, and the dynamic CRT was msvcrt90.dll. But, the CRT is updated and patched more frequently than is the C/C++ compiler. A developer can download an updated CRT, and build against that.
If you compile with the dynamic CRT library, you MUST download a redistributable package for the necessary version of the runtime from microsoft.com and perform a (potentially silent) install of it during your app install.
Prior to VS2005, developers built apps to depend on the MSVCRT that was in the Windows operating system. This would give the benefit of the DLL (small image size) while not incurring the requirement of shipping the CRT DLL in the application install. Prior to Windoes 2000, developers would even install a new MSVCRT.dll in the \Windows installation folder. But, sharing the CRT across many apps and the OS too, turned out to be a really bad idea. With WinXP SP2, the CRT included with Windows changed significantly, and any apps that depended on that version of the CRT were at risk of breaking.
At this point Microsoft tells developers that the MSVCRT.dll that is included with Windows is part of the OS, and may be serviced or patched at any time. It is not supported to build an app against it. Therefore applications should use one of the methods above.
References: