Home Dashboard Directory Help
Search

VC9 SP1 generates manifests with the wrong version number by dcon


Status: 

Closed
 as By Design Help for as By Design


32
0
Sign in
to vote
Type: Bug
ID: 361682
Opened: 8/13/2008 11:26:11 AM
Access Restriction: Public
3
Workaround(s)
view
26
User(s) can reproduce this bug

Description

After install SP1, the version number in the generated manifest is '9.0.21022.8' for the CRT and MFC. However the version in the redist directory is '9.0.30729.1'.

Executables distributed with side-by-side dlls using the redist now fail to run. (This used to work in VS2008 with the Feature Pack)

Note: If you change the project to not embed the manifest, and then manually change the version number in the manifest after compilation, the resulting exe will run with the redist dlls.
Details
Sign in to post a comment.
Posted by Morgan Larosa on 12/21/2011 at 5:36 PM
This should not be closed. It is a significant issue - the functionality in VS2008SP1 which generates the manifests for embedding was obviously not updated to reflect the CRT/MFC version bundled with SP1 redist, which means that the redist and any applications built using auto-generated manifests are now mutually incompatible.

Having to manually create correct manifests is not a feasible workaround, nor is manually modifying the corresponding redist manifests to trick SxS into thinking it has the older CRT/MFC version.

Fix this.
Posted by rajpraba on 4/7/2011 at 10:28 AM
This is a blatant bug.
The only workaround is modifying the local manifest files distributed with our application '9.0.21022.8' instead of its real version number by fooling our application. or manually edit the exe in the resource editor and modify the version in the embedded manifest. both are crude fix. Why not MS provide some decent fix?
Posted by TonyAA on 8/30/2010 at 7:21 PM
I am shocked that this has been closed by design. Did the product team understand the issue?
I create an app which manifest version for CLR and MFC will not match the redist manifests - all from the same product version!!!

How can this be by design?
Posted by Francesco Montorsi on 2/28/2010 at 12:35 PM
I got this sort of problem today.
My Microsoft Visual Studio 2008 Version 9.0.30729.1 SP outputs manifest files with version="9.0.21022.8" in the <assemblyIdentity> tag (even if the CRT dlls which are in "Microsoft Visual Studio 9.0\VC\redist\x86\Microsoft.VC90.CRT" are version "9.0.30729.1").
This is with MSVC Professional edition. Also note that when generating x64 executables instead of win32 ones, this behaviour is ok since the CRT dlls which are in "Microsoft Visual Studio 9.0\VC\redist\amd64\Microsoft.VC90.CRT" are version "9.0.21022.8".

To solve the problem I just told MSVC to _not_ embed manifests and then I edited the manifest files manually replacing the wrong version with the right one.
Posted by swider1235 on 1/23/2010 at 1:16 AM
Hi Maciej if it's possible contact us (me & raj) @IRC channel.
Posted by Maciek Siemczyk on 10/27/2009 at 7:09 AM
Okay, I fixed it by removing _BIND_TO_CURRENT_MFC_VERSION and _BIND_TO_CURRENT_CRT_VERSION flags and using older versions.
Posted by Maciek Siemczyk on 10/27/2009 at 6:08 AM
I'm having the same problem with my managed C++ wrapper for unmanaged C++, I'm sick of this already. In debug mode my manifest is correct and my dll runs. In release mode i have double entries for both CRT and MFC. This used work fine before upgrading VS and VC.

Why is this closed?

I guess M$ does not care about its customers. I spent over week now trying to get this to work and I really don't know what else to say.
Posted by Craig Holmquist on 8/7/2009 at 11:51 AM
The problem is that none of the CRT header files include this line:

#pragma comment(linker, "/include:__forceCRTManifestCUR")

MFC has this line in afx.h:
#pragma comment(linker, "/include:__forceMFCManifestCUR")

which is why this issue only applies to the CRT. In the CRT source, there is code for this pragma in crtdefs.h, but the actual CRT include folder has a different version of crtdefs.h which doesn't include the pragma. I've posted a workaround for this.

This issue is NOT fixed.
Posted by Jerica Truax on 8/3/2009 at 12:12 PM
I'm having a problem loading a C++/CLI wrapper DLL that wraps unmanaged C++ in a C# application and I'm seeing this issue as well. Not sure if it's the only reason I'm unable to load the DLL but until I can get it to work around, I won't be able to know for sure.
Posted by yuriy-k on 7/10/2009 at 9:35 AM
Totally agree - the issue with mixed versions is still there. Was this really by design?
Posted by SimonMichael on 5/14/2009 at 12:49 AM
This issue is still occurring. I can easily recreate it and I do not understand why microsoft have closed this issue.
We have over 80 projects in our solution and making the 'workaround' changes will require 2 man days...
Posted by Microsoft on 1/3/2009 at 3:39 PM
Hi dcon,

It is better sometimes to define the bind macros at the command-line level (/D) rather than in a header file to guarantee early definition.

Thank you,
George Mileka
Visual C++ Libraries
Posted by dcon on 8/28/2008 at 4:09 PM
If I'm distributing to a new machine, there are _no_ mfc dlls (vc9). So I _must_ distribute the new ones. Besides, if I compile against the new ones and use new features in them, then assuming the olds are on the target machine, I have now guaranteed that my app will crash if I use the old ones. How can that possibly be 'as designed'?

FYI: Just ran into more problems with _BIND_TO_CURRENT_VCLIBS_VERSION -> Create a new configuration for 'Itanium' and with the macro defined. The exe/dll won't even link (feedback 364383)
Posted by John Dallman on 8/28/2008 at 6:29 AM
This is the same issue as my feedback 361473, which has been closed as "working as designed". The idea is that you don't need to distribute the new libraries, because the old ones will still work, which rather begs the question of why they bothered distributing the new ones. The blog posting that explains the idea is at http://blogs.msdn.com/vcblog/archive/2008/05/15/vc-runtime-binding.aspx.
Posted by dcon on 8/21/2008 at 12:01 PM
Steps to reproduce:
- Create a new ATL project
- server type: dll
- allow merging of proxy/stub code
- support mfc
- Modify stdafx.h to include "#define _BIND_TO_CURRENT_VCLIBS_VERSION 1"
= Compile
- The manifest now contains references to both versions of the CRT
Posted by dcon on 8/21/2008 at 9:50 AM
Ah ha - I figured out how this happened - my project is not using precompiled headers. So the BIND macro wasn't set in the .c file (it was only set in the single .cpp file). Forcibly setting this in the .c file removed the dual CRT references.

It seems that having dual references in the manifest should be an error rather than compiling and giving the impression that the everything is ok.
Posted by Microsoft on 8/21/2008 at 1:13 AM
Hi dcon,

Thanks for your feedback.

In order to fix the issue, we must first reproduce the issue in our labs. You said that the CRT contains both the current version and the 21022 version. we can't reproduce that.

Could you please upload a zipped project file to help us reproduce the issue? or give us detailed repro steps and some screenshots.

Thanks again for your efforts and we look forward to hearing from you.
Visual Studio Product Team
Posted by dcon on 8/15/2008 at 10:13 AM
I tried using _BIND_TO_CURRENT_VCLIBS_VERSION to work around this - this produces an executable that will not run on the targetted machine. Also using _BIND_TO_CURRENT_MFC_VERSION and _BIND_TO_CURRENT_CRT_VERSION do not work.
The MFC entry in the manifest is correct, however the CRT contains both the current version and the 21022 version. Manually removing the 21022 entry allows the executable to work properly with the dlls/manifests from the redist directory.
Posted by Yuguang on 8/14/2008 at 1:59 AM
It's an old bug.
It's also exist in vs2008 feature pack.
The feature pack's version is 9.00.30304.0, and the myexe.exe's manifest is 9.0.21022.8.

There are 3 workaround solutions:
1, Change myexe.exe's manifest version to 9.0.30729.1. I guest no one want to do it, project maybe includes 10+ dll/exe.
2, Use RTM's VC\redist\x86\Microsoft.VC90.CRT. The myexe.exe would load old runtime dll, God knows what will happen.
3, Use SP1's VC\redist\x86\Microsoft.VC90.CRT\*.dll, but use VC\redist\x86\Microsoft.VC90.CRT\RTM's Microsoft.VC90.CRT.manifest.
It works. The myexe.exe load the new dll. Again, God knows what will happen.
Posted by Microsoft on 8/13/2008 at 10:53 PM
We were able to reproduce the issue you are seeing. We are escalating this bug to the product unit who works on that specific feature area. The product team will review this issue and make a decision on whether they will fix it or not for the next release
Posted by dcon on 8/13/2008 at 3:19 PM
I just found another workaround: in the .manifest files that go with the CRT/MFC files, change the version number in those to '9.0.21022.8'. (I discovered the files used with the feature pack used that version in the manifest even tho the version of the dll is greater)
Sign in to post a workaround.
Posted by Craig Holmquist on 8/7/2009 at 11:47 AM
To workaround the "multiple CRT versions in manifest" issue, you can add this linker option:

/include:__forceCRTManifestCUR

With either project settings or a comment pragma.
Posted by Yuguang on 8/14/2008 at 8:52 PM
Another workaround is
add such line in every stdafx.h.
#define _BIND_TO_CURRENT_VCLIBS_VERSION 1

looks like:
#pragma once
#define _BIND_TO_CURRENT_VCLIBS_VERSION 1
.....
Posted by Yuguang on 8/14/2008 at 2:01 AM
It's an old bug.
It's also exist in vs2008 feature pack.
The feature pack's version is 9.00.30304.0, and the myexe.exe's manifest is 9.0.21022.8.

There are 3 workaround solutions:
1, Change myexe.exe's manifest version to 9.0.30729.1. I guest no one want to do it, project maybe includes 10+ dll/exe.
2, Use RTM's VC\redist\x86\Microsoft.VC90.CRT. The myexe.exe would load old runtime dll, God knows what will happen.
3, Use SP1's VC\redist\x86\Microsoft.VC90.CRT\*.dll, but use VC\redist\x86\Microsoft.VC90.CRT\RTM's Microsoft.VC90.CRT.manifest.
It works. The myexe.exe load the new dll. Again, God knows what will happen.