Troubleshooting Manifest-Related Issues


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# 


 

Comments (8)

  1. R.J says:

    First, thanks for the information.

    Can’t we just add _BIND_TO_CURRENT_VCLIBS_VERSION to Preprocessor Definitions of the project itself?

  2. Jyoti Patel says:

    We can add _BIND_TO_CURRENT_VCLIBS_VERSION  to preprocessor definations of the project itself. But recommended way is to put it in stdafx.h.  In case you have multiple solutions in project this is workaround to do that.

  3. Nikhil Shirke says:

    Can’t we use WinSxS with Win XP SP3 ?

  4. dduong says:

    Jyoti Patel,

    I added _BIND_TO_CURRENT_VCLIBS_VERSION to Preprocessor Definitions but it doesn’t have any effect at all. Any idea? I have to add these definition below to my stdafx.h and it works but I still have multiple manifest entries

    #define _BIND_TO_CURRENT_MFC_VERSION 1

    #define _BIND_TO_CURRENT_CRT_VERSION 1

    #define _BIND_TO_CURRENT_ATL_VERSION 1

    Thanks

    DD

  5. Jon Kilvington says:

    I have a similar problem to this and found that it may be related to the /Zl compiler option. If I compile:

    #include <stdio.h>

    int main() { return 0; }

    with cl -MDd -D_BIND_TO_CURRENT_VCLIBS_VERSION=1 a.cpp then the manifest file looks ok and contains the service packversion of the CRT assembly (30729)

    If I compile with cl -MDd -Zl -D_BIND_TO_CURRENT_VCLIBS_VERSION=1 a.cpp msvcrtd.lib then the manifest file contains the RTM version of the CRT assembly (21022)

    In my application I actually get both versions added to the manifest file, but I have been unable to reproduce this in a smaller example. Rebuilding all my objects without the /Zl compiler flag and relinking fixed it. Does anyone know if this is intentional?

    For the record, using the link /dump /directives approach on all objs/libs that I link with showed that the only 21022 references came from the CRT/MFC and ATL libs themselves!

  6. Jyoti Patel says:

    Hi Nikhil,

    We can use WinSxS with windows XP SP3.  You can go through following blog entry.

    http://blogs.msdn.com/dsvc/archive/2008/08/07/part-1-troubleshooting-vc-side-by-side-problems.aspx

  7. Jim Michaels says:

    exactly what should the assemblyIdentity look like for using

    – the XP msvcrt.dll?  

    – the one that comes with 2000, if it has one?  

    – vista?

    – 7?

    – 8?

    also, for dependentAssembly, is this where I include <file name="msvcrt.dll"/> and other dll's I should require?  please don't tell me to use mt.exe.  is it actually necessary to do <file name="msvcrt.dll"/> itself?  where do I find the file attributes for msvcrt.dll that comes with the OS?  does it change with each OS?

  8. ScotBr-MSFT says:

    Jim,

    The manifests are for use with the "side by side" installations of the CRT (and MFC, ATL, etc.).  It is not necessary or appropriate to use manifests for ancient VC6 programs.  The msvcrt.dll that comes with the OS is really mostly for OS use, although legacy VC6 apps should still work with it.

    Upgrade to VC++ 10 (VS 2010) and you can skip over all the headache of manifests AND get a highly superior C++ compiler and set of libraries.