Should I use vcredist.exe or the msm's to install the Visual C++ runtime library

Question

What are the pluses and minuses to using the vcredist.exe versus the msm files to install the Visual C++ 8.0 runtime libraries?

Answer 1

Merge Modules can not be updated (unless they solved that in Windows Installer) once they are installed, so my advice would be to stick with vcredist.exe.

Answer 2

MSM will give you a better streamline experience then vcredist, it will integrate with the progress bar and will rollback on error (or cancel).
From the developer side you will benefit by seeing the msm log in the main setup log file and it will execute its actions side by side with the setup action (with vcredist you will need to sequence it yourself).

Because of all of the above reasons I usually choose to use the msm (and its more or less one Wix liner to use it).

Answer 3

To point out the obvious, Merge Modules are not really a good solution if you aren't going to use an MSI installer. Vcredist is absurdly simple to use regardless of the install process you are using.

Answer 4

Have you considered statically linking instead? Then you don't have a redistribution problem.

Answer 5

One downside to the merge modules is that you can't deploy multiple versions of the VC80 or VC90 merge module in the same msi because the file identifiers overlap. You can deploy one of each though. So for example, if you wanted to deploy the RTM version of VC80 and the SP1 version, you will get errors if they are in the same msi (I use WiX).

Another issue, build behavior is different between VS 2005/2008 as it pertains to applying a service pack or update.

2005 If you install service pack 1 on your build machine, your program will automatically link against the updated files. The service pack will also update the merge modules, so provided you're pointing your installer to use the updated files, you're fine. However, this can be an issue if you're using third party compiled static libs that may require an older version of the runtime specifically.

2008 The behavior here is the exact opposite. If you install SP1, the merge modules are updated to the SP1 level, but your program will compile against the RTM versions unless you set a per-project preprocessor macro: _BIND_TO_VCLIBS_CURRENT_VERSION=1. This can be set either in stdafx.h or in the "Preprossor definitions" for your project, or if you're using an old nmake project, you will have to pass it wherever your command line options are, such as CFLAGS.

This means that if you're using the msm provided by visual studio, and you apply SP1, your project deployment is broken until you define the macro.

Another caveat to the macro: if you're using a 2005 project that links against a 2008 static lib, setting the macro will break the 2005 project, due to the symbol not existing in the 2005 version of the compiler. In this case I usually split the project I'm linking against into a 2005 and 2008 version of the solution.