使用 WiX bootstrap 构建的设置通常能够在其他安装程序中运行吗？
我想创建一组可分发的文件，其中包含 api dll、安装 API 使用的服务的安装程序以及任何先决条件文件(VC++、.NET 框架等)。此设置将由 Wix bootstrap 构建到 .exe 文件中。然后，最终客户可以将我们的 .exe 安装程序放入他们的安装程序中并静默运行以安装运行我们的 API 所需的一切。
最佳答案
简答:您的 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 )生成。 真实世界故事 : 很多人喜欢合并模块。我不得不承认我不是一个 super 粉丝，但如果做得对，它们工作得很好。有时我不得不处理合并模块，这些模块因其令人难以置信的内置设计缺陷而破坏了完美的设置(我想起了当时的 SOAP 合并模块 - 它极大地 - 并且单枪匹马地 - 引发了我的设置错误率，必须删除)。不是合并模块本身作为技术的问题，而是不止一次导致问题的实际问题。
这个故事的寓意是:不要提供一个糟糕的合并模块，其中包含许多失败的自定义操作和奇怪的要求，这些要求会因不必要的脆弱性和内容而使“父设置”膨胀。如果您交付了一个“最低限度”完成其任务的符合标准的合并模块 - 那么这是部署运行时的好方法，甚至是某些供应商的首选。
核心操作系统运行时 :我建议不要将 .NET 框架与您的设置捆绑在一起 - 特别是如果它是供企业使用的。 Dot NET 现在几乎可以通过操作系统本身始终可用，并且设置中包含的运行时将很快只是过时的臃肿和“胖”，企业应用程序打包人员将花费大量时间从您的包中摆脱它们。 Dot NET 更新最好通过 Windows Update(或等效的公司部署机制)分发。
相反，拥有 one-page (PDF) document explaining (see a bit down the page) 似乎是一种正常的方法。您的应用程序需要哪些先决条件才能正常运行。当然，对于合并模块组件，您会记录这一点，因为您不能在自己的合并模块中包含核心运行时 - 通常您只能安装自己的文件。
部分链接(仅供引用) :
关于windows - 可以在其他安装程序中使用基于 WiX 的 Windows 安装程序吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/51272206/