清单和VC8 [英] Manifests and VC8
问题描述
我刚刚在一台机器上安装了VS2005 RTM，该机器的*版本从未*具有任何价值的b $ b。它确实有VS2003，但我卸载了它。
我使用新的托管C ++语法构建了一个DLL。链接器生成了一个
清单，到目前为止一直很好。清单表明Microsoft.VC80.CRT版本8.0.50608.0存在依赖关系
。 （注意，我没有显示使用CRT的
，编译器正在添加依赖项，但是这个帖子中的问题不是
。）
当我运行使用此DLL的进程时，我得到一个FileNotFoundException。
％windir％\ WinSxS没有此特定版本的条目。我能找到的最近的
是
x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727。 42_x-ww_f75eb16c
请注意，这与
清单中的引用之间的唯一区别是版本。 （公钥令牌是相同的。）那么为什么
链接版本14.00.50727.42为非托管创建清单
不存在，并且从未存在过我的机器？
Richard
-
http://www.grimes.demon.co.uk/workshops/fusionWS.htm
http://www.grimes.demon.co.uk/workshops/securityWS.htm
Richard Grimes写道：我刚刚在一台机器上安装了VS2005 RTM任何测试版本。它确实有VS2003，但我卸载了它。
我使用新的托管C ++语法构建了一个DLL。链接器生成了一个
清单，到目前为止一直很好。清单表明Microsoft.VC80.CRT版本8.0.50608.0存在依赖性。 （注意，我没有明确使用CRT，编译器正在添加依赖项，但
这不是本文中的问题。）
当我运行一个进程时使用这个DLL我得到一个FileNotFoundException。
％windir％\ WinSxS没有这个特定版本的条目。
我最近找到的是
x86_Microsoft.VC80 .CRT_1fc8b3b9a1e18e3b_8.0.50727。 42_x-ww_f75eb16c
请注意，这与
清单中的引用之间的唯一区别是版本。 （公钥令牌是相同的。）那么为什么
链接版本14.00.50727.42为我的机器上不存在且从未存在过的非托管版本创建清单？
有趣。
我刚做了一个快速测试，创建了一个C ++类库和一个使用
$ b $的C＃应用程序那个图书馆。该应用程序运行得很好，但检查为C ++类库生成的文件，我看到一个清单，并且该清单确实有
版本50608.0在其中指定并且不是版本50727.42。
所以这里至少有两件我不理解的东西：
1.为什么清单中错误的内部编号？
2.为什么它对我有用，但对你不起作用，尽管编号错误？
我要去将这些问题转发给VC ++团队 - 这里有一些非常可疑的东西。
-cd
Carl Daniel [VC ++ MVP]写道：Richard Grimes写道：
很有意思。
我刚做了一个快速测试，创建一个C ++类库和一个使用该库的C＃应用程序。该应用程序运行得很好，但检查为C ++类库生成的文件，我看到一个清单，并且
清单确实有版本50608.0在其中指定而不是版本50727.42。
所以这里至少有两件我不明白的事情：
1.为什么清单中的错误编号？
2.为什么这样做为我工作，但不是为了你，尽管错误的建设
号码？
这里有更多信息。我在命令行编译，没有
预编译头文件（/ clr / LD / Zi / MDd）;我没有使用VS项目。
然后我为类库创建了一个VS项目，并编译为
Debug。我将这个新库复制到我的应用程序所在的文件夹中（一个简单的C＃进程），运行它，问题就消失了。
搜索VS构建输出日志差异似乎是
VC项目使用mt.exe嵌入清单，而我在命令行上没有这样做。所以我在命令
line上创建了我创建的库，并使用mt.exe将清单嵌入其中。该库现在已经加载了b $ b并且我没有收到任何错误。
在我看来，托管的C ++编译器如果不能成为无用的话
用于在命令行上构建库。我一直在使用它，因为
C / C ++ v7，据我所知，我已经能够编译并使用编译器链接一个DLL（cl。可执行程序）。版本14打破了这个，
因为要获得一个将加载的库我必须用
mt.exe按摩DLL。这是向后退一步的IMO。
我要把这些问题转发给VC ++团队 - 这里有一些非常可疑的东西。
谢谢，请做。看来，就.NET团队中的任何人而言，我都已经进行了预先沟通。 ： - （
Richard
-
http://www.grimes.demon.co.uk/workshops/fusionWS.htm
http://www.grimes.demon.co.uk/workshops/securityWS.htm
" Richard Grimes"< ri ****** @ mvps.org>写在消息中
news：eG ************** @ TK2MSFTNGP12.phx.gbl ...Carl Daniel [VC ++ MVP]写道：Richard Grimes写道：
有意思。
我刚刚做了一个快速测试，创建了一个C ++类库和一个使用该库的C＃应用程序。该应用运行得很好，但是检查为C ++类库生成的文件，我看到一个清单，而且
清单确实有版本50608.0在其中指定而不是版本50727.42。
所以至少有两件我不明白的事情：
1.为什么清单中的错误编号？
2.为什么它对我有用但不是对于你，尽管错误的构建
号码？
这里有更多的信息。我在命令行上编译，没有预编译的头文件（/ clr / LD / Zi / MDd）;我没有使用VS项目。
然后我为类库创建了一个VS项目，并编译为Debug。
我将这个新库复制到我的应用程序所在的文件夹中（一个简单的C＃
进程），运行它，问题就消失了。
通过VS构建输出日志搜索差异似乎是VC项目使用mt.exe嵌入清单，并且我在命令行上没有这样做。所以我在命令
行上创建了我创建的库，并使用mt.exe将清单嵌入其中。这个库现在已经加载了，我没有收到任何错误。
在我看来，如果无法用来构建一个c ++编译器，它就没用了命令行上的库。我一直在使用它，因为我知道我已经能够使用编译器（cl.exe）编译和链接一个DLL了。至于C / C ++ v7。版本14打破了这个，
因为要获得一个将加载的库我必须使用
mt.exe按摩DLL。这是向后退一步的IMO。
我要将这些问题转发给VC ++团队 - 这里有一些非常可疑的东西。
谢谢，请做。看来，就.NET团队中的任何人而言，我已经进行了预先沟通。 ： - （
这是我收到的回复：
< quote>
如您所示，外部清单文件或嵌入式清单中的版本将显示
8.0.50608.0。真正发生的是WinSxS上有政策
将这样的版本映射到8.0.50727.42的\policies目录。
这就解释了为什么即使你在生成清单时看到
中的不同版本它也能正常工作。
例如，使用/ MD构建一个简单的a.cpp应用程序将生成一个包含
< assemblyIdentity type =''win32的
清单''name =''Microsoft.VC80.CRT''
version ='''8.0.50608.0''processorArchitecture ='''x86''
publicKeyToken =''1fc8b3b9a1e18e3b ''/>
您在我的机器上运行应用程序时的政策
％windir％\ WinSxS \ POLEMENT \ x86_policy.8.0 .Microsoft.VC80。 CRT_1fc8b3b9a1e18e3b_x-ww_77c24773 \8.0.50727.4
2.policy（包含以下内容）将二进制文件指向新的
版本
< ; assemblyIdentity type =" win32" name =" Microsoft.VC80.CRT"
processorArchitecture =" x86" publicKeyToken =" 1fc8b3b9a1e18e3b" />
< bindingRedirect oldVersion =" 8.0.41204.256-8.0.50608.0"
newVersion =" 8.0.50727.42" />
该政策将一定范围的版本指向新版本清单
在SxS directroy。
< ; / quote>
在我的机器上看，我有一个文件
8.0.50727.26.policy
在目录中
C：\ WINDOWS \ WinSxS \政策\ x86_policy.8.0.Microsof t.VC80.DebugCRT_1fc8b3b9a1e18e3b_x-ww_09e017b4
将50608.0版本重新映射到正确的程序集（我正在使用RC1代替
的RTM，这就是为什么我说.26而不是.42）。
也许你的机器上的政策丢失/错误了？
-cd
I have just installed VS2005 RTM on a machine that has *never* had any
of the beta versions. It did have VS2003, but I uninstalled that.
I built a DLL with the new managed C++ syntax. The linker generated a
manifest, so far so good. The manifest says that there is a dependency
to Microsoft.VC80.CRT version 8.0.50608.0. (Note that I do not
explicitly use the CRT, the compiler is adding the dependency, but that
is not the issue in this post.)
When I run a process that uses this DLL I get a FileNotFoundException.
%windir%\WinSxS does not have an entry for this particular version. The
nearest I can find is
x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727. 42_x-ww_f75eb16c
Note that the only difference between this and the reference in the
manifest is the version. (The public key token is the same.) So why is
link version 14.00.50727.42 creating a manifest to an unmanaged that
does not, and has never, existed on my machine?
Richard
--
http://www.grimes.demon.co.uk/workshops/fusionWS.htm
http://www.grimes.demon.co.uk/workshops/securityWS.htm
Richard Grimes wrote:I have just installed VS2005 RTM on a machine that has *never* had any
of the beta versions. It did have VS2003, but I uninstalled that.
I built a DLL with the new managed C++ syntax. The linker generated a
manifest, so far so good. The manifest says that there is a dependency
to Microsoft.VC80.CRT version 8.0.50608.0. (Note that I do not
explicitly use the CRT, the compiler is adding the dependency, but
that is not the issue in this post.)
When I run a process that uses this DLL I get a FileNotFoundException.
%windir%\WinSxS does not have an entry for this particular version.
The nearest I can find is
x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727. 42_x-ww_f75eb16c
Note that the only difference between this and the reference in the
manifest is the version. (The public key token is the same.) So why is
link version 14.00.50727.42 creating a manifest to an unmanaged that
does not, and has never, existed on my machine?
Interesting.
I just did a quick test, creating a C++ class library and a C# app that uses
that library. The app runs just fine, but examining the files produced for
the C++ class library, I see a manifest, and that manifest does indeed have
version 50608.0 specifies in it and not version 50727.42.
So there''s at least two things here that I don''t understand:
1. Why the wrong build number in the manifest?
2. Why did it work for me but not for you despite that wrong build number?
I''m going to forward those questions on to the VC++ team - there''s something
very fishy going on here.
-cd
Carl Daniel [VC++ MVP] wrote:Richard Grimes wrote:
Interesting.
I just did a quick test, creating a C++ class library and a C# app
that uses that library. The app runs just fine, but examining the
files produced for the C++ class library, I see a manifest, and that
manifest does indeed have version 50608.0 specifies in it and not
version 50727.42.
So there''s at least two things here that I don''t understand:
1. Why the wrong build number in the manifest?
2. Why did it work for me but not for you despite that wrong build
number?
Here''s some more information. I compiled on the command line, with no
pre-compiled headers (/clr /LD /Zi /MDd); I was not using a VS project.
Then I created a VS project for the class library, and compiled for
Debug. I copied this new library into the folder where my app was (a
simple C# process), ran it, and the problems disappeared.
Searching through the VS build output log the difference appears to be
that the VC project embeds the manifest using mt.exe, and I am not doing
this on the command line. So I took the library I created on the command
line and embedded the manifest in it with mt.exe. The library is now
loaded and I don''t get any errors.
It seems to me that the managed C++ compiler is useless if it cannot be
used to build a library on the command line. I have been using it since
C/C++ v7 and as far as I can remember I have been able to compile and
link a DLL using just the compiler (cl.exe). Version 14 has broken this,
because to get a library that will load I must massage the DLL with
mt.exe. This is a step backward IMO.
I''m going to forward those questions on to the VC++ team - there''s
something very fishy going on here.
Thanks, please do. It appears that as far as anyone on the .NET team is
concerned, I have been ex-communicated. :-(
Richard
--
http://www.grimes.demon.co.uk/workshops/fusionWS.htm
http://www.grimes.demon.co.uk/workshops/securityWS.htm
"Richard Grimes" <ri******@mvps.org> wrote in message
news:eG**************@TK2MSFTNGP12.phx.gbl...Carl Daniel [VC++ MVP] wrote:Richard Grimes wrote:
Interesting.
I just did a quick test, creating a C++ class library and a C# app
that uses that library. The app runs just fine, but examining the
files produced for the C++ class library, I see a manifest, and that
manifest does indeed have version 50608.0 specifies in it and not
version 50727.42.
So there''s at least two things here that I don''t understand:
1. Why the wrong build number in the manifest?
2. Why did it work for me but not for you despite that wrong build
number?
Here''s some more information. I compiled on the command line, with no
pre-compiled headers (/clr /LD /Zi /MDd); I was not using a VS project.
Then I created a VS project for the class library, and compiled for Debug.
I copied this new library into the folder where my app was (a simple C#
process), ran it, and the problems disappeared.
Searching through the VS build output log the difference appears to be
that the VC project embeds the manifest using mt.exe, and I am not doing
this on the command line. So I took the library I created on the command
line and embedded the manifest in it with mt.exe. The library is now
loaded and I don''t get any errors.
It seems to me that the managed C++ compiler is useless if it cannot be
used to build a library on the command line. I have been using it since
C/C++ v7 and as far as I can remember I have been able to compile and link
a DLL using just the compiler (cl.exe). Version 14 has broken this,
because to get a library that will load I must massage the DLL with
mt.exe. This is a step backward IMO.I''m going to forward those questions on to the VC++ team - there''s
something very fishy going on here.
Thanks, please do. It appears that as far as anyone on the .NET team is
concerned, I have been ex-communicated. :-(
Here''s the reply that I got:
<quote>
The version in the external manifest file or the embeded manifest will show
8.0.50608.0 as you indicated. What really happens is that there are policies
at the WinSxS\policies directory that maps such version to 8.0.50727.42.
That explains why it works even when you are seeing the different version in
the manifest generated.
For example building a simple a.cpp application with /MD will generate a
manifest containing
<assemblyIdentity type=''win32'' name=''Microsoft.VC80.CRT''
version=''8.0.50608.0'' processorArchitecture=''x86''
publicKeyToken=''1fc8b3b9a1e18e3b'' />
Whe you run the application the policy on my machine at
%windir%\WinSxS\Policies\x86_policy.8.0.Microsoft. VC80.CRT_1fc8b3b9a1e18e3b_x-ww_77c24773\8.0.50727.4
2.policy (which contains the below) will direct the binary to the new
version
<assemblyIdentity type="win32" name="Microsoft.VC80.CRT"
processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"/>
<bindingRedirect oldVersion="8.0.41204.256-8.0.50608.0"
newVersion="8.0.50727.42"/>
The policy directs a certain range of versions to the newer version manifest
at the SxS directroy.
</quote>
Looking on my machine, I have a file
8.0.50727.26.policy
in directory
C:\WINDOWS\WinSxS\Policies\x86_policy.8.0.Microsof t.VC80.DebugCRT_1fc8b3b9a1e18e3b_x-ww_09e017b4
that remaps the 50608.0 build to the correct assembly (I''m using RC1 instead
of RTM, which is why mine say .26 instead of .42).
Perhaps that policy is missing/wrong on your machine?
-cd
这篇关于清单和VC8的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
