VC2008下提示找不到MSVCP90D.dll的解决办法
2015-06-06 15:08
274 查看
VS 2005在生成可执行文件时使用了一种新的技术,该技术生成的可执行文件会伴随生成一个清单文件(manifest
file)(.manifest后缀文件)(其本质上是XML文档,你可以用文本编辑器打开看看),并在链接完成后将该清单文件嵌入到exe文件中(默认情况下)。而在FAT32文件系统中,在处理清单文件阶段,当增量链接时不能完成清单文件的更新(默认情况下),于是造成清单文件嵌入失败,从而使该exe文件运行时没有相应的清单文件而运行失败并提示如上错误。
1. 好像是fat32下时间戳有问题(在ntfs下这个问题就没有了),搞得manifest有时嵌入不到exe中(默认配置是嵌入的,所以就报错找不到 dll了。
解决方案很多,列举如下:
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 可以关掉它
转自:http://blog.csdn.net/sea_sharka_17/article/details/4176178
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 可以关掉它
转自:http://blog.csdn.net/sea_sharka_17/article/details/4176178
相关文章推荐
- Java类加载器
- Android之Windows下生成动态库so并打包到APK中(转)
- 小南的数据结构目录
- 卓有成效的管理者(读书笔记)
- 编程模拟自然(一):如何画一颗静态树
- Centos 5.5 安装 Git 以及配置
- 手动加载类的两种方法
- Palindrome Number
- web.xml之filter使用详解
- XP设置远程桌面24位色深
- Struts2上传单个或多个文件
- 安装VisualDSP++出现Install cannot proceed.Could not find XML file or the XML file may be corrupted!
- 文本编码区别
- 百度2015春季实习生招聘附加题_01排序
- 如何检测网页的加载进度。从而编写进度条
- 【Javaweb】后台的字符串转义,入库之前记得先对字符串转义防止sql注入问题
- busybox sendmail发送邮件(含附件)
- 栈回溯技术
- 回溯法解决0-1背包问题
- HDU 2896 病毒侵袭