解决VS2005中的MFC80UD.dll找不到

转载自：http://www.cnblogs.com/wyj553/archive/2009/02/27/1400009.html

解决VS2005中的MFC80UD.dll找不到的问题分类:
我装了Visual Stduio 6编译了一下MFC程序没有问题,突然想试一下最新的巨大的Visual Stduio 2005

于是试验了一下,开始用向导生成了一个项目,编译,一切没有问题,虽然是庞然大物,但是速度还可以,没想到运行时出现了MFC80UD.dll找不到的问题,

嗯?最近我用了比较的优化,于是猜测是DLL被我删了,于是拿出安装盘,进了维护模式,修复一次,结果,修复没有成功?我昏.Baidu搜一下,没有多少资料,google搜了一下,出来三页,全是微软的英文网页,没有办法,只好硬着头皮看了一下,  弄清了 原来是 Manifest  搞的鬼,

然后修改项目属性,清单工具 中的 输入输出 把嵌入清单文件选否.然后编译,链接运行,成功.

 

整合网络中的VC2005中manifest问题
问题描述：大部分的vs.net 2005的用户在新建“win32项目－windows应用程序”的时候，新建的工程都通不过去，出现如下提示： Solution to “MSVCR80D.dll not found”
“没有找到MSVCR80D.dll，因此这个应用程序未能启动。重新安装应用程序可能会修复此问题。”

由于vs.net 2005 采用了一种新的DLL方案，搞成一个exe还要配有一个manifest文件（一般在嵌入文件里了，所以看不到，不过也可以不嵌入，这样会生产一个 <程序名>.exe.manifest的文件，没它exe自己就转不了了：）这是个新功能，微软弄了个新工具（mt.exe），结果不好用，好像是fat32下时间戳有问题（在ntfs下这个问题就没有了），搞得manifest有时嵌入不到exe中（默认配置是嵌入的，所以就报错找不到 dll了。

解决方案
1．微软对于这个问题应该也有处理，不过感觉不是很人性化。在“属性->配置属性->清单工具->常规“下有一个”使用FAT32解决办法，把它选成是，就可以了。（注意：一定要先配置这个选项，然后再编译工程，要不然还是不好用：）

2．找到你的工程的文件夹，如（myproject），找到其下的myproject/myproject/Debug/ myproject.rec，把它删掉（删掉整个Debug目录也可以），重新编译，搞定！

3．
1） 首先找到你的vs.net安装目录（如我的是E:/Program Files/Microsoft Visual Studio 8），定位到Microsoft Visual Studio 8/VC/VCWizards/AppWiz/Generic/Application文件夹，备份这个Application文件夹）
2）打开html/2052，看到两个文件了吧，就那个AppSettings.htm了，打开，在266行“ ”后回车，然后插入一下内容：

选择你所使用的文件系统:

下载: vc.txt
<INPUT TYPE="radio" CLASS="Radio" checked onPropertyChange="" NAME="filesystem" ID="FAT32" ACCESSKEY="F" TITLE="FAT32"> 
FAT32(F) 
  
<INPUT TYPE="radio" CLASS="Radio" onPropertyChange="" NAME="filesystem" ID="NTFS" ACCESSKEY="N" TITLE="NTFS"> 
NTFS(N) 
好，保存关闭，这个改完了，准备下一个。
3） 打开scripts/2052，这里就一个文件，ue打开它，找到138行“ var bATL = wizard.FindSymbol(”SUPPORT_ATL”);”其后回车，插入如下内容：

var MFTool = config.Tools("VCManifestTool"); MFTool.UseFAT32Workaround = true;

好，继续找到210行(源文件的210，你加了上边的语句就不是210了：)“ config = proj.Object.Configurations.Item(”Release”);”注意这次要在这行“前边”加如下内容：
if(bFAT32) { var MFTool = config.Tools("VCManifestTool"); MFTool.UseFAT32Workaround = true; }

好了，终于都改完了，打开你的vs.net 2005新建一个win32应用程序看看吧，效果还不错吧

http://forums.microsoft.com/MSDN/default.aspx?SiteID=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 可以关掉它

VS2005中Menifest相关的设置:
? Project/Properties/Linker/Manifest File/Generate Manifest?? 决定是否生成Manifest，如上情况才可以关闭
? Project/Properties/Linker/Manifest File/Allow Isolation????????这个是设置DLL的调用的，并不能决定Manifest是否还是必须的
? Project/Properties/Manifest Tool/Input and Output/Embed Manifest? 决定Manifest是个单独的文件还是嵌入到exe内的资源

【对于我来说，使用SDL必须是启用DLL的动态链接方式，所以必须开启Manifest，并且让Manifest Embed进入exe比较方便】
【与上面内容相应的是关于如何发布软件的问题，事实上只有VC6.0的CRT库是绑定作为Windows的一部分的，之后从VS.net开始，VC程序制作安装包也是要考虑库文件的，只不过VC6.0时推荐拷入System32，VC.net时推荐放在exe文件local目录，而现在VS2005则还需要考虑Manifest的问题了，看似麻烦，其实也还好，VS自带工具打包，下面一些网址也有讲如何手工做redistribution】

参考网址：
http://msdn2.microsoft.com/en-us/library/ms235342.aspx
http://msdn2.microsoft.com/en-us/library/ms235265.aspx
http://msdn2.microsoft.com/en-us/library/8kche8ah.aspx
http://blog.kalmbachnet.de/?postid=54
http://blogs.msdn.com/nikolad/archive/2005/03/18/398720.aspx