wix - Windows Installer和WiX的创建

Question

目前，我们使用WiX构建我们的MSI文件，因此，这是我有经验的唯一MSI构建器。我知道您可以在Visual Studio中本地构建安装程序。使用WiX和Windows Installer有什么区别，两者各有什么优缺点？

Answer 1

我只想在Windows Installer技术本身上添加一些更具体的技术信息，以及一些导致创建wit工具包的历史，因为该帖子可能会被刚接触该技术的人找到。安装程序的字段，即WiX和Windows Installer。

本文旨在从开发人员的 Angular 快速介绍 WiX 和 MSI 。还有一篇颇受欢迎的serverfault.com文章，可能对了解Windows Installer的好处很有用:The corporate benefits of using MSI files(许多开发人员不喜欢Windows Installer，但是公司部署的好处实际上是非常重要的-如果您认为MSI更加麻烦，那么可能值得快速浏览比它值得的)。

WiX工具包的由来

MSI文件本质上是剥离的SQL Server数据库，存储为COM结构化的存储文件。 这是Microsoft Office中使用的文件格式(请注意，MS Office曾经使用OLE / COM files-但现在较新的版本使用Office Open XML)，并且它被设计为在单个文件中存储层次结构数据的一种方式。本质上，文件中的文件系统具有各种类型的存储流-其中一个文件是要安装在一个或多个cab files中的文件。

最好使用第三方工具(例如InstallShield，Advanced Installer和Wise Package Studio )直接对MSI文件/数据库进行修改(由于法律问题，该工具不再可用-参见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文件。它们很复杂，并且对于开发人员的思维方式来说，明显是非传统的和违反直觉的。它与将整个安装程序存储为单个数据库的复杂性有关。它几乎完全是声明性的，而不是过程性的-但是某些部分是顺序的并定义安装顺序。许多 Activity 部件和“阴谋复杂性”发条(当您认为一切都很好时发现的陷阱)。

这些排序结构是MSI中最复杂的部分，涉及“高权限”，文件系统操作作为数据库事务运行。当您以开发人员的身份学习MSI时，一定会感觉到“此设计有问题”，而的事实是，整个技术都是围绕Office 的部署要求而设计的，而且变得如此复杂确实如此。此外，MSI文件可能是 future 的预览-也许Windows将来会使用SQL Server作为其主要存储解决方案，而MSI是将部署转变为“声明性语言”或针对其内容的大型SQL语句的第一步。部署期间将在目标系统上发生什么？虽然这只是猜测。

一些实用的WiX建议

保持简单，遵循最佳实践，无论您做什么都不反对设计-它都会反击。如果WiX无法做到这一点，则可能是在尝试帮助您避免部署问题。与您的经理一道，简化或更改需求，而不是MSI，这很容易:-)。

大多数情况下，我们发现不寻常的设置设计和使用自定义操作会导致很多不必要的复杂性，如果愿意，可以使用部署反模式，而在应用程序设计中进行细微更改通常可以避免此问题或使用内置的MSI构造。一个好的经理将允许您简化部署，但是他们需要了解为什么有必要。我喜欢licensing作为一个示例，该示例说明了如何通过避免过时的或不必要的，复杂的应用程序和部署解决方案来不同地做事并简化部署。

不惜一切代价避免不必要的(读/写)自定义操作-它们使设置的复杂性和风险增加了四倍。在Stack Overflow上询问并搜索是否有内置替代方法。在大多数或至少许多情况下，MSI中有等效的内置结构可以完成工作。

不能夸大其词。我个人认为read-only custom actions(可以设置属性)是相反的:建议使用它们。在大多数情况下，它们不会造成重大的额外风险-因为它们无需更改需要回滚支持的系统，并且可以非常有效地用于在一个地方收集设置逻辑-而且至关重要的是，它们在同事之间可以很好地工作以允许接机彼此的工作以简单的脚本语言编写，例如JavaScript(处理MSI API时有些笨拙的方面)或VBScript(差的错误处理和总体语言功能，但已通过MSI API进行了很好的测试。坦率地说，微软似乎正在尝试“杀死”该语言。JavaScript至少在网络 Material 中大量使用。

总结有关脚本的问题:部署专家之间普遍达成共识，即所有类型的脚本操作通常难以调试，易受反病毒干扰和缺乏实现高级功能所需的语言功能编码结构。结论:很难用任何类型的脚本编写健壮的代码。 可以执行托管代码自定义操作(.NET)，但是由于要安装.NET的要求，因此安全的建议是使用C++编写自定义操作。这允许最小的依赖关系，非常好的调试和高级的语言构造。这个问题在这里有很长的“讨论”:pros and cons of different custom action types(不是很好，只是真实经验的转储)。也许值得一看- custom actions are the leading cause of deployment failures (链接到我对他们的宣传)，这将我们带到了下一点:部署的总体复杂性(以及如何处理)。

部署的复杂性

部署是将异构目标计算机从一种稳定状态迁移到另一种稳定状态的复杂过程-这需要严格的方法，因为:

错误本质上是累积的-您尝试快速解决问题的次数越多，通常会导致更多问题。很快您将无法维护，因为问题通常是“在野外”(已发布)，并且必须像交付过程一样进行处理-每个迭代都有其自身的附加风险，而不仅仅是一个单一的问题。调试，直到修复为止。

当您无法无法访问有问题的系统时，调试极其困难。日志可以在正确完成时提供帮助，但是当您需要调试时日志通常不会提供给您，或者日志格式或冗长不正确，或者只是毫无用处，因为自定义操作通常不能正确记录日志。

目标系统(和目标环境)在几乎所有可以想象的方面都存在差异(即使是大多数公司使用标准OS安装和程序包的标准操作环境(SOE)，情况也是如此):硬件和驱动程序的差异(大型和小型)，胖客户端/瘦客户端，终端服务器，操作系统平台(x86 / x64 / etc ...)，操作系统版本(Win7，Win10，WinXP等)，操作系统版本(最终版，家庭版，等等)，操作系统语言版本，操作系统升级状态和补丁程序级别，恶意软件状况，磁盘空间问题，分区方案，文件系统类型，加密问题(文件系统，网络)，用户权限设置，UAC配置，系统特权配置(NTRights)，连接类型，连接速度，网络配置(域，工作组等)，子网划分，代理设置，电子邮件系统和配置(Exchange，Outlook，Novell等)， Activity 目录，身份验证方案，网络共享和驱动器，应用程序空间，脚本可用性，脚本锁定，各种运行时版本(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? 。这是一个安装程序需要执行哪些任务的摘要，并附有各种技术细节。可能添加了太多细节，可能破坏了答案的“概述质量”。但是，其目的是与开发人员保持联系。

相关的MSI工具

Visual Studio MSI项目文件是创建MSI文件(作为Visual Studio的一部分)的一种轻量级方法，它的功能集受到极大限制。有人在讨论将Visual Studio中的MSI项目类型替换为WiX XML项目，这通常是人们现在构建其MSI文件的方式。不要使用此项目类型。由于缺乏灵活性和严重的错误，它给许多用户带来了严重的问题。

Orca是 Windows SDK的工具，它允许打开，编辑二进制MSI文件，并在一定程度上进行比较。实际上，它主要是由后来创建WiX工具包的人编写的。 Rob Mensching ，当时他在Microsoft 的 Windows Installer团队中工作。该工具还允许其他操作，例如生成用于修改MSI文件的转换文件和其他一些技术操作。尽管这是一个非常基本的工具，缺少商用工具中最先进的功能，但它仍然是应用程序打包程序的最爱，可以使用，并且由于其可靠性，简单和清洁度“-保存时不会向MSI添加“默认垃圾”(第三方工具会添加自定义表格和类似的垃圾)。我将其用于小型MSI更新，调试，inspection of the summary stream，基本转换的创建，查看修补程序，包验证以及其他重要操作。

实际上，我猜它是一个具有简单界面的高级工具-根本不是一个基本工具:-)。为了掌握Orca，您需要安装Windows SDK(!)。当工具的大小很小时，确实有点超出顶部，但是至少很容易知道它在哪里可用，而不是寻找单独的下载。

更新:如果已安装Visual Studio和SDK，则搜索Orca-x86_en-us.msi并安装它。如果您不这样做，也许有安装Visual Studio的 friend 搜索它，然后将其发送给您？这是一个小文件。

还有一些可供选择的免费工具，如此处所述(朝下):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工具，与wit相比，您可以在 What installation product to use? InstallShield, WiX, Wise, Advanced Installer, etc (与上述链接相同)中找到其中一些。