使用WiX引导程序构建的设置是否通常能够在其他安装程序中运行？
我想创建一个可分发的文件集，其中包含api dll，安装程序以安装API使用的服务以及所有必备文件（VC ++ 、. NET框架等）。此安装程序将由Wix引导程序构建为.exe文件。最终客户可以将我们的.exe设置放到安装程序中，然后以静默方式运行它，以安装运行我们的API所需的一切。
答案 0 :(得分：1)
简短答案： ：setup.exe可以由另一个setup.exe安装，只要它不会踢出几个要安装的MSI文件同时，另一个setup.exe也会按顺序运行，而不会一次产生多个MSI安装。下面是技术说明。
基本上，您可以以setup.exe，MSI或a merge module或以上所有形式提供设置。
更新 ：我想检查一下您是否熟悉WiX包含文件？
InstallExecuteSequence Mutex ：由于非常基本的技术原因，两个MSI文件不能同时运行其实际的安装操作（实际上更改系统的操作）（{当InstallExecuteSequence在InstallInitialize和InstallFinalize之间运行时设置3}}。
多个MSI GUI： 我已经多次写过关于此问题的文章，但我认为最直接的解释是mutex。本质上，系统已锁定，以确保如果在安装过程中发生错误，所有更改都可以回滚。应该注意的是，您可以一次启动多个MSI文件并进入它们的GUI序列（换句话说，显示用于实际安装的设置对话框），但是一次只能进行一次实际的系统更改-在技术方面表示运行InstallExecuteSequence的术语。
顺序排列的MSI文件 ：只要设计合理，MSI文件就可以“一个接一个”运行，而不会出现问题。 WiX引导程序刻录专门用于此目的（以及其他一些附加目的：下载器，引导程序，定序器，允许外部，自定义安装GUI等）。
潜在方法 ：看来您的设置将包含在其他软件套件的安装中？这里有几个选项。
按顺序运行 ：如果其他软件供应商对此表示满意，他们可以将setup.exe包含在其中，并使其运行到完成后再继续自己的设置。这意味着他们将使用WiX（Burn）创建的setup.exe或使用Advanced Installer，Installshield或其他商业工具（甚至是dotnetInstaller-甚至是免费的引导程序）生成的等效setup.exe来执行此操作）。
this one from serverfault （Merge Module）：您也可以通过自己的设置制作“合并模块”-易用的二进制“捆绑包”，可以在编译/构建时将其合并到任何MSI设置中。它是一个小的数据库片段，或者如果您愿意的话，可以是部分数据库。它将包含所有设置为以适当方式安装的组件。本质上，合并模块是将您的设置作为消耗性的整个组件交付的组件，它成为其他设置的实际组成部分-无需作为单独的必备设置进行安装。换句话说，这是交付运行时的另一种方式，而无需交付单独的设置。这是MSI最初打算用于部署先决条件的方式，并且基本上仍然是-尽管现在存在诸如Burn的替代方案。
真实故事 ：许多人喜欢合并模块。我必须承认我不是一个忠实的粉丝，但是如果做得对，他们的表现会很好。有时我不得不处理合并模块，这些合并模块因其令人难以置信的内置设计缺陷而破坏了完美的设置（从今天开始，SOAP合并模块就浮现在脑海中-彻底地-单枪匹马-引发了我的设置错误率，必须将其删除）。合并模块本身并不是一项技术问题，而是不止一次引起问题的实际问题。
故事的寓意：不要提供一个糟糕的合并模块，其中包含许多自定义操作，这些自定义操作会失败并产生奇怪的要求，这些要求会以不必要的脆弱和内容使“父级设置”膨胀。如果您提供的标准合并模块“最小”地执行其任务-那么这是部署运行时的一种好方法，甚至是某些供应商所喜欢的。
核心操作系统运行时 ：我建议不要将.NET框架与您的设置捆绑在一起-尤其是用于企业用途时。现在，Dot NET几乎可以通过OS本身随时使用，并且安装程序中包含的运行时将很快变得过时并且“发胖”，企业应用程序包装商将花费大量时间摆脱您的软件包。最好通过Windows Update（或等效的公司部署机制）分发点NET更新。
相反，似乎(merge module projects)是应用程序正常运行所必需的先决条件。当然，对于合并模块组件，您将对此进行记录，因为您不能在自己的合并模块中包含核心运行时-通常，您只能安装自己的文件。
某些链接（仅供参考） ：