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內的資源
manifest嵌入exe
然後在VC中新建一個MFC AppWizard（exe）工程，Document/View或Dialog均可，接着把XPStyle.manifest複製到工程所在目錄，再用記事本或其它文本編輯工具手動修改工程目錄下的資源文件（.rc），在文件最後加上一行：
1 24 “XPStyle.manifest”
最後加上的那一行，“1”代表資源ID，必須是“1”。“24”代表資源類型，我想我們對RT_ACCELERATOR、RT_BITMAP、RT_MENU、RT_STRING等資源都非常熟悉，而“24”實際上是RT_MANIFEST。
