After migrating to Visual Studio 2008 SP1 and building the application, the manifest file of application and all the dependent DLL’s contain RTM version.

In Visual Studio 2008 SP1, by design, the manifest for the created exe links it to the RTM version of the CRT.

In Visual Studio 2005 SP1, by design, the manifest is linked to the current version of the CRT. This was a design change that happened in Visual Studio 2008; by default, it always links to the RTM version of the CRT (no matter if we are using SP1 to build it).

In order to link with SP1 version, rebuild the application with _BIND_TO_CURRENT_MFC_VERSION=1, _BIND_TO_CURRENT_CRT_VERSION=1, and/or _BIND_TO_CURRENT_ATL_VERSION=1 in stdafx.h.

http://blogs.msdn.com/vcblog/archive/2008/05/15/vc-runtime-binding.aspx

Recently, I came across the scenario where building an ATL project with _BIND_TO_CURRENT_MFC_VERSION=1, _BIND_TO_CURRENT_CRT_VERSION=1, _BIND_TO_CURRENT_ATL_VERSION=1 in stdafx.h, the manifest file contains dependency of both RTM and SP1 version of CRuntime library.

The manifest file will look like:

<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.ATL" 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>

 

 

If you’re seeing multiple manifest entries, the easiest way I’ve found to diagnose this is to do something like this:

1.       Set LINK_REPRO=c:\repro  [or any other directory]

2.       Build your app. 

3.       All objs and libs that your application depends on are present in c:\repro.

4.       In c:\repro, do “link /dump /directives *.lib *.obj > direct.txt”

5.       Open up ‘direct.txt’ in your any text editor and search for the “bad” version number (9.0.21022.8).  That will tell you which object or library is responsible for the RTM dependency in your manifest.

This may be caused by one of the following:

1.       Inconsistent use of ‘BIND_TO_CURRENT_VERSION’ in your app. 

2.       An external static library that you are using which wants RTM, while the rest of your objects want SP1. 

In my scenario, it was the .obj file that corresponds to the _i.c file which is auto generated file after compiling an IDL file.  As IDL files are compiled before stdafx.h, and if IDL file is referring to certain header files which can introduce dependency to RTM version of CRT, finding such dependency is very difficult.  Also we cannot add _BIND_TO_CURRENT_MFC_VERSION=1, _BIND_TO_CURRENT_CRT_VERSION=1, _BIND_TO_CURRENT_ATL_VERSION=1 _i.c to the _i.h file, as they are auto-generated files. 

Work Around:

To work around this issue, we can use preprocessor definitions and add _BIND_TO_CURRENT_VCLIBS_VERSION

1.       Right Click _i.c file.

2.       Go to Configuration Property.

3.       Select C/C++ Preprocessor

4.       Add _BIND_TO_CURRENT_VCLIBS_VERSION to Preprocessor Definitions.

 

 

Jyoti Patel

Developer Support VC++ and C#