How to distribute C run-time (CRT) Libraries

Question

I'm building an application after converting VC++ 6 workspace on Visual C++ 2008 express. Build in itself goes successfully but real problem I have is with the generated manifests which looks like this:

<?xml version='1.0' encoding='UTF-8' standalone='yes'?>
<assembly xmlns='urn:schemas-microsoft-com:asm.v1' manifestVersion='1.0'>
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
    <security>
      <requestedPrivileges>
        <requestedExecutionLevel level='asInvoker' uiAccess='false' />
      </requestedPrivileges>
    </security>
  </trustInfo>
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type='win32' name='Microsoft.VC90.CRT' version='9.0.30729.1' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' />
    </dependentAssembly>
  </dependency>
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type='win32' name='Microsoft.VC90.CRT' version='9.0.21022.8' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' />
    </dependentAssembly>
  </dependency>
</assembly>

My Question is :

How can I restrict the manifest to list only ONE version , preferably 9.0.21022.8. so that I can bundle the necessary C-Run time dependencies inside my application ?

I know the possible root cause to this problem is dependency on some library which uses 9.0.21022.8 and my VC++ Express 2008 might be using 9.0.30729.1. that's why both are listed as dependency.

Note:

I'm following approach b) of http://www.codeproject.com/Tips/211756/How-to-Distribute-C-run-time-CRT-Libraries-with-Yo?display=Print which talks about copying the CRT DLL files and Microsoft.VCXX.CRT.manifest file inside application folder.

You need to fix that. Yes, rebuild all libs with the same compiler settings. — Hans Passant, Nov 11 '11 at 17:34
Further to Hans comment, it's worth reading [this](http://www.nuonsoft.com/blog/2008/10/29/binding-to-the-most-recent-visual-studio-libraries/) which tells you a bit about controlling the version of the library that your code binds to. — tinman, Nov 11 '11 at 17:37
Thanks @tinman, link posted by you helped in resolving my problem. — amit, Nov 15 '11 at 20:10
@amit and/or @tinman, feel free to post an answer summarising the problem resolution so that I can "bounty you up". ` — Lightness Races in Orbit, Nov 17 '11 at 11:01
@amit: Please accept tinman's answer if it solved your problem. :) — Lightness Races in Orbit, Nov 17 '11 at 11:40

score 9 · Accepted Answer · edited May 23 '17 at 12:16

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 the same 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.

How to distribute C run-time (CRT) Libraries

Note:

1 Answers1

Linked