Why does my application require Visual C++ Redistributable package

Question

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?

Sollows

Answer 1

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

Sollows

I will do solution 1 which is "link statically with runtime library". How can I do that in VS 2013? – Betrothal

It's explained pretty good at the official Microsoft site. In a nutshell, you should go to Project properties -> C/C++ -> Code generation -> Runtime Library and choose an MT option for Release or MTd option for debug. But keep in mind that as it's specified in the answer above, use of static linkage is not recommended. – Sollows

Can you elaborate why static linking is bad? – Shushan

Sure. Say you're developing an application which links statically to a runtime library. Which means, at linkage time the linker will look for the runtime library functions you're using and put them inside your application. Say also you want to use some third party library which also links statically to a runtime library. Now, if your application and the dll you want to use are using the same runtime function (for instance any std function) your linker won't be able to decide which function should it pick - the one from your runtime library or the one from dll runtime library. – Sollows

To clearify further: this is a compile time issue only. When your target links w/o errors against the static import libraries of DLLs, because they use the same RTLs, the product should run on any machine. Static linking can be easier and safer than relying on DLLs. In 25+ years of Windows development I avoided DLLs where possible. Never was a friend. Nowadays it's a security issue too. Compromising some msvcrtxx.dll can affect many applications. – Norvol

@NathanGoings - Rare edge case: you link statically and dll links statically and all is well. THEN the dll gets updated in the field and it now links statically to a different version of the "common" library that implements some structure differently from how the old version did. Your application has no way to know that the dll is using an incompatible version of the static library. So it isn't that static linking is bad, it is that mixing static linking with dynamic linking has risks that you need to be aware of. Option #4 (side-by-side deployment) or #3 (smart setup) are your safest. – Iotacism

Answer 2

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.

Baba

uTorrent.exe and BitTorrent.exe, for example, statically link the C runtime. This is part of the reason the single .exe can serve as its own installer. – Metacenter

Only issue in mixing .exe, .dll and statically linked libs is when the .dll is 3rd-Party and out of your control. it may get updated in the field to use an incompatible version of the (previously common version) static library. This is still not guaranteed to cause problems. But if data structures from one version of the static lib are given to the other version of the static lib and the two versions made a significant change (like memory management), then it COULD cause issues. So, yes statically link everything is a good way to go, but it makes for a larger .exe. – Iotacism

to continue - dynamically linking, and deploying many .dll files with your .exe means you can update for a bug fix by updating only the one DLL that changed. There is no need to re-link the .exe or the other .dll files so long as you don't make breaking changes in the .dll you update. This just means maintain interface stability when you do tweaks to your dynamic libraries. @binyan commented that when using a 3rd-Party .dll you have no control over, static linking to a common library can raise issues down the road. You app is broken for a dll change out of your control. – Iotacism

To clarify here. I totally agree with the author of this answer that we don't statically link DLL, which stands for (ironically) Dynamic-Link Library. I'm not suggesting to completely avoid use of static libraries. I'm saying that static linkage to a runtime library might get you in troubles. If you develop a simple application without use of any DLLs, you can live with statically linked runtime. However, if you use a 3d party DLLs, or you develop a DLL yourself, you probably should consider using dynamically linked runtime (for the reasons I specified in my answer). – Sollows