After the Feature Pack release, I noticed that the manifests of the new MFC dll's had not been updated. They were still mentioning the old version (9.0.21022.8) as reported here.
Now, after the Feature Pack refresh, the version number in C:\Program Files\Microsoft Visual Studio 9.0\VC\redist\x86\Microsoft.VC90.MFC\Microsoft.VC90.MFC.manifest is correct (9.0.30411.0) but I have an error when deploying my application: it doesn't run because of missing DLL.
After setting the manifest generation to an external file (myapp.exe.manifest) rather than embed in the exe, I saw that:
<?xml version='1.0' encoding='UTF-8' standalone='yes'?>
<assembly xmlns='urn:schemas-microsoft-com:asm.v1' manifestVersion='1.0'>
<requestedExecutionLevel level='asInvoker' uiAccess='false' />
<assemblyIdentity type='win32' name='Microsoft.VC90.CRT' version='9.0.21022.8' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' />
<assemblyIdentity type='win32' name='Microsoft.VC90.MFC' version='9.0.21022.8' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' />
If I manually correct the version in my app's manifest to match the version of the MFC dll's manifest, it works like before.
So my question is: how do I get Visual Studio to generate the correct manifest file for my app ?
The manifest file contents is generated from #pragma comment(linker, ...) statements in the header files. Check which mfcassem.h gets included by your project, use /showIncludes to be sure. I did see another post in this forum this week that talked about hanky-panky going on with this. Hope you can find it back.
Ok, that solved my problem.
Just for the record, here's the relevant part in MFCassem.h:
#define _MFC_ASSEMBLY_VERSION "9.0.30411.0"
#define _MFC_ASSEMBLY_VERSION "9.0.21022.8"
nobugz, yeah that was actually the way they had it set up in VC2005 SP1, they had a define named _USE_RTM_VERSION. Didn't work too well with regular DLLs though, only EXEs (a bug filed by me but closed as won't fix)
Here's the explanation of why they changed it (given to me by Microsoft), but unfortunately no documentation exists for this change, nor how to use it, not to mention there are many problems with these defines in various circumstances (/clr, regular DLL, etc, all are recent feature pack bugs filed by me and others on connect.microsoft.com, that have been now listed as being fixed in VC 2008 SP1 which is not out yet).
The user ability to choose whether to bind to the RTM version or the most recent version of the libraries is necessary in servicing for two different scenarios:
1. Scenario 1:
a. A user finds a problem with the VC libraries. The problem affects his product behavior.
b. The user gets a QFE from MS with the fix, so that his product works properly.
c. The user builds his product and ships this way.
In this scenario, that user’s product should be dependent on the QFE because that’s what’s been tested to be working.
2. Scenario 2:
a. A user installs RTM.
b. The user builds his product and ships to his customers.
c. SP1 is released, so the user goes and installs it. He might install it because it has fixes to the IDE for example – but nothing in libraries for example.
d. The user now wants to service a dll in his product with a fix that is unrelated to the VC libraries.
e. The user re-builds his dll with the new toolset.
f. The user packages the new dll and send it to his customers.
In this scenario, the user does not really depend on the new VC libraries, they just happen to be there. When he ships his product update, he does not want to redistribute the VC libraries again. So, his new dll must depend on RTM only.
In VS2005, the default (out of the box after installing a QFE or SP1) is Scenario #1.
In VS2008, the default is Scenario #2.
The reason we have switched the default behavior is that Scenario #2 is way more common than Scenario #1 – this is based on customer feedback.
One can argue that we could have had different defaults based on the release context (QFE vs. SP1), but we think this will be very confusing for users than just sticking with one policy for everything.
What you are seeing with the Feature Pack is the new expected behavior: basically, out of the box after installing an update, no new dependencies.
DLL Hell just isn't going away, is it. This is partly self-inflicted pain too by not being ready when VS2008 shipped. That blog post is certainly warranted, I hope enough customers can find it after a fruitless search through the MSDN library.
We'll be answering this question for a while to come. If you can cut-and-paste a post together about it, I'll make it sticky.