Visual Studio 9 including the wrong CRT assembly.

[Chris Becke]

Visual Studio 9 seems to have two parallel, but conflicting systems, for
defining the CRT assembly to link in.

With VS9 SP1 installed:

_BIND_TO_CURRENT_CRT version drives the definition of
_CRT_ASSEMBLY_VERSION, which is used in a #pragma to set a
/manifestdependency linker option.

// snip from crtassem.h
#ifndef _CRT_ASSEMBLY_VERSION
#if _BIND_TO_CURRENT_CRT_VERSION
#define _CRT_ASSEMBLY_VERSION "9.0.30729.1"
#else
#define _CRT_ASSEMBLY_VERSION "9.0.21022.8"
#endif
#endif

It ALSO drives the inclusion of a #pragma that does a /INCLUDE on
_forceCRTManifestRTM or _forceCRTManifestCUR - which link in object code
containing an embedded /manifestdependency entry.

Now, the problem is, There was a security fix, and the current version
of the VC9 runtime is "9.0.30729.4148".

We added '_CRT_ASSEMBLY_VERSION=\"9.0.30729.4148\"' to our project
settings, which causes the resulting app manifest to contain references
to both the 9.0.21022.8 AND 9.0.30729.4148 runtimes.

(Setting _BIND_TO_CURRENT_CRT_VERSION just changes the problem to be
both 9.0.30729.1 and 9.0.30729.4148).

The only way to "fix" this issue so far is to add

extern "C" int _forceCRTManifestRTM=0;
extern "C" int _forceCRTManifestCUR=0;

to one of our cpp files to ... unforce the inclusion of the cpp files
containing the dodgey #pragma's.

The other option is to turn off manifest generation, and simply include
a hand crafted one, but given the number of settings in manifests
nowadays that are configured via property pages, bypassing the
generation seems a very bad long term solution.

It is important to us to have the manifest file explicitly ask for the
4148 build as we are shipping the runtime as a private assembly, and we
obviously want to ship the latest version. (Version checks are done for
private assemblies.)

Am I missing something, or is this hackish solution really the only way
to get the generated manifests to link vs the correct "Microsoft.VC90"
assembly?

[Chris Becke]

Post by Chris Becke
Visual Studio 9 seems to have two parallel, but conflicting systems, for
defining the CRT assembly to link in.
_BIND_TO_CURRENT_CRT version drives the definition of
_CRT_ASSEMBLY_VERSION, which is used in a #pragma to set a
/manifestdependency linker option.
// snip from crtassem.h
#ifndef _CRT_ASSEMBLY_VERSION
#if _BIND_TO_CURRENT_CRT_VERSION
#define _CRT_ASSEMBLY_VERSION "9.0.30729.1"
#else
#define _CRT_ASSEMBLY_VERSION "9.0.21022.8"
#endif
#endif
It ALSO drives the inclusion of a #pragma that does a /INCLUDE on
_forceCRTManifestRTM or _forceCRTManifestCUR - which link in object code
containing an embedded /manifestdependency entry.
Now, the problem is, There was a security fix, and the current version
of the VC9 runtime is "9.0.30729.4148".
We added '_CRT_ASSEMBLY_VERSION=\"9.0.30729.4148\"' to our project
settings, which causes the resulting app manifest to contain references
to both the 9.0.21022.8 AND 9.0.30729.4148 runtimes.
(Setting _BIND_TO_CURRENT_CRT_VERSION just changes the problem to be
both 9.0.30729.1 and 9.0.30729.4148).
The only way to "fix" this issue so far is to add
extern "C" int _forceCRTManifestRTM=0;
extern "C" int _forceCRTManifestCUR=0;
to one of our cpp files to ... unforce the inclusion of the cpp files
containing the dodgey #pragma's.
The other option is to turn off manifest generation, and simply include
a hand crafted one, but given the number of settings in manifests
nowadays that are configured via property pages, bypassing the
generation seems a very bad long term solution.
It is important to us to have the manifest file explicitly ask for the
4148 build as we are shipping the runtime as a private assembly, and we
obviously want to ship the latest version. (Version checks are done for
private assemblies.)
Am I missing something, or is this hackish solution really the only way
to get the generated manifests to link vs the correct "Microsoft.VC90"
assembly?

um, so, how are we supposed to target the Microsoft.VC90.CRT SP1.1
runtime then?

(Is this the wrong newsgroup for this question? The managed groups don't
list nntp forums for Visual C++ support, and the email address im using
here IS my msdn subscriber registered one).

[Chris Becke]

perhaps if I use a different email address.

Post by Chris Becke

Post by Chris Becke
Visual Studio 9 seems to have two parallel, but conflicting systems, for
defining the CRT assembly to link in.
_BIND_TO_CURRENT_CRT version drives the definition of
_CRT_ASSEMBLY_VERSION, which is used in a #pragma to set a
/manifestdependency linker option.
// snip from crtassem.h
#ifndef _CRT_ASSEMBLY_VERSION
#if _BIND_TO_CURRENT_CRT_VERSION
#define _CRT_ASSEMBLY_VERSION "9.0.30729.1"
#else
#define _CRT_ASSEMBLY_VERSION "9.0.21022.8"
#endif
#endif
It ALSO drives the inclusion of a #pragma that does a /INCLUDE on
_forceCRTManifestRTM or _forceCRTManifestCUR - which link in object code
containing an embedded /manifestdependency entry.
Now, the problem is, There was a security fix, and the current version
of the VC9 runtime is "9.0.30729.4148".
We added '_CRT_ASSEMBLY_VERSION=\"9.0.30729.4148\"' to our project
settings, which causes the resulting app manifest to contain references
to both the 9.0.21022.8 AND 9.0.30729.4148 runtimes.
(Setting _BIND_TO_CURRENT_CRT_VERSION just changes the problem to be
both 9.0.30729.1 and 9.0.30729.4148).
The only way to "fix" this issue so far is to add
extern "C" int _forceCRTManifestRTM=0;
extern "C" int _forceCRTManifestCUR=0;
to one of our cpp files to ... unforce the inclusion of the cpp files
containing the dodgey #pragma's.
The other option is to turn off manifest generation, and simply include
a hand crafted one, but given the number of settings in manifests
nowadays that are configured via property pages, bypassing the
generation seems a very bad long term solution.
It is important to us to have the manifest file explicitly ask for the
4148 build as we are shipping the runtime as a private assembly, and we
obviously want to ship the latest version. (Version checks are done for
private assemblies.)
Am I missing something, or is this hackish solution really the only way
to get the generated manifests to link vs the correct "Microsoft.VC90"
assembly?

um, so, how are we supposed to target the Microsoft.VC90.CRT SP1.1
runtime then?
(Is this the wrong newsgroup for this question? The managed groups don't
list nntp forums for Visual C++ support, and the email address im using
here IS my msdn subscriber registered one).

[Chris Becke]

Post by Chris Becke

Post by Chris Becke
Visual Studio 9 seems to have two parallel, but conflicting systems, for
defining the CRT assembly to link in.
_BIND_TO_CURRENT_CRT version drives the definition of
_CRT_ASSEMBLY_VERSION, which is used in a #pragma to set a
/manifestdependency linker option.
// snip from crtassem.h
#ifndef _CRT_ASSEMBLY_VERSION
#if _BIND_TO_CURRENT_CRT_VERSION
#define _CRT_ASSEMBLY_VERSION "9.0.30729.1"
#else
#define _CRT_ASSEMBLY_VERSION "9.0.21022.8"
#endif
#endif
It ALSO drives the inclusion of a #pragma that does a /INCLUDE on
_forceCRTManifestRTM or _forceCRTManifestCUR - which link in object code
containing an embedded /manifestdependency entry.
Now, the problem is, There was a security fix, and the current version
of the VC9 runtime is "9.0.30729.4148".
We added '_CRT_ASSEMBLY_VERSION=\"9.0.30729.4148\"' to our project
settings, which causes the resulting app manifest to contain references
to both the 9.0.21022.8 AND 9.0.30729.4148 runtimes.
(Setting _BIND_TO_CURRENT_CRT_VERSION just changes the problem to be
both 9.0.30729.1 and 9.0.30729.4148).
The only way to "fix" this issue so far is to add
extern "C" int _forceCRTManifestRTM=0;
extern "C" int _forceCRTManifestCUR=0;
to one of our cpp files to ... unforce the inclusion of the cpp files
containing the dodgey #pragma's.
The other option is to turn off manifest generation, and simply include
a hand crafted one, but given the number of settings in manifests
nowadays that are configured via property pages, bypassing the
generation seems a very bad long term solution.
It is important to us to have the manifest file explicitly ask for the
4148 build as we are shipping the runtime as a private assembly, and we
obviously want to ship the latest version. (Version checks are done for
private assemblies.)
Am I missing something, or is this hackish solution really the only way
to get the generated manifests to link vs the correct "Microsoft.VC90"
assembly?

um, so, how are we supposed to target the Microsoft.VC90.CRT SP1.1
runtime then?
(Is this the wrong newsgroup for this question? The managed groups don't
list nntp forums for Visual C++ support, and the email address im using
here IS my msdn subscriber registered one).

[Steven O]

Chris,

Did you ever find a solution to this problem? I also need to target the
9.0.30729.4148, and I am having the same problem. I am setting
_BIND_TO_CURRENT_CRT, and I am seeing the same problem.

The manifest inside of my executables reveals that it is depending on both
9.0.30729.4148 and 9.0.30729.1.

Thanks!

Post by Chris Becke

Post by Chris Becke
Visual Studio 9 seems to have two parallel, but conflicting systems, for
defining the CRT assembly to link in.
_BIND_TO_CURRENT_CRT version drives the definition of
_CRT_ASSEMBLY_VERSION, which is used in a #pragma to set a
/manifestdependency linker option.
// snip from crtassem.h
#ifndef _CRT_ASSEMBLY_VERSION
#if _BIND_TO_CURRENT_CRT_VERSION
#define _CRT_ASSEMBLY_VERSION "9.0.30729.1"
#else
#define _CRT_ASSEMBLY_VERSION "9.0.21022.8"
#endif
#endif
It ALSO drives the inclusion of a #pragma that does a /INCLUDE on
_forceCRTManifestRTM or _forceCRTManifestCUR - which link in object code
containing an embedded /manifestdependency entry.
Now, the problem is, There was a security fix, and the current version
of the VC9 runtime is "9.0.30729.4148".
We added '_CRT_ASSEMBLY_VERSION=\"9.0.30729.4148\"' to our project
settings, which causes the resulting app manifest to contain references
to both the 9.0.21022.8 AND 9.0.30729.4148 runtimes.
(Setting _BIND_TO_CURRENT_CRT_VERSION just changes the problem to be
both 9.0.30729.1 and 9.0.30729.4148).
The only way to "fix" this issue so far is to add
extern "C" int _forceCRTManifestRTM=0;
extern "C" int _forceCRTManifestCUR=0;
to one of our cpp files to ... unforce the inclusion of the cpp files
containing the dodgey #pragma's.
The other option is to turn off manifest generation, and simply include
a hand crafted one, but given the number of settings in manifests
nowadays that are configured via property pages, bypassing the
generation seems a very bad long term solution.
It is important to us to have the manifest file explicitly ask for the
4148 build as we are shipping the runtime as a private assembly, and we
obviously want to ship the latest version. (Version checks are done for
private assemblies.)
Am I missing something, or is this hackish solution really the only way
to get the generated manifests to link vs the correct "Microsoft.VC90"
assembly?

um, so, how are we supposed to target the Microsoft.VC90.CRT SP1.1
runtime then?
(Is this the wrong newsgroup for this question? The managed groups don't
list nntp forums for Visual C++ support, and the email address im using
here IS my msdn subscriber registered one).

.

[Steven O]

I figured it out. Here's what I did. I'm using Vista 32-bit. I build
64-bit executables, so the procedure should work on 64-bit OS's as well.

1. Uninstalled Visual Studio.

2. Uninstalled the KB97324 redistributable update.

3. Reinstalled Visual Studio.

4. Installed Visual Studio SP1
http://www.microsoft.com/downloads/details.aspx?FamilyId=FBEE1648-7106-44A7-9649-6D9F6D58056E&displaylang=en

5. Check for Windows updates. Got these updates:
--Security Update for Microsoft Visual Studio 2008 Service Pack 1 (KB971092)
--Security Update for Microsoft Visual Studio 2008 Service Pack 1 (KB972222)
--Security Update for Microsoft Visual Studio 2008 Service Pack 1 ATL for
Smart Devices(KB973675)
--Security Update for Microsoft Visual C++ 2008 Redistributable
Package(KB973924)

6. Open Program Files\Microsoft Visual Studio 9.0\VC\include\crtassem.h.
You should see these lines:
#ifndef _CRT_ASSEMBLY_VERSION
#if _BIND_TO_CURRENT_CRT_VERSION
#define _CRT_ASSEMBLY_VERSION "9.0.30729.4148"
#else
#define _CRT_ASSEMBLY_VERSION "9.0.21022.8"
#endif
#endif

7.Make sure that _BIND_TO_CURRENT_CRT_VERSION is defined in your project.
This is the only define you'll need.

8.Now, your manifest should contain a reference to CRT version
9.0.30729.4148. No other versions should be referenced.

If you are still seeing more than one CRT reference, try to create a simple
"Hello world" console app, and check its manifest. If the console app comes
up clean, your project may be linking with a static library that was built
with a different CRT version. If so, you'll have to rebuild the static
library with 9.0.30729.4148.

I hope this helps all of you guys in search engine land.

Steven

Post by Steven O
Chris,
Did you ever find a solution to this problem? I also need to target the
9.0.30729.4148, and I am having the same problem. I am setting
_BIND_TO_CURRENT_CRT, and I am seeing the same problem.
The manifest inside of my executables reveals that it is depending on both
9.0.30729.4148 and 9.0.30729.1.
Thanks!

Post by Chris Becke

Post by Chris Becke
Visual Studio 9 seems to have two parallel, but conflicting systems, for
defining the CRT assembly to link in.
_BIND_TO_CURRENT_CRT version drives the definition of
_CRT_ASSEMBLY_VERSION, which is used in a #pragma to set a
/manifestdependency linker option.
// snip from crtassem.h
#ifndef _CRT_ASSEMBLY_VERSION
#if _BIND_TO_CURRENT_CRT_VERSION
#define _CRT_ASSEMBLY_VERSION "9.0.30729.1"
#else
#define _CRT_ASSEMBLY_VERSION "9.0.21022.8"
#endif
#endif
It ALSO drives the inclusion of a #pragma that does a /INCLUDE on
_forceCRTManifestRTM or _forceCRTManifestCUR - which link in object code
containing an embedded /manifestdependency entry.
Now, the problem is, There was a security fix, and the current version
of the VC9 runtime is "9.0.30729.4148".
We added '_CRT_ASSEMBLY_VERSION=\"9.0.30729.4148\"' to our project
settings, which causes the resulting app manifest to contain references
to both the 9.0.21022.8 AND 9.0.30729.4148 runtimes.
(Setting _BIND_TO_CURRENT_CRT_VERSION just changes the problem to be
both 9.0.30729.1 and 9.0.30729.4148).
The only way to "fix" this issue so far is to add
extern "C" int _forceCRTManifestRTM=0;
extern "C" int _forceCRTManifestCUR=0;
to one of our cpp files to ... unforce the inclusion of the cpp files
containing the dodgey #pragma's.
The other option is to turn off manifest generation, and simply include
a hand crafted one, but given the number of settings in manifests
nowadays that are configured via property pages, bypassing the
generation seems a very bad long term solution.
It is important to us to have the manifest file explicitly ask for the
4148 build as we are shipping the runtime as a private assembly, and we
obviously want to ship the latest version. (Version checks are done for
private assemblies.)
Am I missing something, or is this hackish solution really the only way
to get the generated manifests to link vs the correct "Microsoft.VC90"
assembly?

um, so, how are we supposed to target the Microsoft.VC90.CRT SP1.1
runtime then?
(Is this the wrong newsgroup for this question? The managed groups don't
list nntp forums for Visual C++ support, and the email address im using
here IS my msdn subscriber registered one).

.