views:

47

answers:

1

Hi,

I am having a problem with building an application in Visual Studio 2008. I have declared the following in my project properties:

_BIND_TO_CURRENT_MFC_VERSION=1 _BIND_TO_CURRENT_CRT_VERSION=1 _BIND_TO_CURRENT_ATL_VERSION=1

When I build my application in VS2008 it generates an intermediate.manifest file which contains:

<dependentAssembly>
  <assemblyIdentity type='win32' name='Microsoft.VC90.CRT' version='9.0.30729.1' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' />
</dependentAssembly>

Now, this machine has newer C runtime DLLs installed (version 9.0.30729.4148 can be found in the WinSxS folder). The pre processor definitions above are supposed to tell VS to use the latest runtime DLLs, but it doesn't appear to be doing so. Is anyone able to explain why dev studio won't show the newer version of these DLLs in the manifest? I can build the same application on other machines and get the right number in the manifest file, so it must be something peculiar to the setup of this one machine, but I don't know what.

The machine where I am having the problem is a Windows 2003 SP2 server. Can anyone shed any light on how dev studio works out what the latest runtime version is?

Thanks, Al.

A: 

You indeed have an old version of the CRT. The version number is set in the vc\include\crtassem.h include file. Windows Update should have given you the security update that was released in July of last year. It also updates the CRT .h and .lib files. Maybe you got that release from an installer of another program.

If you don't want to turn on Windows Update then you can get the security update from here. Beware that the download it starts is rather large.

Hans Passant
Hans - thanks for that link, have installed the redist update on my windows 2003 server but the crtassem.h file remains the same, with 30729.1 as the assembly version. I have VS2008 installed on the D drive on this server rather than the more normal C, surely that couldn't be the problem, could it?
Al Henderson
I don't know. Sounds as good as an explanation as any.
Hans Passant
I have manually editted the crtassem.h in my VC\include folder to update the _CRT_ASEMBLY_VERSION definition to 9.0.30729.4148 and that results in the correct runtime version being put in the manifest file. Not entirely happy about manually editting system include files, but I don't appear to have a lot of choice. Think I'll copy the crtassem.h (and mfcassem.h as well, to get that reference right) from a machine that has had it correctly applied. Thanks for your help! Al.
Al Henderson
Yuck, don't do this. You've screwed up the timestamp on the .h file, any future update won't be able to update that file. And you're still deploying a CRT version to your customers that has the security flaw, they won't be pleased if they find out.
Hans Passant
I'm not deploying the CRT, just trying to target the 4148 version which my InstallShield is deploying. As for the header files, I don't see what other option I have if the security update is failing to update them correctly..
Al Henderson
Of course, there are the libs that need updating as well, the header files are only part of the problem. Guess I need to figure out how to make vcredist_x86 work.. :-(
Al Henderson
Al Henderson