还是那个宏的问题,早在2008年就发现了这个问题,当时还是MFC feature pack,就是要在
#pragma once
#define _BIND_TO_CURRENT_VCLIBS_VERSION 1
现在转下其它TX的发现之旅和解决之道:
再谈manifest version
[附注,这个问题在msdn 2008 sp1中有提及，ms-help://MS.MSDNQTR.v90.en/dv_vccore/html/43bcd98a-b0f7-4b3b-aea3-7a0f87f2887b.htm]
昨天我在visual c++ team blog上发了一个留言，结果今天有一个回复
Thursday, August 14, 2008 11:12 AM by Ted.
# re: Bugs fixed in MFC in Visual Studio 2008 SP1
yuguang.hu - read this blog entry
http://blogs.msdn.com/vcblog/archive/2008/05/15/vc-runtime-binding.aspx
the real solution for you is (which I'm happy to say actually works in SP1) is to:
#define _BIND_TO_CURRENT_VCLIBS_VERSION 1
near the top of your stdafx.h
我测试了这个回复中提到的方法，的确可行，这个define会导致build出来的myexe.exe的manifest的version是9.0.30729.1。
这个回复指向了一个link，这个link值得仔细阅读。这个link里面的回复也值得仔细阅读。简要概述这个link如下：
有2种选择：
1，link RTM runtime
2，link Current runtime
vs2008选择了缺省是1，vs2005选择缺省是2。
在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 目录。可是那个目录已经被覆盖了。
为备份，附注该link如下：
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.
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.
Published Thursday, May 15, 2008 5:04 PM by vcblog
Comments
Friday, May 16, 2008 6:09 AM by Toma Bussarov
# 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!
Friday, May 16, 2008 11:04 AM by Ted.
# 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.
Saturday, May 17, 2008 2:39 AM by Toma Bussarov
# re: VC Runtime Binding...
Thank you for the comprehensive answer!
Saturday, May 17, 2008 12:44 PM by Jochen Kalmbach
# 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
!?
Tuesday, May 20, 2008 3:22 PM by Ted.
# 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"
Thursday, May 22, 2008 4:41 AM by Liveck
# re: VC Runtime Binding...
Supposing u wouldn't mind, I've translated this into chinese and put it on my blog.
Wednesday, June 04, 2008 8:36 AM by Alex
# 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?
Thursday, June 05, 2008 3:29 PM by grmileka
# 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
Friday, June 06, 2008 4:19 AM by Alex
# 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.
Friday, June 06, 2008 4:34 AM by Alex
# 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.
Monday, June 16, 2008 5:01 PM by Alex
# 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).
Thursday, June 19, 2008 12:54 PM by Alex