下列附有VS2008釋出程式介紹：
vc2008程式釋出指南2008-05-03 17:46vc2008開發的程式的釋出方式可以有5種方式:

1. 採用靜態連結到crt和MFC. 只要你擁有組成程式的所有原始碼,你就可以採用這種方式,
這種方式除了程式變大一點,好處多多:
1) 不必重新發布vc2008基礎庫vcredist_x86.exe(安裝到WinSxS).
2) 不必產生,嵌入manifest.
3) 也不把vc2008基礎庫放在程式所在目錄.

2. exe(嵌入manifest) + vcredist_x86.exe

確保程式正確產生並嵌入manifest檔案,然後把程式和vcredist_x86.exe一起釋出.使用者先安裝
vcredist_x86.exe(安裝到WinSxS),然後程式就能正常運行了.

(debug 編譯的會有問題)

3. exe(嵌入manifest) + 用到的基礎庫檔案放到程式目錄(包括庫檔案本身的manifest檔案)

確保程式正確產生並嵌入manifest檔案,然後把程式用到的vc2008基礎庫相關檔案複製到程式
所在目錄,這種方式適用於使用者沒有安裝過vcredist_x86.exe,一旦使用者安裝過vcredist_x86.exe,
若WinSxS中的相關檔案遭到破壞,那麼即使在程式目錄放上所有用到的vc2008基礎庫,程式也跑
不起來;若WinSxS中的相關檔案正常,那麼程式目錄下的相關檔案就是多餘的了,刪掉它們程式也能
正常執行.

4. exe(自行編寫manifest) + vcredist_x86.exe

5. exe(自行編寫manifest) + 用到的基礎庫檔案放到程式目錄(包括庫檔案本身的manifest檔案)

另外,C:/Program Files/Common Files/Merge Modules 目錄下有相應庫的整合模組可以直接整合到安裝包中去.

alt+F7->配置屬性->C/C++->Code Generation->Runtime Library 屬性一般在釋出的時候要進行靜態釋出，因為目前的作業系統正在換代，平臺比較多，所以debug：Multi-threaded Debug(MTd)、release：Multi-threaded(MT),當然如果工程裡邊需要依賴很多的dll，每個dll又不一定是靜態釋出，尤其是MFC extension DLL,必須為動態釋出這時工程裡肯定要包含MFC的執行庫，所以這好似所有的工程就可以採用動態執行庫的方法，debug：Multi-threaded Debug DLL(MDd)、release：Multi-threaded DLL(MD)，這時可以採用共享MFC庫的方式即alt+F7->配置屬性->General->Project Defaults->Use of MFC->use mfc in a shared dll
vs2005
Debug 發行版所依賴的庫為：mfc80d.dll、Microsoft.VC80.DebugMFC.manifest、Microsoft.VC80.DebugMFC.manifest、msvcm80d.dll、msvcp80d.dll、msvcr80d.dll
Release 釋出版所依賴的庫為：mfc80.dll、Microsoft.VC80.MFC.manifest、Microsoft.VC80.MFC.manifest、msvcm80.dll、msvcp80.dll、msvcr80.dll

vs2008
Debug 發行版所依賴的庫為：mfc90d.dll、Microsoft.VC90.DebugMFC.manifest、Microsoft.VC90.DebugMFC.manifest、msvcm90d.dll、msvcp90d.dll、msvcr90d.dll
Release 釋出版所依賴的庫為：mfc90.dll、Microsoft.VC90.MFC.manifest、Microsoft.VC90.MFC.manifest、msvcm90.dll、msvcp90.dll、msvcr90.dll

附錄:

A. 自行編寫的manifest檔案命名: abc.exe 對應abc.exe.manifest

B. 與程式對應的manifest的格式:

<?xml version='1.0' encoding='UTF-8' standalone='yes'?>
<assembly xmlns='urn:schemas-microsoft-com:asm.v1' manifestVersion='1.0'>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel level='asInvoker' uiAccess='false' />
</requestedPrivileges>
</security>
</trustInfo>

<dependency> // VC9 的CRT, 基本上所有用vc2008的程式都需要下面一段
<dependentAssembly>
<assemblyIdentity type='win32' name='Microsoft.VC90.CRT' version='9.0.21022.8' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' />
</dependentAssembly>
</dependency>

//用到 VC9的MFC庫,需要加下面一段
<dependency>
<dependentAssembly>
<assemblyIdentity type='win32' name='Microsoft.VC90.MFC' version='9.0.21022.8' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' />
</dependentAssembly>
</dependency>

<dependency> //想使用windows xp 的6.0版本的通用控制元件,加需要下面一段
<dependentAssembly>
<assemblyIdentity type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='x86' publicKeyToken='6595b64144ccf1df' language='*' />
</dependentAssembly>
</dependency>

</assembly>

C. 如何確保程式正確產生並嵌入manifest檔案?
- xxxproject > properties > Configuration Properties > Generate Manifest: 確保為Yes
這個與Configuration Properties >Linker > Manifest File >Generate Manifest都是指同一個設定.
- Project > Tool Build Order > Manifest Tool確保打勾.
release版本可以看到有: xxx.exe.intermediate.manifest 生成, 它是由linker生成的,由manifest tool嵌入程式的.
debug版本manifest tool把xxx.exe.intermediate.manifest嵌入程式後還會輸出一個xxx.exe.embed.manifest,供檢查內容是否一樣

1、檢視匯入表，檢視相關crt庫dll路徑，找到對應目錄，一般在C:\WINDOWS\WinSxS中，例如：
C:\WINDOWS\WinSxS\x86_Microsoft.VC80.DebugCRT_1fc8b3b9a1e18e3b_8.0.50727.4053_x-ww_d014c028\MSVCR80D.dll

2、將對應檔案帶目錄複製出來，C:\WINDOWS\WinSxS\...

3、在C:\WINDOWS\WinSxS\Manifests找到對應描述檔案，包含.cat和.Manifest檔案，帶目錄複製出來，

4、上述檔案在對應機器上解壓就可以執行了。

5、注意不同機器體系結構上要複製ia**/x86**等都需要。

==========================================

========================================

再談VC2005 釋出程式的兩大問題:"應用程式正常初始化失敗","應用程式配置不正確",攻略全

自己電腦上能用,到了其他電腦上就不能用了,是不是很頭痛,除了必要的DLL檔案,還有些什麼是必須一起打包發行的呢?

1."應用程式配置不正確"

============================================

我們用 VS 2005 編寫非託管的程式, 在一臺未安裝 .net 開發環境的機器上執行會出現

"由於應用程式的配置不正確，應用程式未能啟動，重新安裝應用程式可能會糾正這個問題"。

開始時還以為必須要安裝 .net Framework 2.0 ， 然後安裝了 .net Framework 2.0 。發現仍然報錯。此時暈了, 這是為什麼呢？

網上一查: 才知道是缺少 DLL 檔案, 可是我的程式裡面有一部分是 MFC 寫的，有一部分是 Win32 ， 還有很多 DLL, 以及驅動程式，缺少的DLL那就多了, 而且MFC 和 Win32 需要不同的 DLL。

後來用 dependens.exe 查看了各個應用程式需要哪些額外的DLL檔案, 發現有些 DLL 確實是目標機器中沒有的 ，難怪會報錯. 以前用 VC 6.0 時 如果缺少 DLL 會給出提示，現在不給提示真讓人暈了，該死的 MS

我做了下面的試驗：

(1) 採用 VS 2005 預設的編譯器選項, 構建 Win32 程式， 檢查他需要哪些額外的 DLL。編譯選項如下圖所示:

build 後檢查生成程式需要下面的 DLL:

MSVCR80D.DLL, msvcrt.dll 在本機我找到了這2 個檔案並和應用程式放在了同一目錄下, 結構還是報錯誤。根據已有的資料我知道，還缺少檔案, 繼續找。

我的VS安裝在 E: 盤, 從下面路徑中找:

E:/Program Files/Microsoft Visual Studio 8/VC/redist/Debug_NonRedist/x86/Microsoft.VC80.DebugCRT 我們需要從這個資料夾中拷貝檔案 Microsoft.VC80.DebugCRT.manifest ，該檔案是文字格式的, 包含了版本資訊。

注意現在我們構建的是 Debug 版本, 需要從這個檔案中得到該檔案。

總結: 構建 Win32 程式時, 採用VS預設的編譯選項, 需要下面檔案:

(1) MSVCR80D.DLL

(2) msvcrt.dll (我測試過這個檔案 , 即使沒有也沒有關係, 為了保險起見還是加上吧)

(3)E:/Program Files/Microsoft Visual Studio 8/VC/redist/Debug_NonRedist/x86/Microsoft.VC80.DebugCRT/Microsoft.VC80.DebugCRT.manifest

現在再試驗一下 Release 版本的:

Release 版本的程式直接就可以執行, 根本就不需要什麼其它的檔案。

我又測試了其它幾個專案, win32 Release 版本不需要其它的檔案。

MSVCR80D.DLL

MFC: 現在我添加了
mfc80d.dll
mfc80ud.dll
Microsoft.VC80.DebugCRT.manifest
Microsoft.VC80.DebugMFC.manifest
msvcr80d.dll
debug 版本才可以執行

更詳細資訊:

==========================================================================

1.如果你的專案屬性是 MD 或 MDd,那就要把以下檔案放入你的EXE目錄一起釋出

開始-執行- X:\Program Files\Microsoft Visual Studio 8\VC\redist\Debug_NonRedist\x86\Microsoft.VC80.DebugCRT

2.如果你想靜態編譯進EXE,也就是 MT/MTd,那就參看這裡:建議動態連結,這種不同開關的LIB也能一起工作了.

===============================================

Background MSDN中對於在不同的配置下Link的LIB作了說明： C Runtime Library：

開關	對應的庫	版本
/MD	MSVCRT.LIB	多執行緒DLL的Release版本
/MDd	MSVCRTD.LIB	多執行緒DLL的Debug版本
/MT	LIBCMT.LIB	多執行緒靜態連結的Release版本
/MTd	LIBCMTD.LIB	多執行緒靜態連結的Debug版本
/clr	MSVCMRT.LIB	託管程式碼和非託管程式碼混合
/clr:pure	MSVCURT.LIB	純託管程式碼

C++ Standard Library：

開關	對應的庫	版本
/MD	MSVCPRT.LIB	多執行緒DLL的Release版本
/MDd	MSVCPRTD.LIB	多執行緒DLL的Debug版本
/MT	LIBCPMT.LIB	多執行緒靜態連結的Release版本
/MTd	LIBCPMTD.LIB	多執行緒靜態連結的Debug版本

編譯器會自動根據編譯選項，選擇對應的LIB檔案。一般情況下這不會出現問題。 然而，在部分情況下，一旦你的程式的各個部分（LIB, OBJ…）並非由相同的編譯選項編譯出，而Link在一起的話，會出現各種各樣的看似很難解決的問題，這類問題主要以重複定義的錯誤形式存在，通常的解決方法也很簡單，就是選擇同樣的編譯選項進行編譯之後再Link。 Case Study 之前剛下載了ANTLR，在準備編譯它的Example的時候發現了下面的Build錯誤（我自己為這個例子建立了VS的專案，當前配置為動態連結Runtime庫，Debug版）：

1>msvcprtd.lib(MSVCP80D.dll) : error LNK2005: "public: __thiscall std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >::~basic_string<char,struct std::char_traits<char>,class std::allocator<char> >(void)" ([email protected][email protected]@[email protected]@[email protected]@[email protected]@[email protected]@[email protected]) already defined in antlr.lib(CharScanner.obj) 1>msvcprtd.lib(MSVCP80D.dll) : error LNK2005: "public: class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > & __thiscall std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >::replace(unsigned int,unsigned int,char const *,unsigned int)" ([email protected][email protected][email protected]@[email protected]@V?

分析一下錯誤來源，會發現： 1.錯誤來源主要是重複定義的問題，而且重複定義的基本上都是VC Runtime和Standard C++ Library中的函式 2.LIBCMT和LIBCPMT為Release下的Lib，本來不應該出現在Debug版本的連結的Lib中 3.重複定義的問題主要出現在：LIBCMT, LIBCPMT, MSVCPRTD, MSVCRTD 來看看出問題的LIB是那些： 1.LIBCMT：C Runtime庫的多執行緒靜態連結的Release版本 2.LIBCPMT：C++ Standard Library的多執行緒靜態連結的Release版本 3.MSVCPRTD：C++ Standard Library的多執行緒DLL的Debug版本 4.MSVCRTD：C Runtime Library的多執行緒DLL的Debug版本 當前我們的配置是多執行緒DLL的Debug版，因此3和4是應該出現在link的列表中的，不屬於多餘。而後兩者則是隻是當多執行緒靜態連結Release版中才會出現。這提示我在專案中加入的ANTLR.LIB可能是造成這個問題的根源，因為靜態庫的編譯選項很容易和主程式發生衝突，並且根據實際資訊我們可以看出ANTLR.LIB應該是用多執行緒靜態連結的Release版本來編譯的。 這樣，解決方法就很清楚了： 1.切換到Release，因為ANTLR.LIB是在Release下面編譯的 2.把Run Time庫的版本修改成多執行緒靜態連結 做了這兩個修改之後編譯通過。 還有一種方法是，自己用多執行緒DLL的Debug版重新編譯一次ANTLR，生成一個新的ANTLRD.LIB，再link這個Lib也可以解決這個問題。 Summary 1.知道各個不同的LIB代表的版本資訊非常重要，可以幫助快速定位問題 2.在程式設計的時候，一定要把所有的專案的編譯選項（是靜態連結Runtime庫還是動態連結Runtime庫，Debug/Release）配置成一樣的。如果部分LIB/OBJ是由第三方提供（OBJ情況很少見），一般情況下只能調整自己的編譯選項，除非你可以要求第三方提供其他版本的編譯好的LIB 3.在釋出可重用的靜態LIB庫供其他人呼叫的時候，最好對應不同的編譯選項，乃至VC版本，提供不同版本的LIB。VC自己的Runtime就是最好的例子。 =================================== C Runtime Library：

開關 對應的庫 版本 /MD MSVCRT.LIB 多執行緒DLL的Release版本 /MDd MSVCRTD.LIB 多執行緒DLL的Debug版本 /MT LIBCMT.LIB 多執行緒靜態連結的Release版本 /MTd LIBCMTD.LIB 多執行緒靜態連結的Debug版本 /clr MSVCMRT.LIB 託管程式碼和非託管程式碼混合 /clr:pure MSVCURT.LIB 純託管程式碼

C++ Standard Library：

開關 對應的庫 版本 /MD MSVCPRT.LIB 多執行緒DLL的Release版本 /MDd MSVCPRTD.LIB 多執行緒DLL的Debug版本 /MT LIBCPMT.LIB 多執行緒靜態連結的Release版本 /MTd LIBCPMTD.LIB 多執行緒靜態連結的Debug版本

在專案屬性-連結-輸入 中,輸入對應的庫,記住程式裡還要還引用其他LIB,其他LIB也必須是相同的開關,比如都是 /MTD

2.應用程式正常初始化失敗:

1.今天這兩種情況都被我碰到了,這個比較好解決,在Microsoft Visual Studio 8資料夾內搜尋

vcredist_x86.exe VC可再發行包,到目標機器上安裝一下,不用重啟,即可使用.

2.專案的檔案被放在了fat/fat32分割槽上導致的, 解決方法是把它們都移動到ntfs分割槽上, 或者把“專案屬性|Manifest Tool|General|Use FAT32 Work-around”設為yes。

3.如果把相應的MFCDLL全COPY過去了,還不行怎麼辦呢?

(1)用ultraedit,editplus開啟你的EXE檔案,搜尋manifest,找到使用的DLL版本號,如version="8.0.50.XXX"

(2)DEBUG模式下報此錯的話, 把你電腦上的 c:\windows\winsxs\policies\x86_policy.8.0.Microsoft.VC80.DEBUGCRT.XXXXXXXXXXX

找到對應版本號的cat,和policy這兩個檔案,再找到

c:\windows\winsxs\manifest\x86_Microsoft.VC80.DebugCRT_XXXX_8.0.50727.762_XXXXX.cat和x86_Microsoft.VC80.DebugCRT_XXXXXX_8.0.50727.762_XXXXX.manifest

複製到出問題的機子上的對應目錄就OK了

3.缺少SP1補丁,

GHOST了C盤後,發覺再執行OGRE的程式就不行了,:"應用程式正常初始化失敗",偵錯程式輸出:
LDR: LdrpWalkImportDescriptor() failed to probe d:\program\project\BumperCar\BumperCar\Debug\exe\OgreMain_d.dll for its manifest, ntstatus 0xc0150002 ,想起來了,VC2005要裝SP1才相容OGRE1.4X,這裡放出補丁.

英文補丁 431M

http://download.microsoft.com/download/6/3/c/63c69e5d-74c9-48ea-b905-30ac3831f288/VS80sp1-KB926601-X86-ENU.exe

中文補丁
http://download.microsoft.com/download/8/0/7/8071514d-9370-45c3-8af1-4ff09a70e59d/VS80sp1-KB926604-X86-CHS.exe

 =======================================================================================================================

VC9編譯的程式在沒有裝過VC9（確切的說是.Net Framework3.5）的機器上執行時，如果提示“由於應用程式配置不正確，應用程式未能啟動。重新安裝應用程式可能會糾正這個問題。”這個錯誤，那麼就說明該程式動態連結了VC9的執行時庫，（如果還用到了MFC，那麼可能動態連結了VC9的MFC庫，同理還有ATL庫），以及缺少對應的manifest檔案，程式在目標機器上沒有找到這些庫和配置檔案，因此導致了這個錯誤。出現這種情況的VC9編譯器可能存在3個版本，接下來分別闡明：

1、沒有打過任何補丁的VS2008

該版本對應的CRT/MFC/ATL庫的版本號為9.0.21022.8，這個版本號在後面會用到。這個版本的程式部署比較簡單，直接把VC安裝目錄下的redist目錄（C:\Program Files\Microsoft Visual Studio 9.0\VC\redist）中需要的庫以及對應的manifest檔案拷貝到執行程式同目錄下，這樣程式到任何機器上都能夠正常運行了。

2、打過SP1補丁的VS2008

打過該補丁後，系統中存在著兩個版本的CRT/MFC/ATL庫，版本號分別為9.0.21022.8和9.0.30729.1，這導致了manifest檔案中記錄的版本號和實際庫的版本號不一致（程式要求它們的版本號一致才能執行）。這個版本的程式部署需要兩個步驟，首先要使manifest檔案中依賴項的版本號與實際庫的版本號一致，均為9.0.30729.1，方法是在工程設定中增加一個巨集定義_BIND_TO_CURRENT_VCLIBS_VERSION，該巨集定義於C:\Program Files\Microsoft Visual Studio 9.0\VC\include\crtassem.h檔案中，然後重新編譯程式。接下來還是將VC安裝目錄下的redist目錄（C:\Program Files\Microsoft Visual Studio 9.0\VC\redist）中需要的庫以及對應的manifest檔案拷貝到執行程式同目錄下，然後修改manifest檔案中依賴項的版本號為9.0.21022.8，這樣使得程式誤以為該目錄下庫的版本號為9.0.21022.8（實際上是9.0.30729.1版本），這樣程式到任何機器上都能夠正常運行了。

3、打過SP1補丁與SP1 ATL 安全更新 (KB973675)的VS2008

這是最新的更新。在SP1補丁之後，微軟又於近日釋出了一個用於智慧裝置的 Microsoft Visual Studio 2008 Service Pack 1 ATL 安全更新 (KB973675)， 該補丁又將CRT/MFC/ATL庫的版本號升級，為9.0.30729.4148，這次升級比較好，manifest檔案與庫的版本號一致了，不像SP1一樣升級的不徹底。這樣只需要在工程設定中增加一個巨集定義_BIND_TO_CURRENT_VCLIBS_VERSION，接下來重新編譯程式，然後直接把VC安裝目錄下的redist目錄中需要的庫以及對應的manifest檔案拷貝到執行程式同目錄下，這樣程式到任何機器上都能夠正常運行了。

順便提一下，如果不想在釋出程式時帶上這些庫和manifest檔案（如果沒有必要的話），那麼可以採用靜態編譯CRT和MFC，然後把manifest檔案新增到資源中，這樣編譯出的程式只要一個exe就可以在任何機器上直接運行了。

參考文章：

1、“應用程式配置不正確，程式無法啟動”的解決方法資料收集：

有的時候，你在Visual C++上面經過好幾個月的辛勤努力，終於將程式編寫完成並且測試完畢，然而當你試圖在客戶的釋出機上執行剛寫好的程式時，有可能會碰到類似下面的錯誤，作業系統告訴你“由於應用程式配置不正確，應用程式未能啟動。重新安裝應用程式可能會糾正這個問題”.

一般情況下，這個問題都是由於程式不能找到所需要的C執行庫（CRT）而引起的。

在Windows XP SP2以後，Windows引入了Side-by-Side執行的概念，這個概念本來是.NET提出來的，但是Windows後來將這個概念整合到作業系統層面上來了。大家都應該知道Dll Hell的問題，為了解決Dll Hell的問題，Side-By-Side提出不同版本的dll檔案可以同時存在於同一個系統裡面，而且依賴於不同版本dll的應用程式在執行的時候可以使用到它當初被編譯生成的dll。前面的話，有點繞，舉個例子：

1.         假定你編寫了一個C++程式A，是使用MFC 8.0（這個版本是隨著Visual Studio 2005）釋出的。

2.         之後你的機器升級了Visual Studio的版本，從2005升級到2008，2008的MFC庫是9.0版本的，這個時候你的作業系統裡面安裝了兩個版本的MFC，分別是8.0和9.0。

3.         你在Visual Studio 2008編寫了另外一個C++程式B，B依賴與MFC 9.0。

4.         如果你執行程式A的話，作業系統會將MFC 8.0載入到A的程序裡面。

5.         如果你這時同時執行程式B，作業系統會將MFC 9.0載入到B的程序裡面。這就是Side-by-side的執行概念。

作業系統之所以能夠這樣做，是因為它在載入程式A和B之前，除了檢視PE格式裡面A和B所依賴的Dll資訊，都會檢視A和B的manifest檔案。Manifest檔案儲存了Windows可執行檔案（包括exe和dll檔案）要執行起來的環境設定資訊，檔名一般是可執行檔案的檔案全名加上.manifest。例如notepad.exe的manifest檔案就應該是notepad.exe.manifest。例外有的程式將manifest檔案直接嵌入到可執行檔案的資源裡面了，這也就是為什麼有的時候你看不到程式的manifest檔案的原因。通常來說，一個manifest檔案的內容如下（test.exe.manifest檔案）：

<?xml version='1.0' encoding='UTF-8' standalone='yes'?> <assembly xmlns='urn:schemas-microsoft-com:asm.v1' manifestVersion='1.0'> <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">     <security>       <requestedPrivileges>         <requestedExecutionLevel level='asInvoker' uiAccess='false' />       </requestedPrivileges>     </security> </trustInfo> <dependency>     <dependentAssembly>       <assemblyIdentity type='win32' name='Microsoft.VC90.DebugCRT' version='9.0.21022.8'                         processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' />     </dependentAssembly> </dependency> </assembly>

上面的例子裡面，就說明這個程式依賴於CRT 9.0，而且是除錯版的，CPU架構是32位的CPU。對於將manifest檔案嵌入到資原始檔的程式我們也有辦法看到manifest的資訊。

1.         一種是使用mt.exe（Visual Studio自帶的manifest處理程式）：

mt -inputresource:test.exe;#1 /out:test.manifest

2.         另外一種是使用dumpbin程式將整個exe的內容列印到一個檔案，然後用文字編輯器開啟，搜尋Assem字串樣式就能找到manifest資訊：

解決方案

知道了程式依賴於具體哪一個dll以後，你可以將所依賴的dll拷貝到程式的安裝資料夾裡面，以CRT庫繫結失敗為例，介紹解決步驟：

1.從上例中我們知道程式依賴的Microsoft.VC90.DebugCRT庫，版本號是9.0.21022.8，需要32位機器版本的CRT。這個依賴項一般是因為你的程式是除錯版，所以Visual Studio在編譯的時候，將除錯版的CRT加入程式的依賴項。

2.從Visual Studio的安裝資料夾裡面將D:"Program Files"Microsoft Visual Studio 9.0"VC"redist"Debug_NonRedist"x86中的Microsoft.VC90.DebugCRT整個資料夾拷貝到應用程式所在的資料夾裡面，注意：

a)如果你的程式依賴的是32位的CRT，則要拷貝x86資料夾裡面的Microsoft.VC90.DebugCRT資料夾，如果是先x64程式，則要拷貝x64資料夾裡面。

b)你需要確定Microsoft.VC90.DebugCRT資料夾裡面的Microsoft.VC90.DebugCRT.manifest檔案裡面儲存的版本資訊而你程式依賴的版本資訊匹配，Microsoft.VC90.DebugCRT.manifest裡面的版本資訊大版本號一定要一致，小版本號一定要等於或者大於你程式依賴的CRT的小版本號。比如上例中，我們的程式是依賴於CRT 9.0.21022.8，而我們的Microsoft.VC90.DebugCRT.manifest的版本是9.0.30729.1，這樣是可以的；而8.0.30729.1就會有問題。如果大版本號一樣，小版本號不一致的話，一個比較簡單的方案就是修改程式的manifest檔案，使其互相匹配就可以了。

3.如果你的程式不是依賴除錯版本的CRT，而是release版本的CRT，直接去微軟的官方網站下載一個crt redist包安裝上就可以了。

附:解決方案參考：

方案一:

方法一：
在C:\Program Files\Microsoft Visual Studio 8\VC\redi
st\Debug_NonRedist\x86\Microsoft.VC80.DebugCRT 下找到了下列檔案：

msvcm80d.dll
msvcp80d.dll
msvcr80d.dll
Microsoft.VC80.DebugCRT.manifest

把這幾個檔案拷貝到目標機器上，與執行程式同一資料夾或放到system32下，就可以執行那個程式了。

其他release版,MFC程式什麼的都是拷redist下相應資料夾下的檔案就可以了,資料夾後都有標識!

方法二：
修改編譯選項，將/MD或/MDd 改為 /MT或/MTd，這樣就實現了對VC執行時庫的靜態連結，在執行時就不再需要VC的dll了。

方法三:

工程－》屬性－》配置屬性－》常規－》MFC的使用，選擇"在靜態庫中使用mfc"
這樣生成的exe檔案應該就可以在其他機器上跑了。

方法四:

你的vc8安裝盤上找到再分發包vcredist_xxx.exe和你的程式捆綁安裝

我逐一測試下來,直到第三個方法才成功.第二個方法不知道在哪裡修改編譯選項所以放棄了,第四個方法不喜歡,這跟直接安裝.net framework 2.0 有什麼區別嗎?還不如直接安裝.net framework 2.0 呢.

     方案二:

最早出現這個錯誤我和許多人認為的一樣
認為是缺乏DLL庫檔案導致.但是在測試機複製了DLL甚至安裝了.net framework 2.0以後
都無法解決問題,最後確認不是由缺乏DLL所致
因為程式是純win32的應用程,非託管程式碼,所以也無需.net framework

Visual C++2003/2005預設的MFC程式是使用動態MFC庫(Use MFC in a Shared DLL)來連結的
而動態MFC庫使用的是Multi-threaded DLL (/MD)
由於XP對於PE檔案格式監測更加嚴格.
就會導致部分使用多執行緒DLL的可執行檔案在呼叫的時候出錯
修改專案屬性的編譯開關
Project->Property->configuration Properties->C/C++->Code Generation->Runtime Library
修改成Multi-threaded (/MT)
修改了Runtime型別以後
需要將MFC的編譯型別也改成靜態庫
Project->Property->configuration Properties->General->Use of MFC
修改成Use MFC in a Static Library
一部分情況下在這步就能解決問題
另外一部分情況會遇見如下情況
編譯器報錯



CODE:
nafxcw.lib(afxmem.obj) : error LNK2005: "void * __cdecl operator new[](unsigned int)" ([email protected]@Z) already defined in libcpmt.lib(newaop.obj)
[Copy to clipboard]


產生這個問題的原因是庫依賴關係
在Project->Property->configuration Properties->Linker->Command Line
加入編譯開關/verbose:lib可以顯示詳細的庫連結順序
CODE:

------ Build started: Project: PerfMonDemo, Configuration: Release Win32 ------
Linking...
Searching libraries
Searching d:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\lib\pdh.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\lib\DelayImp.lib:
.................
Searching d:\Program Files\Microsoft Visual Studio 8\VC\atlmfc\lib\nafxcw.lib:
Finished searching libraries
.\Release/PerfMonDemo.exe : fatal error LNK1169: one or more multiply defined symbols found
Build log was saved at "file://d:\Dev\Performance Monitor\Release\BuildLog.htm"
PerfMonDemo - 2 error(s), 0 warning(s)
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

[Copy to clipboard]

我們發現在libcpmt.lib宣告過的operator new在nafxcw.lib中再次定義
解決方法如下
Project->Property->configuration Properties->Linker->Input->Additional Dependencies
加入
nafxcw.lib
libcpmt.lib
Project->Property->configuration Properties->Linker->Input->Ignore Specific Library
加入
nafxcw.lib
libcpmt.lib
這樣連結程式就不會先按照預設順序來連線這兩個庫檔案
而是在最後在加入對他們的引用.這樣就避免了這個問題
下面是一張可能發生衝突的列表
若要使用此執行時庫 請忽略這些庫
單執行緒 (libc.lib) libcmt.lib、msvcrt.lib、libcd.lib、libcmtd.lib、msvcrtd.lib
多執行緒 (libcmt.lib) libc.lib、msvcrt.lib、libcd.lib、libcmtd.lib、msvcrtd.lib
使用 DLL 的多執行緒 (msvcrt.lib) libc.lib、libcmt.lib、libcd.lib、libcmtd.lib、msvcrtd.lib
除錯單執行緒 (libcd.lib) libc.lib、libcmt.lib、msvcrt.lib、libcmtd.lib、msvcrtd.lib
除錯多執行緒 (libcmtd.lib) libc.lib、libcmt.lib、msvcrt.lib、libcd.lib、msvcrtd.lib
使用 DLL 的除錯多執行緒 (msvcrtd.lib) libc.lib、libcmt.lib、msvcrt.lib、libcd.lib、libcmtd.lib