Binding to the most recent Visual Studio Libraries

Every version of Visual Studio comes with certain versions of Microsoft libraries, like the C runtime library, the MFC library and so on. For example, Visual Studio 2008 comes with version 9.0.21022.8 of the Microsoft C runtime library and version 9.0.21022.8 of the MFC library. You can easily check which version your application needs by checking its manifest. For example: open Visual Studio 2008 and start a new MFC dialog based application. Activate the release build configuration and build the test application. Once it is build open a command prompt from inside Visual Studio, go to Tools > Visual Studio 2008 Command Prompt. Go to the folder containing the executable we’ve just build and use the following command to extract the manifest from our executable:

mt.exe -inputresource:bindingtest.exe -out:manifest.txt

where bindingtest.exe is the name of your executable. The file manifest.txt will contain the exported manifest. The manifest for this test application, build using Visual Studio 2008 will look like:

<?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"></requestedExecutionLevel>
      </requestedPrivileges>
    </security>
  </trustInfo>
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32" name="Microsoft.VC90.CRT" version="9.0.21022.8"
processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
    </dependentAssembly>
  </dependency>
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32" name="Microsoft.VC90.MFC" version="9.0.21022.8"
processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
    </dependentAssembly>
  </dependency>
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls"
version="6.0.0.0" processorArchitecture="x86" publicKeyToken="6595b64144ccf1df"
language="*"></assemblyIdentity>
    </dependentAssembly>
  </dependency>
</assembly>

What you see in this output is that our executable is dependent on the Microsoft C Runtime version 9.0.21022.8 and on the MFC library version 9.0.21022.8.

When you install the Visual Studio 2008 Service Pack 1, new versions of those libraries will be installed. However, by default, Visual Studio will keep linking to the old libraries unless you explicitly tell it to use the new versions.

How do we force it to bind to the new libraries?


Microsoft has defined a certain number of preprocessor defines to tell the compiler/linker what version of the libraries to use. These defines are also described here http://msdn.microsoft.com/en-us/library/cc664727.aspx
These defines are:

#define _BIND_TO_CURRENT_CRT_VERSION 1
#define _BIND_TO_CURRENT_ATL_VERSION 1
#define _BIND_TO_CURRENT_MFC_VERSION 1
#define _BIND_TO_CURRENT_OPENMP_VERSION 1

The above defines allow you to tell the compiler/linker to use the latest version of the CRT, ATL, MFC and/or OpenMP libraries.
To make it a bit more easier, the following define will link to the latest version of all Visual Studio libraries:

#define _BIND_TO_CURRENT_VCLIBS_VERSION 1

Lets try this in our example project.
Go to Project > xyz Properties. In the project properties window, select Configuration Properties > C/C++ > Preprocessor and edit the “Preprocessor Definitions”. Right now it probably is something like:

WIN32;_WINDOWS;NDEBUG

Change this to:

WIN32;_WINDOWS;NDEBUG;_BIND_TO_CURRENT_VCLIBS_VERSION=1

Close the properties window and rebuild your application. After rebuilding, extract the manifest from the Visual Studio 2008 Command Prompt.

mt.exe -inputresource:bindingtest.exe -out:manifest.txt

The new manifest will look like:

<?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"></requestedExecutionLevel>
      </requestedPrivileges>
    </security>
  </trustInfo>
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32" name="Microsoft.VC90.CRT" version="9.0.30729.1"
processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
    </dependentAssembly>
  </dependency>
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32" name="Microsoft.VC90.MFC" version="9.0.30729.1"
processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
    </dependentAssembly>
  </dependency>
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls"
version="6.0.0.0" processorArchitecture="x86" publicKeyToken="6595b64144ccf1df"
language="*"></assemblyIdentity>
    </dependentAssembly>
  </dependency>
</assembly>

Now the manifest tells us that our new application is dependent on the version 9.0.30729.1 of the C Runtime and on version 9.0.30729.1 of MFC which are the versions installed by service pack 1.

In real life, your application is much more complicated and will probably link to some other libraries, either third party libraries or libraries of your own. To ensure that your final application only depends on the latest version of the Visual Studio libraries, you need to make sure that all your other libraries are also only dependent on the latest version. For example, if you have a library that is still dependent on version 9.0.21022.8 of the C Runtime and you link it with your new application, your manifest might look like:

<?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"></requestedExecutionLevel>
      </requestedPrivileges>
    </security>
  </trustInfo>
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32" name="Microsoft.VC90.CRT" version="9.0.30729.1"
processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
    </dependentAssembly>
  </dependency>
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32" name="Microsoft.VC90.MFC" version="9.0.30729.1"
processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
    </dependentAssembly>
  </dependency>
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32" name="Microsoft.VC90.CRT" version="9.0.21022.8"
processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
    </dependentAssembly>
  </dependency>
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls"
version="6.0.0.0" processorArchitecture="x86" publicKeyToken="6595b64144ccf1df"
language="*"></assemblyIdentity>
    </dependentAssembly>
  </dependency>
</assembly>

Which means it will need both version 9.0.21022.8 and version 9.0.30729.1 of the CRT.

If you are linking with libraries (.lib) files you can use dumpbin to check what version of the libraries that lib file needs. For example:

dumpbin /directives <name>.lib

The output might contain something like:

Linker Directives
-----------------
/manifestdependency:"type='win32'
name='Microsoft.VC90.CRT'
version='9.0.21022.8'
processorArchitecture='x86'
publicKeyToken='1fc8b3b9a1e18e3b'"
/DEFAULTLIB:"MSVCRT"
/DEFAULTLIB:"OLDNAMES"

telling you it probably will force a dependency on version 9.0.21022.8 of the Microsoft CRT into your final manifest.

It’s also important to know that the MSM merge modules which you can find in Program Files\Common Files\Merge Modules are updated to the new version when installing the Visual Studio 2008 service pack. This means that if your application is still dependent on the old version of the libraries and you are using the merge modules in your setup project, it will not work. In other words, if you want to keep using those merge modules, you are forces to use the latest version of the Visual Studio libraries.

As a conclusion, if you want to link to the latest Visual Studio libraries, make sure all libraries that you are linking with are also using the latest version of the Visual Studio libraries.

( This article is also posted on CodeGuru. )

Share

5 Comments so far »

  1. John said,

    Wrote on April 1, 2009 @ 10:03 pm

    Well… went from DLL hell straight into something far far worse.

  2. Marc Gregoire said,

    Wrote on April 2, 2009 @ 8:06 am

    I agree.
    The good news is that all this will be changed in Visual C++ 2010. Basically the new deployment model goes back to the VC6 days, solving all those Windows SxS issues.
    See http://blogs.msdn.com/vcblog/archive/2008/10/28/visual-studio-2010-ctp-released.aspx

  3. klaus triendl said,

    Wrote on December 26, 2009 @ 12:41 am

    I don’t see any DLL hell here… the important thing to keep in mind is to distribute the merge modules for the runtime as well as the merge modules for the policy files!

    Example scenario:
    - Setting the macro _BIND_TO_CURRENT_VCLIBS=1 (as C/C++ preprocessor macro as well as for the midl compiler) for our projects results in a manifest binding to the runtime with version 9.0.30729.1
    - Because we’re using a static 3rd-party library that we cannot influence, and whose manifest binds to the RTM version of the runtime (9.0.21022.8), the final manifest for my applications contains dependencies on two versions of the runtime
    - Our install packages deploy the newest runtime via the most recent merge modules available, which currently is version 9.0.30729.4148

    Everything goes like clockwork as long as the policy files are present.
    Tested on fresh windows server 2003 and windows xp professional installations without WinSxS runtime assemblies being present on the system.

  4. Dimitrios Staikos said,

    Wrote on May 5, 2010 @ 8:18 am

    You rule!!!
    I noticed myself by opening the embedded manifest that it specified a different version (an earlier version), but I thought that it would work ok if you request an earlier version and find a newer one.
    And why all this? Because some sucker wanted to make a really trivial exported class in a DLL and made the DLL an MFC extension DLL, so I could not recompile with static MFC. Arghhh!!!
    My rule is this: ALWAYS STATIC LINKING. You simply reduce dramatically the problem surface area :-)
    Thanks!

  5. Kristian Nilssen said,

    Wrote on January 26, 2011 @ 10:06 am

    So when I deploy my exe and the manifest of that exe says 9.0.21022.8 and the end user has 9.0.30729.4148 installed, does the end user still have to install 9.0.21022.8?

    Is there any way of telling vs2008 to use a specific redist? Our solution has about 60 projects in it and I don’t want to modify 60 project settings. Thanks.

Comment RSS · TrackBack URI

Leave a Comment

Name: (Required)

E-mail: (Required)

Website:

Comment: