[T] 這個應用程式無法啟動 @ Edison.X. Blog

這個應用程式無法啟動，因為找不到 MSVCD90D.dll，

重新安裝應用程式可能可以解決這個問題

玩遊戲時，有些人會遇到這問題；而在程式設計開發中，這問題幾乎是所有人會遇到的問題。比較常見到的「症頭」是類似上面這行字，其中的 MSVCD90D.dll 可能會換成其它字樣。這種問題最常見到的衍生是

自己的電腦可以 compile 、生成出執行檔、可正常執行，
但直接將該執行檔複制給別人卻沒辦法執行。

這裡提出簡單的二個解決方案做參考。

1. 到 Microsoft 下載散佈包

這應是最一勞永逸的方法，什麼原理、有的沒的都不用了解。以上述的 MSVCD90D.dll，指的是用 Microsoft Visual C++ 9.0 (註1) 所開發。其中最後一個英文字母 D 表示是 Debug Mode，代表這很可能只是還在發展期之程式，故即使能正常執行，速度效能上應差了一點。

若為上述情況，請到此下載並安裝散佈包。

[註一] MSVCD90D.dll，MS 代表 Microsoft ，VC 代表 Visual C++，9.0 是版本，大多都是記 Visual C++ 2008 (2008 年發行) 沒記錯的話版本對話字如下對應

6.0 x
7.0 2002
7.1 2003
8.0 2005
9.0 2008
10.0 2010

所以就算要安裝散佈包，也要挑對 CPU 架構 (X86, AMD64)、使用之版本，以此例而言，dll 出現字樣為 90，便該安裝的是 VC 2008 之散佈包。若出現 xxxx10.dll ，則應安裝之散佈包為 VC 2010。

2. 直接從開發之電腦拉出 DLL 一起附上

這不是什麼好方法，但卻是提供給了懶人客戶的一個方法 (真有些客戶是完全不想再安裝什麼散佈包有的沒的)。

(1) 首先，到開發電腦裡面，到以下目錄 (假設安裝目錄都為預設)

C:\Program Files\Microsoft Visual Studio 9.0\VC\redist

(2) 這時會發現裡面有三個資料夾

amd64、Debug_NonRedist、x86，若開發模式是在 debug mode，則必須再進入 Debug_NonRedist資料夾裡面，一樣裡面還是會有 amd64、x86 資料夾。若是 release mode，則就不用再進資料夾裡面。

(3) 選擇所需之dll 檔

一般電腦大多為 x86 架構，不確定客戶端電腦是何種架構[註2]，那下述的東西都 copy 一份出來。最簡便的方式是，在該資料夾 (以 x86 為例) 底下，直接搜尋 *.dll，及直接搜尋 *.manifest，好了之後全都再 copy 出來，接著再和開發出來的執行檔放在同一路徑，壓縮後一起包給客戶即可。x86 全包的話大概 20MB 左右，但只要包這次，下次再有執行檔，用之前給的 dll 放進同一目錄下即可。

也可考慮由 coder 寫份 batch (堅持用 C/C++寫也可以)，將 dll 先複制到指定路徑中，再新增一環境變數，路徑設至此處，此後 release 出來的程式碼便可直接執行，不需與 .dll / .manifest 同一路徑。這部份詳細說明應先研究「何謂環境變數」與「 MSVC 上之環境變數」。

[註2] 欲知何種架構並不難，若是用 C 語言寫的話可這麼做

#include <stdio.h>
#include <string.h>

#define STRING_ARCHI "PROCESSOR_ARCHITECTURE"

int main(int argc, char **argv, char**env)
{
    int i=0;
    char *ptr;
    while(env[i]!=NULL) {
       if(!strnicmp(env[i], STRING_ARCHI, strlen(STRING_ARCHI))){
          break;
       }
       ++i;
    }
    printf("%s\n", env[i]);
    ptr = strchr(env[i], '=');
    printf("%s\n", ptr+1);
    return 0;
}

其中 strnicmp (不分大小寫只比較部份字串) 雖非標準函式，視 compiler library 有無支援，但非本文探討重點，這部份也可自行處理。若不想用 C 寫，可直接從我的電腦-> 右鍵 -> 內容 -> 進階 -> 環境變數 -> 系統變數，查看 PROCESSOR_ARCHITECTURE 之值為何。

3. coder 開發時顯示此問題

這問題的確是因為 MS 在開發時沒考慮到，在 FAT32 之硬碟分割開發時確時有此份問題。由於 VC2005 / 2008 在生成執行檔時，會「順便」生成一份文件清單，這份文件清單副檔名為 manifest，伴隨生成在 Debug/Release 資料夾內。本質上 manifest 為一 XML 檔，這裡不再解釋，想更深入了解再去 msdn 查相關說明。

記得程式開發的「大致」流程吧？

Coding -> Preprocessor -> Compile -> Link -> Exe

當在 Compile 完成時，便會生成了一份 manifest，此時進行 Link 時，預設情況會將該 manifest 清單上之文件再崁到 exe 裡面去。然而於 FAT32 下，在進行 Link 時，並不會對該 manifest 進行清單之更新，所以常有第一次可以生成 exe，之後再做 Link 時，由於沒辦法更新清單，就會產生上述之錯誤訊息。

問題解決方案的確不少，大致上只舉幾個例子，但在失敗後若要嚐試，建議先把 Debug 資料夾整個給刪掉， ReBuild。

(1) IDE 上設定 / CL.exe 上下手

這方法應是從 MSDN 官方上提出的有效解決方法。

a. 專案->屬性 (Alt+F7)
b. 組態屬性 -> 連結器 -> 偵錯
c. 右方，「產生對應檔」改為「是 (/MAP)」
d. 點「資訊清單」，將裡面的「使用 FAT32 解決辦法」改為「是」

也有人提出下面方法，但很不建議

/MDd 和 MSVCRTD.LIB 偵錯程式庫連結
/MTd 和 LIBCMTD.LIB 偵錯程式庫連結

Link 方式改選 /MTd ，但這方法很不實用，基本上產生的執行檔會肥出 5~10 倍。

(2) 修改清單

這方法我認為還不到這種必要，Visual Studio 做得最好的便是讓 Coder 專心致力於開發程式，其它 compiler 參數問題幾乎都沒必要讓 Coder 去煩惱 (當然大型專案除外)，為了此問題而去研究如何修改 manifest ，倒不如花時研究 CL.exe 與 NMAKE.exe 較為實際。 (研究 manifset 不是壞事，研究過程中勢必可增加對於程式語言生成執行檔之過程。)

(3) 直接從 FAT32 轉 NTFS

既已知是檔案系統所造成，何不對症下藥？這是比較建議的方式，若像第一個解決方案，每次開一個專案都要像上面的方式做設定，不是個好現象，比較建議是直接從 FAT32 轉成 NTFS 分割。開啟命令提示字元，輸入

Convert C: /FS:NTFS (C: 為安裝 VC 之磁碟區)

會提示是否要轉檔案系統，按確定後會自動重新開機，接下來就讓它跑完吧，會花久一點時間，但認為這是一勞永逸的方式。別擔心會轉失敗，機率應該是不高，目前我轉過八台電腦，八台都轉成功，但的確是需要「耐心等候」 (這也不能說明一定不會失敗，我也沒看過失敗是長怎樣)。類似的解決方案，即是再用分割工具分出一槽，格式化為 NTFS，讓 VC 安裝在上面。這方法不會比 Convert 還容易、快，因為要重新再安裝一次 VC，但若有「不可抗拒理由」絕不能將 C 槽轉成 NTFS，此方法倒是可考慮。