轉載自：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