Binding to the Most Recent Visual Studio Libraries

Every version of Visual Studio comes with certain versions of the Microsoft libraries, such as 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 built, open a command prompt from inside Visual Studio, go to Tools > Visual Studio 2008 Command Prompt. Go to the folder containing the executable you've just built and use the following command to extract the manifest from your 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, built using Visual Studio 2008, will look like the following:

<?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 your 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 to Force Visual Studio to Bind to the New Libraries

Microsoft has defined a certain number of preprocessor definitions to tell the compiler/linker what version of the libraries to use. These definitions are also described in the MSDN. These definitions 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 easier, the following definition will bind to the latest version of all Visual Studio libraries:

#define _BIND_TO_CURRENT_VCLIBS_VERSION 1

Try this in your 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 this:

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 the following:

<?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 you that your new application is dependent on version 9.0.30729.1 of the C Runtime and on version 9.0.30729.1 of MFC; these 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 your own libraries. 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 the following:

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 that 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 forced to use the latest version of the Visual Studio libraries.

In 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.



About the Author

Marc Gregoire

Marc graduated from the Catholic University Leuven, Belgium, with a degree in "Burgerlijk ingenieur in de computer wetenschappen" (equivalent to Master of Science in Engineering in Computer Science) in 2003. In 2004 he got the cum laude degree of Master In Artificial Intelligence at the same university. In 2005 he started working for a big software consultancy company. His main expertise is C/C++ and specifically Microsoft VC++ and the MFC framework. Next to C/C++, he also likes C# and uses PHP for creating webpages. Besides his main interest for Windows development, he also has experience in developing C++ programs running 24x7 on Linux platforms and in developing critical 2G,3G software running on Solaris for big telecom operators.

Comments

  • There are no comments yet. Be the first to comment!

Leave a Comment
  • Your email address will not be published. All fields are required.

Top White Papers and Webcasts

  • Live Event Date: October 29, 2014 @ 11:00 a.m. ET / 8:00 a.m. PT Are you interested in building a cognitive application using the power of IBM Watson? Need a platform that provides speed and ease for rapidly deploying this application? Join Chris Madison, Watson Solution Architect, as he walks through the process of building a Watson powered application on IBM Bluemix. Chris will talk about the new Watson Services just released on IBM bluemix, but more importantly he will do a step by step cognitive …

  • Companies must routinely transfer files and share data to run their business, work with partners, and speed operations. However, many find the traditional approach to file transfer lacks necessary security, is too complex and difficult to manage, does not support the levels of automation needed, and breaks down when addressing the file transfer requirements of new areas like Big Data analytics and mobile applications. This QuinStreet SmartSelect discusses how the changing business environment is making the use …

Most Popular Programming Stories

More for Developers

Latest Developer Headlines

RSS Feeds