Understand Manifest Version
VC Runtime Binding...
Hello, I am George Mileka, a developer on the Visual C++ Libraries Team. After we released the Visual C++ 2008 Feature Pack back in April, we got a lot of useful feedback from MVPs and customers. One of the areas that definitely needed clarification is the version dependency embedded in the generated manifest.
The question goes like this:
Why does the VS team provide two options:
(1) bind the application to the RTM version of the VC runtimes.
(2) bind the application to the current version of the VC runtimes.
And what is the default behavior?
Before going into why each case can be useful, I'd like to emphasize something...
The policy redirection provided by VC redirects application requests for older versions to newer ones (for a given servicing baseline*, and after applying the <app>.config file if present**).
This means that:
- an application that binds to the RTM version of the libraries can be directed to RTM or later (if a newer runtime is installed).
- an application that binds to the current version of the libraries can be directed to the current version (or later version when a newer version is released).
Now - back to answering the question.
Option (1) is useful for the following scenario:
- Alan installs the RTM product and uses it to develop his product.
- Alan builds his product and ships the VC runtime dlls he has along with it (RTM ones).
- Microsoft releases VS SP1, and the user installs it to get a fix for a non-libraries related issue (perf improvement in some area for example).
- Alan finds a bug in his own product and decides to fix it, rebuild his binaries and ship a patch for his customers.
In this scenario, Alan does not really care about the newer VC runtime dlls. Alan should be able to rebuild his binaries, and hand them to customers without having to redistribute the VC runtime. To decouple the new application binaries from the new VC runtime dlls, the user chooses to bind to the RTM version of the VC runtime dlls.
Option (2) is useful for the following scenario:
- Jim installs the RTM product and uses it to develop his product.
- Jim finds a problem with the VC libraries. The problem affects his product behavior.
- Jim asks Microsoft for a fix (a QFE) so that his product works properly.
- Microsoft fixes the problems and hands Jim a QFE with the fix. The QFE contains new headers/libraries/runtime dlls.
- Jim builds his product and ships the VC runtime dlls he got through the Microsoft QFE.
In this scenario, Jim’s product correct behavior is dependent on the newer runtime dlls. Jim prefers that his application does not start at all rather than starting and inhibiting incorrect behavior. Jim can enforce that by binding to the QFE version of the runtime dlls.
In VS2005, the default (out of the box after installing SP1) is Scenario #2.
In VS2008, the default is Scenario #1.
Note:
在vs2008如果要使用#2，应该在stdafx.h的最上面定义
#define _BIND_TO_CURRENT_MFC_VERSION 1
#define _BIND_TO_CURRENT_CRT_VERSION 1
另外有一个_BIND_TO_CURRENT_VCLIBS_VERSION，但这个定义有bug，据说sp1将修复。
注意这依然是一个bug。考虑一个新手，他用app wizard生成了一个project并且编译，他是无法发布的，除非他加了这行define。而且所有没加这行define的project都无法发布，除非他们发布老的runtime 目录。可是那个目录已经被覆盖了。
The reason we have switched the default behavior is that (based on customer feedback) scenario #1 is way more common than scenario #2.
One can argue that we could have had different defaults based on the release context (QFE vs. SP1), but we think this will be more confusing than just sticking with one policy for everything.
Please, let me know if you have any questions…
George Mileka
Visual C++ Development Team
* A “servicing baseline” can be VS RTM, VS SP1, etc.
** The <app>.config can be used to disable the central policy altogether – or it can map the application request to something else before the central policy is applied.
Comments
# re: VC Runtime Binding...
How can I switch binding to SP1 libraries from the development environment?
You have described in detail the default behavior, but not how to change it!
# re: VC Runtime Binding...
To change the bindings in the Feature pack version you need to define
_BIND_TO_CURRENT_MFC_VERSION 1
and
_BIND_TO_CURRENT_CRT_VERSION 1
in your stdafx.h (near the top)
(there is another define named _BIND_TO_CURRENT_VCLIBS_VERSION which was supposed to be the thing to use but it has various bugs that will be addressed in SP1 so do NOT use it with the feature pack).
Secondly the defines I mentioned to not work very well with regular MFC DLLs and the /clr option. Again, these problems will be addressed in SP1, and there are workarounds if you need them.
# re: VC Runtime Binding...
Thank you for the comprehensive answer!
# re: VC Runtime Binding...
Hi!
Can you please give us an example of this
Quote:
The <app>.config can be used to disable the central policy altogether
!?
# re: VC Runtime Binding...
Jochen, see this link for app specific local policy (apparently doesn't work fully Win2003 Server without extra step !!!), see the text in the following link that is just below the part that says "customer's issue"
http://www.microsoft.com/communities/newsgroups/en-us/default.aspx?dg=microsoft.public.vc.mfc&tid=ab5bc68a-3bf1-4537-9285-5697048f13ed&cat=&lang=&cr=&sloc=&p=1
# re: VC Runtime Binding...
Supposing u wouldn't mind, I've translated this into chinese and put it on my blog.
# re: VC Runtime Binding...
While porting an existing VS 2005 project (ATL, ATL Server and WTL, no MFC) to VS 2008 + Feature Pack found a following problem:
If I #define _BIND_TO_CURRENT_CRT_VERSION 1, an executable gets two references to VC90 CRT runtime in its embedded manifest - to the old one and to the new one (shipped with feature pack). Several forum threads in MSDN discuss this issue regarding MFC regular DLLs, but all offered workarounds failed.
I've even tried to compile with /EP /P to get a preprocessed output to find where it tries to reference an old library and found nothing.
The issue is still unresolved. Anyone managed to successfully resolve it?
# re: VC Runtime Binding...
Alex,
Are linking with 3rd party libraries?
If the 3rd party libraries got built with VS2008 RTM, they can have references to the RTM CRT.
One way to track those issues down is to do a findstr on the unwanted version. This will give you the file - and from there you can track it back to the build/environment etc.
Please, let us also know you can repro this with a new project (or a smaller repro).
thanks,
George Mileka
Visual C++ Libraries
# re: VC Runtime Binding...
George,
Thank you for the prompt reply.
The project is quite a big one, includes several projects, but all externally used libraries are template libraries and are include-only (like Boost, ATL Server, WTL and several home-grown ones).
Just compiled the project with /EP /P again and here's lines that relate to CRT versioning I think:
#pragma comment(linker, "/include:__forceCRTManifestCUR")
#pragma comment(linker,"/manifestdependency:""type='win32' " "
"name='" "Microsoft.VC90" ".CRT' " "
"version='" "9.0.30411.0" "' " "
"processorArchitecture='x86' " "
"publicKeyToken='" "1fc8b3b9a1e18e3b" "'""")
#pragma comment(linker, "/include:??3@YAXPAX@Z")
#pragma comment(linker,"/manifestdependency:""type='win32' " "
"name='" "Microsoft.VC90" ".CRT' " "
"version='" "9.0.30411.0" "' " "
"processorArchitecture='x86' " "
"publicKeyToken='" "1fc8b3b9a1e18e3b" "'""")
(This is from stdafx.i, all other *.i files contain the same lines). And yes, the /manifestdependency occurs twice in each .i file.
I've also used Find in Files to search for unwanted "21022" (both ANSI and UNICODE) in the $(IntDir) with only two occurrences: in .intermediate.manifest and .pch files (in the last one as part of the following string: "_MSC_FULL_VER=150021022").
I'll try with a smaller project and describe the results in the next post.
# re: VC Runtime Binding...
Damn, in fact you were right... Several projects in the solution have dependencies (static) on zlib library, which is part of solution too and which is built with it... and for which I forgot to set the #define!!!
I'm very sorry for the confusion. Maybe it would be better to delete my previous post.
George, I want to thank you again for a quick and helpful hint.
# re: VC Runtime Binding...
I am also having a problem with manifest having references to both runtimes. In my case it is an mixed-mode assembly (/clr).
# re: VC Runtime Binding...
George,
In this thread http://forums.msdn.microsoft.com/en-US/vcgeneral/thread/1c038102-896c-4b0a-974b-83d2e490386d/ Ted suggests to contact you directly for resolution with /clr. How do I contact you directly? My e-mail alex.ivanoff at shavlik.com
# About manifest version
[转载自：http://alpha.oopslab.net/2008/08/15/再谈manifest-version/] 再谈manifestversion
...