Visual Studio 2008 library version management

http://stackoverflow.com/questions/8097733/how-to-distribute-c-run-time-crt-libraries

The default for Visual Studio 2008 is to bind to version 9.0.21022.8. This is regardless of whatever version of service pack or hotfix you have installed, since updates to Visual Studio should not necessarily force your application to have to upgrade (as described here).

Other possible versions are 9.0.30729.1 for Service Pack 1 or 9.0.30729.6161 for SP1 with a security update. There are others.

Because of the default behaviour, it is likely that your application is using 9.0.21022.8 and there is a library which has been compiled to use 9.0.30729.1. You can find out what version of each library is dependant on by using the following command line (described here):

dumpbin /directives <name>.lib

In order to control the version of the runtime that your application binds to you can define preprocessor symbols in your project settings (must be in the project settings or on the command line) to either bind to the default version (9.0.21022.8 - by not defining them) or binding to thesame version as your installed Visual Studio:

_BIND_TO_CURRENT_VCLIBS_VERSION=1

Apparently you can also specify the exact version you want to bind to using the defines from this answer (maybe I should have found that first before typing all this out :).

If you find it is your application that binds to 9.0.30729.1 and the dependant library is binding to 9.0.21022.8 then you simply need to remove the preprocessor definition.

The other difficulty is that when you upgrade Visual Studio, the runtime merge modules in your redistributable folder are also upgraded to those versions. So if you have a setup project that uses those merge modules and you are trying to bind to the default version you would end up installing the new versions of the runtimes.

Resolving the runtime version would not be a problem if you also distribute the runtime policy merge modules, as the library loader will at runtime look at the policy of your runtime and automatically load the newest version even if you bind to the default version. Even with private assemblies the loader will first look in the WinSxS folder so if the policies are there you will bind to the newest version. So your mixed version numbers in your manifest will both redirect to the newest version.

Sometimes that is not desired and you can control that to force it to load only the version in the manifest that you specify, which is explained in an answer to this similar SO question.