Should I redistribute msvcrt.dll with my application?
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/MTor the/MTdoption 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/MDor the/MDdoption 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:
You must ship msvcrt with your application. It is not a guaranteed part of the operating system. If a particular version of Windows happens to have it, it's only because something in Windows is using it.
Applications have broke when newer versions of Windows didn't happen to contain the binaries people assumed Windows came with. Applications have broke when the user chose not to install WinFax, which meant that msvcrt wasn't installed with it.
From Raymond Chen:
Depending on what version of Windowsyou're running, there may be a varietyof support DLLs for things that aren'tformal product components, but whichare merely along for the ride.
...
This problem persists today. People goscrounging around the binaries thatcome with Windows looking forsomething they can remora. And thenthey're surprised when those binarieschange or vanish entirely.
From KB326922 - Redistribution of the shared C runtime component in Visual C++:
...the CRT DLL is no longer considereda system file, therefore, distributethe CRT DLL with any application thatrelies on it. Because it is no longera system component, install it in yourapplications Program Files directorywith other application-specific code.This prevents your application fromusing other versions of the CRTlibrary that may be installed on thesystem paths.
You must ship msvcrt with your application, if you link to MSVCRT.
More
the decision was made to just give up and declare it an operating system DLL, to be used only by operating system components.
Although
MSVCRT.DLLhas been an operating system DLL for a long time, and has been documented as off-limits to applications, there are still a lot of people who treat it as a C runtime delivery channel, and those programs create a lot of grief for the product team.
You must redistribute the Microsoft Visual C Runtime with your application, because Windows does not ship with any Microsoft Visual C Runtime. There might happen to be a DLL called msvcrt.dll (which is not guaranteed), it is not the MSVCRT.
Chris's answer shouldn't be voted down because both are right.
The matter is that there're two different sets of MSVCRTs. One set is the msvcrt80.dll, msvcrt90.dll, etc. which comes with Visual Studio. This is what people normally used. And they must be redistributed, as talked in other answers.
The other is the msvcrt.dll (with no numbers in the file name) in System32 folder, which is intended to be used ONLY by the OS itself since some time ago. And applications should never replace/reinstall it. However, some applications do link to it, for some reasons like to remove the extra dependencies to install. But be aware that it is not guaranteed to be available in future Windows version.