Chinaunix首页 | 论坛 | 博客
  • 博客访问: 94323
  • 博文数量: 50
  • 博客积分: 1086
  • 博客等级: 少尉
  • 技术积分: 420
  • 用 户 组: 普通用户
  • 注册时间: 2011-10-25 16:16
文章分类
文章存档

2011年(50)

我的朋友

分类: WINDOWS

2011-11-15 19:25:13

VC2008下提示找不到MSVCP90D.dll的解决办法

 

VS 2005在生成可执行时使用了一种新的,该技术生成的可执行文件会伴随生成一个清单文件(manifest file)(.manifest后缀文件)(其本质上是XML文档,你可以用文本编辑器打开看看),并在链接完成后将该清单文件嵌入到exe文件中(默认情况下)。而在FAT32文件中,在处理清单文件阶段,当增量链接时不能完成清单文件的更新(默认情况下),于是造成清单文件嵌入失败,从而使该exe文件运行时没有相应的清单文件而运行失败并提示如上错误。

 

1. 好像是fat32下时间戳有问题(在ntfs下这个问题就没有了),搞得manifest有时嵌入不到exe中(默认配置是嵌入的,所以就报错找不到 dll了。

2. 磁盘系统是fat32格式的:FAT32的时间精度不够,所以linker在生成文件的时候会出错,如果是ntfs的就没有问题


很多,列举如下:
1. 由于这是在链接动态运行库出现的问题,所以你可以选择代码生成的连接方式为/MTd而非/MDd,不用这些DLL文件从而避免问题的出现。该方法有一个很显然的缺点:适用范围有限,不推荐该方法。
2. 既然跟FAT32系统有关,那么我们可以选择在NTFS文件系统中开发从而避免该问题,此方法同上,也是采用的回避问题的方式,不提倡。
3. 该方法仍与FAT32有关:在项目的“属性|配置属性|清单工具|常规(Project | Game Properties | Configuration Properties | C/C++ | Code Generation | Runtime Library)”中的“使用FAT32解决办法”选择“是”(默认为“否”),重新生成项目即可解决问题。该方法是唯一真正针对问题所在而提出的解决方法,使清单工具可以正确更新。(此方法是官方解决方法,也比较方便,推荐)
4. 既然问题是在更新嵌入的清单文件时发生的,由于FAT32的原因而未能更新嵌入的清单文件,于是我们有如下两种解决方法:
(1)不启用增量链接。在项目的“属性|配置属性|链接器|常规”中的“启用增量链接”选择“否”。此方法阻断了问题产生的源头,其每次生成exe文件时都直接嵌入清单文件,而不是默认的根据时戳而决定是否更新清单文件。
(2)不嵌入清单文件。在项目的“属性|配置属性|清单工具|输入和输出”中的“嵌入清单”选择“否”,从而在生成exe文件时附随生成一个清单文件(默认情况下,其文件名为exe文件的全名加上“.manifest”),避免了嵌入清单文件可能失败的问题。在程序运行时,会用到该清单文件。显然,这种方式使可执行程序产生了更多的外部依赖,不推荐。

另外,还有一个不能称为方法的土办法:每次Build前手动删除*.ilk文件(增量链接文件)(当然可以在项目属性中写入删除,使其自动执行),不推荐该土办法。
最后,总结一下:
1. 此问题只在特定条件下才会出现:在FAT32文件系统中编译、默认(增量模式、不启用FAT32解决方案、嵌入清单文件)、非第一次生成可执行文件文件(即在增量连接、更新清单文件时)。
2. 解决方案1和4.1方便实用,推荐使用。

 

 

 

manifest原理和用途

dll是被动态调用的,所以会被若干个程序共享使用的 但是如果dll在应用程序不知道的情况下升级了、或是被另一个程序更改了,就可能会出现问题,即”DLL Hell”

随着系统资源越来越丰富,硬盘不那么紧张,所以在XP以后的操作系统中,用新的机制来管理DLL
(这种机制,这不仅仅是对于.NET而言,对于普通的Native程序也是一样的)

Madifest是个XML的描述文件,对于每个DLL有DLL的Manifest文件,对于每个应用程序Application也有自己的Manifest

对于应用程序而言,Manifest可以是一个和exe文件同一目录下的.manifest文件,也可以是作为一个资源嵌入在exe文件内部的(Embed Manifest)

XP以前版本的windows,会像以前那样执行这个exe文件,寻找相应的dll,没有分别
Manifest只是个多余的文件或资源,dll文件会直接到system32的目录下查找,并且调用

而XP以后的操作系统,则会首先读取Manifest,获得exe文件需要调用的DLL列表
(此时获得的,并不直接是DLL文件的本身的位置,而是DLL的manifest)
操作系统再根据DLL的Manifest去寻找对应的DLL
<因此就可能区别不同版本的同一个DLL文件,或是指定一个程序本身Isolated的DLL>

不过使用Visual Studio 2005以后的一个新问题是,
VS2005带的8.0新版的C运行库(VC 8.0 CRT)文件在XP以后支持manifest的Windows版本中被调用时,
将会check一下Application自身的Manifest,否则将会拒绝被调用
这也就是说,使用Visual Studio开发的Application,Manifest将是必不可少的
(搞不懂MS为啥要这样设置,所以与VS2003.NET不同了)
(后来想想,除了MS自己说的哪些冠冕堂皇的原因,至少这样一来Linux的Wine模拟要麻烦多了)

除非,你的程序是静态链接的,没有使用dll,只使用了操作系统核心的 Kernel32.dll, User32.dll, Ole32.dll, 或ShDocVW.dll 等
project的设置必须是Use Standard Windows Libraries、Not Using ATL、No Common Language Runtime support
那么你可以不需要考虑Manifest 可以关掉它

阅读(748) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~