26

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

4

2 回答 2

59

我只想添加一些关于 Windows Installer 技术本身的更具体的技术信息，以及一些导致创建 WiX 工具包的历史，因为刚进入安装程序领域的人可能会发现这篇文章，WiX和 Windows 安装程序。

这旨在从开发人员的角度快速介绍WiX和MSI。还有一篇颇受欢迎的 serverfault.com 文章可能有助于了解 Windows Installer 的优势：使用 MSI 文件的企业优势（许多开发人员不喜欢 Windows Installer，但企业部署优势实际上非常显着 - 或许值得快速浏览一下，如果您认为 MSI 麻烦多于其价值）。

WiX 工具包的由来

MSI 文件本质上是剥离了存储为COM结构存储文件的 SQL Server 数据库。这是 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)，因为大多数公司使用标准化的操作系统安装和软件包）：硬件和驱动程序差异（大和small), fat client/thin client, terminal server, OS platform (x86/x64/etc...), OS version (Win7, Win10, WinXP, etc...), OS edition (ultimate, home, etc..) .)、操作系统语言版本、操作系统升级状态和补丁级别、恶意软件情况、磁盘空间问题、分区方案、文件系统类型、加密问题（文件系统、网络）、用户权限设置、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 等...）。它会一直持续下去。

部署是一个简单的概念，具有复杂的变量组合，可能会导致最神秘的错误 - 包括开发人员最喜欢的：间歇性错误。众所周知，此类错误的严重性不能被夸大，因为它们通常无法正确调试。

更多关于部署以及现代安装程序可能需要做什么：程序安装的好处和真正目的是什么？. 这是一个设置可能需要执行哪些任务的摘要，其中包含各种技术细节。可能添加了太多细节，可能会破坏答案的“概述质量”。然而，目的是与开发人员保持相关性。

相关微星工具

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 工具，其中一些与 WiX 相比，您可以在What install product to use？InstallShield、WiX、Wise、Advanced Installer 等（与上述相同的链接）。

于 2012-08-23T23:52:29.557 回答
18

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

Visual Studio 只是 WiX 的替代品，只是另一种设置创作工具。我不推荐它，因为它非常有限。它仅提供基本功能。

如果您对 WiX 感到满意，请继续使用它。

于 2011-05-19T14:46:16.637 回答