Why does my application require Visual C++ Redistributable package

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:

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

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

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

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