Windows Installer 和 WiX 的創建

Question

我們目前使用 WiX 來構建我們的 MSI 文件，因此它是我使用過的唯一 MSI 構建器。 我知道您可以在 Visual Studio 中本地構建安裝程序。 使用 WiX 和 Windows Installer 之間有什么區別，各自的優缺點是什么？

Answer 1

我只想添加一些關於 Windows Installer 技術本身的更具體的技術信息，以及一些導致WiX 工具包創建的歷史，因為這篇文章可能會被剛剛進入安裝程序 WiX 領域的人發現和 Windows 安裝程序。

這旨在從開發人員的角度快速介紹WiX和MSI 。 還有一篇頗受歡迎的 serverfault.com 文章可能有助於了解 Windows Installer 的優勢： 使用 MSI 文件的企業優勢（許多開發人員不喜歡 Windows Installer，但企業部署優勢實際上非常重要 - 如果你認為 MSI 比它的價值更麻煩）。

WiX 工具包的起源

MSI 文件本質上是精簡的 SQL Server 數據庫，存儲為COM結構的存儲文件。 這是 Microsoft Office 中使用的文件格式（請注意，MS Office 曾經使用OLE/COM 文件- 但現在較新的版本使用Office Open XML ），它被設計為一種在單個文件中存儲分層數據的方式。 本質上是文件內的文件系統，具有各種類型的存儲流——其中一種是要安裝在一個或多個cab 文件中的文件。

早期的 MSI 文件/數據庫最好直接使用第三方工具進行修改，例如InstallShield 、 Advanced Installer和智包工作室 （由於法律問題不再可用 - 請參閱當前可用 MSI 工具的比較）。這些工具將 MSI 文件以其原生“可安裝”格式存儲為 COM 結構化存儲文件。 這意味着您的 MSI 文件既是源文件又是可執行文件 - 並且是二進制格式。 這使您的安裝項目的源代碼控制變得困難。 不同 MSI 數據庫上的二進制差異很困難，並且由於數據庫引用完整性，即使是 MSI 中最基本的更改也會通過數十個表級聯，即使訓練有素的眼睛也很難看到發生了什么變化。

WiX 的出現是作為開發人員允許從常規文本源文件創建二進制 MSI 文件的一種方式。 就像常規的 EXE 二進制文件一樣，MSI 二進制文件是從 WiX 文本 XML 文件“編譯”的。 在管理發布過程和理解 MSI 文件中的更改方面，這是一個巨大的飛躍。 該工具包對開發人員來說非常全面和直觀，並且具有一定程度的“自動魔術”功能，因為它使開發人員免受 MSI 數據庫模式的一些復雜性的影響，因為更改是在具有自己的模式的 XML 格式中進行的，而不是數據庫本身。 實際上，WiX 將 MSI 從其數據庫起源帶入了今天的“XML 時代”，以便開發人員可以使用文本文件，並且可以將 MSI 文件視為已編譯的可執行文件，而不是數據庫源文件。

實際上可以制作好的 MSI 文件而無需對 MSI 文件的內部工作了解太多 - 只要您遵循 WiX 最佳實踐- 並且相信我作為開發人員，您會希望遠離 MSI 文件。 對於開發人員的思維方式來說，它們很復雜，而且非常非正統和違反直覺。 它與將整個安裝程序存儲為單個數據庫的復雜性有關。 它幾乎完全是聲明性的而不是程序性的 - 但有些部分是連續的並定義了安裝順序。 許多活動部件和“陰謀復雜性”的發條（當您認為一切都很好時發現的陷阱）。

這些排序結構是 MSI 中最復雜的部分，涉及“提升的權限”和作為數據庫事務運行的文件系統操作。 當您作為開發人員學習 MSI 時，您一定會覺得“這種設計有問題”，而事實是，整個技術是圍繞當時的 Office 部署要求設計的 - 它變得如此復雜必須是。 此外，MSI 文件可能是未來事物的預覽——也許 Windows 將來會使用 SQL Server 作為其主要存儲解決方案，而 MSI 是將部署轉變為“聲明性語言”或巨大 SQL 語句的第一步。部署期間會在目標系統上發生嗎？ 不過這也只是猜測。

一些實用的 WiX 建議

保持簡單，遵循最佳實踐，無論您做什么，都不要與設計抗爭——它會反擊。 如果 WiX 不能做到，它可能會試圖幫助您避免部署問題。 與您的經理對抗以簡化或更改要求，而不是 MSI - 一次更容易:-)。

大多數時候我們發現不尋常的設置設計和自定義操作的使用會導致很多不必要的復雜性，或者如果您願意，可以使用部署反模式，而問題通常可以通過應用程序設計的微小變化來避免，或者使用內置 MSI 結構。 一個好的管理者會允許努力簡化部署，但他們需要了解為什么這是必要的。 我喜歡將許可作為一個例子，說明如何通過避免老式或不必要的復雜應用程序和部署解決方案來以不同方式做事並簡化部署。

不惜一切代價避免不必要的（讀/寫）自定義操作- 它們使設置的復雜性和風險增加了四倍。 在 Stack Overflow 上詢問這里並搜索是否有內置替代方案。 在大多數或至少許多情況下，MSI 中有等效的內置結構來完成工作。

這個特別的建議不能被誇大。 在我個人看來， 只讀自定義操作（可以設置屬性）正好相反：推薦使用它們。 在大多數情況下，它們不會造成顯着的額外風險——因為它們不會對需要回滾支持的系統進行任何更改，並且可以非常有效地用於在一個地方收集設置邏輯——而且至關重要的是，它們在同事之間工作良好以允許接聽用簡單的腳本語言編寫時彼此的工作，例如 JavaScript （處理 MSI API 時的一些笨拙的方面）或VBScript （糟糕的錯誤處理和整體語言功能，但使用 MSI API 進行了很好的測試。坦率地說，微軟似乎正試圖“殺死”該語言。JavaScript 至少是“活着的”以及”大量用於網絡內容）。

總結一下關於腳本的事情：部署專家普遍認為，所有類型的腳本操作通常都難以調試，容易受到反病毒干擾，並且缺乏實現高級編碼結構所需的語言功能。 總之：很難用腳本編寫健壯的代碼 - 任何類型。 托管代碼自定義操作是可能的 (.NET)，但由於它們需要安裝 .NET，因此安全的建議是用 C++ 編寫自定義操作。 這允許最小的依賴性、非常好的調試和高級語言結構。 這里有一個關於這個問題的長篇“討論”： 不同自定義操作類型的優缺點（不太好，只是現實世界經驗的轉儲）。 不過可能值得一讀—— 自定義操作是部署失敗的主要原因（鏈接到我針對它們的宣傳），這將我們帶到下一點：部署的整體復雜性（以及如何處理它）。

部署的復雜性

部署是將異構目標計算機從一種穩定狀態遷移到另一種穩定狀態的復雜過程- 這需要有紀律的方法，因為：

1. 錯誤本質上是累積性的——你越是試圖用快速修復來解決問題，往往會導致更多的問題。 很快，您將無法維護，因為問題通常是“不確定的”（已發布）並且必須像交付過程一樣處理 - 每次迭代都有其自己的附加風險，而不僅僅是一個問題調試直到你有一個修復。
2. 當您無法訪問相關系統時，錯誤很難調試。 如果做得好，日志記錄會有所幫助，但是當您需要它進行調試時，它通常不會交付給您，或者它的格式或冗長錯誤，或者完全無用，因為自定義操作通常不會正確記錄事情。
3. 目標系統（和目標環境）在幾乎所有可以想象的方面都不同（即使它是標准操作環境 (SOE)，因為大多數公司使用標准化的操作系統安裝和包，情況也是如此）：硬件和驅動程序差異（大和小）、胖客戶端/瘦客戶端、終端服務器、操作系統平台（x86/x64/etc...）、操作系統版本（Win7、Win10、WinXP等...）、操作系統版本（終極版、家庭版等.. .)、操作系統語言版本、操作系統升級狀態和補丁級別、惡意軟件情況、磁盤空間問題、分區方案、文件系統類型、加密問題（文件系統、網絡）、用戶權限設置、UAC配置、系統權限配置（ NTRights ） 、連接類型、連接速度、網絡配置（域、工作組等）、子網、代理設置、電子郵件系統和配置（Exchange、Outlook、Novell 等）、活動目錄、身份驗證方案、網絡共享和驅動器、應用程序資產、腳本可用性、腳本鎖定 n、各種運行時版本（C、C++、MFC、ATL、ADO、OLE DB、ADO.NET、Java、腳本運行時）、COM和DCOM對象注冊和配置、COM+、IIS和Web服務器、路徑變量和環境變量、文件關聯和外殼操作、無線軟件設置、用戶數量、.NET 版本和配置、語言包、GAC 和 WinSxS 狀態和配置（策略文件）、軟件防火牆、模擬/虛擬化系統、部署系統（SCCM、Tivoli ， 等等...）。 它會一直持續下去。

部署是一個簡單的概念，具有復雜的變量組合，可能導致最神秘的錯誤 - 包括開發人員最喜歡的：間歇性錯誤。 眾所周知，此類錯誤的嚴重性不能被誇大，因為它們通常無法正確調試。

更多關於部署以及現代安裝程序可能需要做什么： 程序安裝的好處和真正目的是什么？ . 這是一個設置可以完成哪些任務的摘要，其中包含各種技術細節。 可能添加了太多細節，可能會破壞答案的“概述質量”。 然而，目的是保持與開發人員的相關性。

---

相關的 MSI 工具

Visual Studio MSI 項目文件是作為 Visual Studio 的一部分創建 MSI 文件的輕量級方法，它的功能集極其有限。 有討論用 WiX XML 項目替換 Visual Studio 中的 MSI 項目類型，這通常是人們現在構建 MSI 文件的方式。 不要使用這種項目類型。 由於缺乏靈活性和嚴重的錯誤，它給許多用戶帶來了嚴重的問題。

Orca是Windows SDK工具，它允許打開、編輯二進制 MSI 文件並進行一定程度的比較。 事實上，它主要是由后來創建 WiX 工具包本身的人編寫的。 Rob Mensching在 Microsoft的Windows Installer 團隊工作時。 該工具還允許其他操作，例如生成用於修改 MSI 文件的轉換文件和一些其他技術操作。 雖然它是一個非常基本的工具，缺乏商業工具中可用的最高級功能，但它仍然是應用程序打包者最喜歡使用的，並且由於其可靠性、簡單性和“清潔”而可用於調試和小修復- 它不添加“默認值”垃圾”保存到 MSI 時（第三方工具添加自定義表和類似的垃圾）。 我將它用於小型 MSI 更新、調試、 檢查摘要流、創建基本轉換、查看補丁、包驗證和其他重要操作。

事實上，我猜它是一個高級工具，界面簡單——根本不是基本工具:-)。 為了獲得 Orca，您需要安裝Windows SDK (!)。 當工具的大小如此之小時，確實有點過頭了，但至少很容易知道它在哪里可用，而不是尋找單獨的下載。

更新：如果您安裝了 Visual Studio 和 SDK，請搜索Orca-x86_en-us.msi並安裝它。 如果沒有，也許有安裝了 Visual Studio 的朋友搜索它然后發送給你？ 它是一個小文件。

還有一些替代的免費工具可用，如下所述（朝底部）： 如何比較兩個（或更多）MSI 文件的內容？

DTF - 部署工具基礎是一個 .NET 類套件，用於以編程方式處理 MSI 文件。 寫得好，易於使用且非常強大，它現在包含在主要的 WiX 下載中。 它是任何項目中自動化企業使用MSI 文件的重要組成部分。 這是 serverfault.com 上的簡短回答，討論了它的使用並描述了它的基本組件。 DTF 中包含的幫助文件將使您快速使用該工具包，而且您永遠不會回頭使用 Win32 函數或 COM 類來訪問 MSI 文件。

市場上還有許多其他 Windows Installer 工具，您可以在使用什么安裝產品？ InstallShield、WiX、Wise、Advanced Installer 等（與上面相同的鏈接）。

Answer 2

WiX 創建使用 Windows Installer 的 MSI 包。 所以 WiX 使用 Windows Installer 引擎。

Visual Studio 只是一個 WiX 替代方案，只是另一個設置創作工具。 我不推薦它，因為它非常有限。 它僅提供基本功能。

如果您對 WiX 感到滿意，請繼續使用它。