我有一個項目依賴於特定版本的MSVCR80.dll（MS Visual C運行時），我遇到了問題，根據特定的系統配置，我的應用並不總是獲得該文件的正確版本。關於用這個名字找到一個文件需要什麼路徑，這是一個廢話拍攝，它並不總是正確的...在VS2005中包含MS C++運行時生成的MSI
有沒有辦法，當在VS2005中創建一個部署項目，到保證我的應用程序將總是使用我提供的運行時？當我將運行時文件添加到項目中時，它會詢問有關創建合併模塊的信息......但並不確定它會做什麼。而不管創建一個，問題依然存在。
馬丁·里克特寫某篇文章在CodeProject： Create projects easily with private MFC, ATL and CRT assemblies
該解決方案不依賴於MSI包，但對使用的CRT文件的應用程序。
我不確定它是否是您的應用程序安裝後不起作用，或者如果它是您使用作爲安裝不起作用的一部分的DLL？要做一個很長的故事，很簡短：新版本的C/C++運行時安裝爲Win32程序集或並排安裝。這意味着這些文件將進入文件夾C：\ Windows \ winsxs - GAC的Win32等效項，並且可以在此共存同一文件的多個版本。
應用程序與的Visual Studio2008分之2005編譯會放一個清單文件成二進制，而這個清單指定什麼並排端運行時版本綁定到。將MSVCR80.dll放在EXE或甚至是system32的旁邊並不重要 - 嵌入在EXE中的清單將從加載文件C：\ Windows \ winsxs。
這是所有「完整的圓」。在過去，運行時間進入System32。這導致原始的dll-hell：應用程序覆蓋彼此的全局運行時文件。爲了彌補這一切，這個想法是爲每個應用程序「隔離更改」。因此，新方法是隔離EXE旁邊的運行時文件的本地副本。現在，這引發了一個全新的問題：您如何確保部署隔離dll的安全更新？在大多數情況下，這絕不會發生，並且你有很多應用程序在運行本地，不安全的dll。那麼該怎麼辦？決定是介紹dll-hell的第二次來臨：並排組裝方法。在這種方法中，運行時不是本地的，而是全局的 - 與支持並行安裝的關鍵區別。這樣，理論上，應用程序可以在不覆蓋彼此的運行時DLL的情況下運行。
這就是「如何使運行時部署變得複雜」的快速總結。我不積極，它仍然有可能做，但你檢查你是否可以靜態鏈接到運行時？有時老派真的更容易...
不幸的是，我不能真正修改應用程序... – 2009-05-18 12:57:49