windows - 可以在其他安装程序中使用基于 WiX 的 Windows 安装程序吗？

Question

使用 WiX bootstrap 构建的设置通常能够在其他安装程序中运行吗？

我想创建一组可分发的文件，其中包含 api dll、安装 API 使用的服务的安装程序以及任何先决条件文件(VC++、.NET 框架等)。此设置将由 Wix bootstrap 构建到 .exe 文件中。然后，最终客户可以将我们的 .exe 安装程序放入他们的安装程序中并静默运行以安装运行我们的 API 所需的一切。

Answer 1

简答:您的 setup.exe可以由其他人安装 setup.exe只要不踢几个MSI文件同时安装，其他setup.exe还可以按顺序运行，而不会同时产生多个 MSI 安装。技术说明如下。

基本上，您可以将您的设置作为 setup.exe 提供, MSI或作为 a merge module或以上所有。

更新 : 我想看看你是否熟悉 WiX 包含文件？

安装执行序列互斥锁 :由于非常基本的技术原因，两个 MSI 文件无法同时运行其实际安装操作(实际更改系统的操作)(当 InstallExecuteSequence 在 InstallInitialize 和 InstallFinalize 之间运行时设置 mutex)。

多个 MSI GUI:这个问题我已经写过很多次了，但我认为最直接的解释是this one from serverfault .本质上，系统被锁定以确保在安装过程中发生错误时可以回滚所有更改。应该注意的是，您可以一次启动多个 MSI 文件并访问它们的 GUI 序列(换句话说，显示准备实际安装的设置对话框)，但您一次只能启动一个进行实际系统更改 - 在技术上术语意味着运行 InstallExecuteSequence .

已排序的 MSI 文件 : MSI 文件可以“一个接一个”运行而不会出现问题，只要它们都设计得很好。 WiX bootstrap Burn 专门为此目的而制作(以及其他一些免费用途:下载程序、 bootstrap 、音序器、允许外部、自定义设置 GUI 等...)。

潜在途径 : 似乎您的设置将包含在其他软件套件的安装中？这里有几个选项。

按顺序运行 :如果其他软件供应商同意这一点，他们可以包括您的 setup.exe并让它运行完成，然后再继续他们自己的设置。这意味着他们从自己的 setup.exe 中这样做使用 WiX (Burn) 或等效工具创建 setup.exe使用 Advanced Installer、Installshield 或其他商业工具(甚至只是 dotnetInstaller - 这是一个免费的 bootstrap )生成。

Merge Module ( a Symantec article ): 或者，您可以根据自己的设置制作“合并模块”——这是一个可消耗的二进制“捆绑包”，可以在编译/构建时合并到任何 MSI 设置中。它是一个小的数据库片段，如果您愿意，也可以是部分数据库。它将包含以适当方式安装的所有组件。本质上，合并模块是您的设置作为可消耗的整个组件交付，成为其他设置的实际部分 - 无需作为单独的先决条件安装。换句话说，它是交付运行时的另一种方式，无需交付单独的设置。这就是 MSI 最初打算用于部署先决条件的方式，并且基本上仍然如此 - 尽管现在存在诸如 Burn 之类的替代方案。

制作合并模块:Advanced Installer ( merge modules general info ), WiX (也许检查 IsWiX's installer source , 它使用合并模块), Installshield (merge module projects) .

MSI 文件 :坦率地说，我最喜欢的方法是不用担心执行大量先决条件安装的 setup.exe 启动程序，而是提供符合标准的 MSI 文件，您的客户可以在他们自己的安装之前按顺序运行。如果未安装适当的运行时，您的 MSI 可以设置启动条件以拒绝安装。通过这种方式，如果发现错误，您的 MSI 可以“自我更新”，理论上它可以单独分发 - 无需重新编译捆绑合并模块的所有设置 - 到任何安装了第一个版本软件的计算机。我喜欢这种解耦。

真实世界故事 : 很多人喜欢合并模块。我不得不承认我不是一个 super 粉丝，但如果做得对，它们工作得很好。有时我不得不处理合并模块，这些模块因其令人难以置信的内置设计缺陷而破坏了完美的设置(我想起了当时的 SOAP 合并模块 - 它极大地 - 并且单枪匹马地 - 引发了我的设置错误率，必须删除)。不是合并模块本身作为技术的问题，而是不止一次导致问题的实际问题。

这个故事的寓意是:不要提供一个糟糕的合并模块，其中包含许多失败的自定义操作和奇怪的要求，这些要求会因不必要的脆弱性和内容而使“父设置”膨胀。如果您交付了一个“最低限度”完成其任务的符合标准的合并模块 - 那么这是部署运行时的好方法，甚至是某些供应商的首选。

核心操作系统运行时 :我建议不要将 .NET 框架与您的设置捆绑在一起 - 特别是如果它是供企业使用的。 Dot NET 现在几乎可以通过操作系统本身始终可用，并且设置中包含的运行时将很快只是过时的臃肿和“胖”，企业应用程序打包人员将花费大量时间从您的包中摆脱它们。 Dot NET 更新最好通过 Windows Update(或等效的公司部署机制)分发。

相反，拥有 one-page (PDF) document explaining (see a bit down the page) 似乎是一种正常的方法。您的应用程序需要哪些先决条件才能正常运行。当然，对于合并模块组件，您会记录这一点，因为您不能在自己的合并模块中包含核心运行时 - 通常您只能安装自己的文件。

部分链接(仅供引用) :

Can Windows installer install two msi files at the same time?

Why Windows Installer can only install a single program at a time?

Other installation In Progress Hanging my Wix Install

Wix Custom Action Sequence

Prerequisites button disabled - MSI installer

How to make an installer that automatically install all the prerequisite programs for the application

Wix - How to run/install application without UI