我只想添加一些关于 Windows Installer 技术本身的更具体的技术信息，以及导致 WiX 创建的一些历史工具包，因为刚进入安装程序、WiX 和 Windows Installer 领域的人可能会发现这篇文章。
本文旨在从开发人员的角度快速介绍 WiX 和 MSI。还有一篇颇受欢迎的 serverfault.com 文章可能有助于了解 Windows Installer 的优势：The corporate benefits of using MSI files（许多开发人员不喜欢 Windows Installer，但企业部署的优势实际上非常显着 - 如果您认为 MSI麻烦多于值得）。
WiX 工具包的由来
MSI 文件本质上是存储为COM-结构化存储文件的 SQL Server 数据库。这是 Microsoft Office 中使用的文件格式（请注意，MS Office 曾经使用OLE / COM files -但较新的版本现在使用Office Open XML)，它被设计为将分层数据存储在单个文件中的一种方式。本质上是一个文件中的文件系统，具有各种类型的存储流 - 其中之一是要安装在一个或多个 cab files 中的文件。
早期的 MSI 文件/数据库最好直接使用第三方工具修改，例如 InstallShield、Advanced Installer 和 Wise Package Studio（由于法律问题 - 请参阅a comparison of currently available MSI tools)。这些工具将 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 构造来避免。一个好的经理会努力简化部署，但他们需要了解为什么有必要这样做。我喜欢 licensing 作为一个示例，说明如何通过避免老式或不必要的复杂应用程序和部署解决方案来以不同的方式做事并简化部署。
不惜一切代价避免不必要的（读/写）自定义操作 - 它们使设置的复杂性和风险翻了两番。在 StackOverflow 上询问并搜索以查看是否有内置替代方案。在大多数或至少很多情况下，MSI 中有等效的内置结构来完成工作。
这个特别的建议怎么强调都不为过。在我个人看来，read-only custom actions（可以设置属性）恰恰相反：推荐它们。在大多数情况下，它们不会造成明显的额外风险——因为它们不会对需要回滚支持的系统进行任何更改，并且可以非常有效地用于在一个地方收集设置逻辑——而且至关重要的是，它们在同事之间可以很好地工作以允许拾取用简单的脚本语言编写，例如 JavaScript（处理 MSI API 时的一些笨拙方面）或VBScript（错误处理和整体语言功能较差，但经过良好测试MSI API。坦率地说，微软似乎正试图“扼杀”该语言。JavaScript 至少“活得很好”，大量用于网络内容）。
关于脚本的总结：部署专家普遍认为所有类型的脚本操作通常难以调试，容易受到防病毒攻击实现高级编码结构所需的干扰和缺乏语言功能。结论：很难用任何类型的脚本编写健壮的代码。 strong> 可以使用托管代码自定义操作 (.NET)，但由于需要安装 .NET，因此安全的建议是使用 C++ 编写自定义操作。这允许最小的依赖关系、非常好的调试和高级语言结构。这个问题在这里有一个很长的“讨论”：pros and cons of different custom action types（不是很好，只是现实世界经验的转储）。不过可能值得略读一下 - custom actions are the leading cause of deployment failures（链接到我对他们的宣传），这将我们带到了下一点：部署的整体复杂性（以及如何处理它）。
部署的复杂性
部署是将异构目标计算机从一种稳定状态迁移到另一种稳定状态的复杂过程 - 这需要严谨的方法，因为： p>
-
错误在本质上是累积的 - 您越是尝试通过快速修复来解决问题，通常会导致更多问题。很快你就不可能在你的手上维护，因为问题通常是“在野外”（已发布）并且必须像交付过程一样处理 - 每次迭代都有自己的附加风险，而不仅仅是一个问题调试，直到你有一个修复。
-
当您无法访问相关系统时，错误极难调试。日志记录在正确完成时会有所帮助，但当您需要它进行调试时，它通常不会交付给您，或者格式错误或冗长，或者完全无用，因为自定义操作通常无法正确记录事情。李>
-
目标系统（和目标环境）几乎在所有可以想象的方面都不同（即使它是标准操作环境 (SOE)，因为大多数公司使用标准化的操作系统安装和软件包）：硬件和驱动差异（大小）、胖客户端/瘦客户端、终端服务器、操作系统平台（x86/x64/等...）、操作系统版本（Win7、Win10、WinXP等...）、操作系统版本（终极版、家庭版等）、操作系统语言版本、操作系统升级状态和补丁级别、恶意软件情况、磁盘空间问题、分区方案、文件系统类型、加密问题（文件系统、网络）、用户权限设置、UAC 配置、系统权限配置（NTRights）、连接类型、连接速度、网络配置（域、工作组等）、子网、代理设置、电子邮件系统和配置（Exchange、Outlook、Novell 等）。 .)、活动目录、身份验证方案、网络共享和驱动器、应用程序资产、脚本可用性、脚本锁定、各种运行时版本（C、C++、MFC、ATL、ADO、OLE DB、ADO.NET、Java、脚本运行时）、COM 和 DCOM 对象注册和配置、COM+、IIS 和 Web 服务器、路径变量和环境变量、文件关联和 shell 操作、无线软件设置、用户数量、.NET 版本和配置、语言包、GAC 和 WinSxS 状态和配置（策略文件）、软件防火墙、模拟/虚拟化系统、部署系统（ SCCM、Tivoli 等...）。它一直在继续。
部署是一个简单的概念，具有复杂的变量组合，可能导致最神秘的错误 - 包括开发人员最喜欢的：间歇性错误。众所周知，此类错误的严重性不容小觑，因为它们通常无法正确调试。
更多关于部署和现代安装程序可能需要做的事情：What is the benefit and real purpose of program installation?。这是一个设置可能需要执行哪些任务的摘要，其中包含各种技术细节。可能添加了太多细节，可能会破坏答案的“概述质量”。但是，其目的是与开发人员保持相关性。
相关微星工具
Visual Studio MSI 项目文件是作为 Visual Studio 的一部分创建 MSI 文件的轻量级方法，它的功能集极为有限。有人讨论用 WiX XML 项目替换 Visual Studio 中的 MSI 项目类型，这通常是人们现在构建 MSI 文件的方式。不要使用此项目类型。由于缺乏灵活性和严重的错误，它给许多用户带来了严重的问题。
Orca 是 Windows SDK 工具，它允许打开、编辑二进制 MSI 文件并进行一定程度的比较。事实上，它主要是由后来创建 WiX 工具包本身的人编写的。 Rob Mensching，当时他在 Microsoft 的 Windows Installer 团队工作。该工具还允许其他操作，例如生成用于修改 MSI 文件的转换文件和一些其他技术操作。虽然它是一个非常基本的工具，缺乏商业工具中可用的最高级功能，但它仍然是应用程序打包程序的最爱，可用于调试和小修复 由于其可靠性、简单和“cleanliness” - 保存时不会将“默认垃圾”添加到 MSI （第三方工具添加自定义表格和类似的垃圾）。我将它用于小型 MSI 更新、调试、inspection of the summary stream、创建基本转换、查看补丁、 包验证等重要操作。
事实上，我猜它是一个高级工具，具有简单的界面 - 根本不是一个基本工具:-)。为了获得 Orca，您需要安装 Windows SDK (!)。当工具的大小如此之小时，确实有点过头了，但至少很容易知道它在哪里可用，而不是寻找单独的下载。
更新：如果您安装了 Visual Studio 和 SDK，请搜索 Orca-x86_en-us.msi 并安装它。如果你没有，也许有安装了 Visual Studio 的朋友搜索它然后发送给你？这是一个小文件。
还有一些可供选择的免费工具，如下所述（靠近底部）：How can I compare the content of two (or more) MSI files?
DTF - 部署工具基础 是一个 .NET 类套件，用于以编程方式处理 MSI 文件。 now included with the main WiX download 写得很好，易于使用且功能强大。它是任何项目中企业使用 MSI 文件的关键组件。 Here is a brief answer on serverfault.com 讨论其使用并描述其基本组件。 DTF 中包含的帮助文件将帮助您快速使用该工具包，并且您永远不会回头使用 Win32 函数或 COM 类来访问 MSI 文件。
市场上有许多其他 Windows Installer 工具，您可以在 What installation product to use? InstallShield, WiX, Wise, Advanced Installer, etc 找到其中一些与 WiX 相比的工具（与上述相同的链接）。