Troubleshooting Manifest-Related Issues

Artikel
02/18/2009

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.

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:

</dependentAssembly>

</dependency>

</dependentAssembly>

</dependency>

</dependentAssembly>

</dependency>

</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

Anonymous
February 18, 2009
First, thanks for the information. Can't we just add _BIND_TO_CURRENT_VCLIBS_VERSION to Preprocessor Definitions of the project itself?
Anonymous
February 20, 2009
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.
Anonymous
May 12, 2009
Can't we use WinSxS with Win XP SP3 ?
Anonymous
May 13, 2009
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
Anonymous
May 19, 2009
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!
Anonymous
June 22, 2009
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
Anonymous
February 10, 2012
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?

Anonymous
February 11, 2012
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.

Freigeben über

Comments

Zusätzliche Ressourcen