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 可以關掉它