我只是想添加一些更具体的内容技术信息关于 Windows Installer 技术本身，以及一些history导致WiX 工具包的创建因为刚刚进入安装程序、WiX 和 Windows Installer 领域的人可能会发现这篇文章。
这是为了快速介绍WiX and MSI from a 开发者视角。 serverfault.com 上还有一篇颇受欢迎的文章，可能有助于了解 Windows Installer 的优点：使用 MSI 文件的企业优势 https://serverfault.com/questions/11670/the-corporate-benefits-of-using-msi-files/274609#274609（许多开发人员不喜欢 Windows Installer，但企业部署的好处实际上相当显着 - 如果您认为 MSI 带来的麻烦大于其价值，也许值得快速浏览一下）。
WiX 工具包的由来
MSI 文件本质上是剥离 SQL Server 数据库，存储为COM http://en.wikipedia.org/wiki/Component_Object_Model- 结构化存储文件。这是 Microsoft Office 中使用的文件格式（请注意，MS Office 过去使用OLE/COM 文件 https://en.wikipedia.org/wiki/COM_Structured_Storage- 但现在较新的版本使用办公室开放 XML https://en.wikipedia.org/wiki/Office_Open_XML），它被设计为一种在单个文件中存储分层数据的方法。本质上是一个文件内的文件系统，具有各种类型的存储流 - 其中之一是要安装在一个或多个内部的文件出租车文件 http://en.wikipedia.org/wiki/Cabinet_(file_format) .
Early on MSI files / databases were best modified directly using third-party tools such as InstallShield http://en.wikipedia.org/wiki/InstallShield, Advanced Installer http://www.advancedinstaller.com/ and Wise Package Studio (no longer available due to legal issues - see a comparison of currently available MSI tools https://stackoverflow.com/questions/1544292/what-installation-product-to-use-installshield-wix-wise-advanced-installer/1546941#1546941).These tools stored the MSI file in its native "installable" format as a COM structured storage file. This meant your MSI file was both source and executable - and in binary format. This made source control of your installation project difficult. Binary diffs on different MSI databases were difficult, and due to database referential integrity even the most basic changes in the MSI will cascade through dozens of tables and make it difficult to see what changed even for trained eyes.
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 - 这一次会更容易:-)。
大多数时候我们发现不寻常的设置设计并且使用自定义操作会导致很多不必要的复杂性，或者部署反模式如果你愿意的话，这个问题通常可以通过以下方式避免应用程序设计的小变化, or 使用内置 MSI 结构。一个好的管理者会努力简化部署，但他们需要理解为什么这是必要的。我喜欢许可 https://stackoverflow.com/questions/24359248/installer-with-online-registration-for-windows-application/24360658#24360658作为一个示例，说明如何通过避免老式或不必要的复杂应用程序和部署解决方案来以不同的方式做事并简化部署。
不惜一切代价避免不必要的（读/写）自定义操作- 它们使设置的复杂性和风险增加了四倍。在 Stack Overflow 上询问并搜索以查看是否有内置替代方案。在大多数或至少很多情况下，MSI 中有等效的内置构造来完成工作。
This particular advice can not be overstated. In my personal opinion, read-only custom actions http://forum.installsite.net/index.php?showtopic=21645#entry60802 (that may set properties) are the opposite: they are recommended. They do not cause significant extra risk in most cases - since they make no changes on the system requiring rollback support, and can be used very effectively to gather setup logic in one place - and crucially they work well between co-workers to allow picking up each other's work when written in simple scripting languages such as JavaScript https://en.wikipedia.org/wiki/JavaScript (some clunky aspects when dealing with the MSI API) or VBScript http://en.wikipedia.org/wiki/VBScript (poor error handling and overall language features, but well tested with the MSI API. Frankly it seems like Microsoft is trying to "kill" the language. JavaScript is at least "alive and well" in heavy use for web-stuff).
总结一下关于脚本的事情：部署专家普遍认为所有类型的脚本操作都是通用的难以调试, 容易受到反病毒干扰 and 缺乏语言特征需要实现高级编码结构。综上所述：使用任何类型的脚本编写健壮的代码都很困难。托管代码自定义操作是可能的 (.NET)，但由于需要安装 .NET，安全建议是使用 C++ 编写自定义操作。这允许最小的依赖性、非常好的调试和高级语言结构。这里对这个问题有一个很长的“讨论”：不同自定义操作类型的优缺点 https://stackoverflow.com/questions/46045359/windows-installer-fails-on-win-10-but-not-win-7-using-wix/46058543#46058543（不是很好，只是现实世界经验的转储）。不过，这可能值得浏览一下——自定义操作是部署失败的主要原因 https://stackoverflow.com/questions/46179778/why-is-it-a-good-idea-to-limit-the-use-of-custom-actions-in-my-wix-msi-setups/46179779#46179779（链接到我针对他们的宣传），这给我们带来了下一点：部署的整体复杂性（以及如何处理它）。
部署的复杂性
部署是将异构目标计算机从一种稳定状态迁移到另一种稳定状态的复杂过程
