将什么直接放入 Windows Installer MSI 与包装器/引导程序？

Question

背景

我目前正在将现有的非 MSI 设置迁移到基于 Windows Installer 的解决方案。当前的解决方案是用InnoSetup 编写的，我非常喜欢它，但是，客户 IT 部门开始需要 MSI，并且在他们这样做的地方，通常情况下，我们包含的许多/一些先决条件和脚本他们的自动化任务不需要我们的 setup.exe（但是，有些是）。

因此，似乎纯 MSI 包装器在这里没有太大意义，所以我正在查看（多个？）MSI 文件和 boostrapper。

先验知识

我是一个很好的 InnoSetup，但我才刚刚开始readinto Windows Installer 技术。

问题

据我所知，对于任何多步骤/“复杂”的设置要求，包括先决条件和其他内容，仅使用裸 MSI 文件是行不通的。 （正如所有不同的助推器的存在所证明的那样，包括与 WiX 捆绑的那个，Burn）

因此，我需要将我们现有的整体设置拆分为几个步骤，其中一些（主要是安装 我们的 文件的那些）捆绑到 MSI 数据库中，而一些步骤只是“脚本化”在引导程序。

这里是我真正可以使用一些关于安装包的先前经验的地方：（链接的）安装的哪些部分进入 MSI 包，哪些部分进入引导程序？

所有（通常可见的）用户界面都应该驻留在引导程序中，还是应该将其中的一部分放入 MSI 文件中？

每个 MSI 文件最终应该有多“愚蠢”？也就是说，如果无论如何使用引导程序和多个 MSI 文件，任何单个 MSI 文件是否应该包含任何可选部分，或者是否应该将所有选项分解为单独的 MSI 文件（仅检查它们各自的先决条件是否存在，但不包含安装它们的逻辑）？

---

基本上，应用程序（套件）需要支持点击通过的普通用户场景，其中设置处理一切，对于企业客户，需要能够拆分为仅包含的 MSI 文件我们的东西减去 .NET 运行时、SQL Server 等依赖项......将由客户的公司 IT 处理，我们的软件 MSI 将由客户 IT 自动部署。

那么，所有胶水和依赖脚本是否应该进入引导程序并且只使用非常简单的 MSI 文件？还是应该在（某些）MSI 文件中加入一些“逻辑”？

Answer 1

简短的回答：

当有多个 MSI 文件时，UI 由 Burn 引导程序处理是正常的，因为您确实希望查看组合进度，而不是所有单独的 MSI UI。如果您确实将多个 MSI 打包为一个产品，您还应该为多个 MSI 设置适当的回滚，以防一个 MSI 失败，因此如果一个 MSI 失败，它们都需要退出。

引导程序包含确定需要安装什么的检测逻辑，并且可以安装 SQL、NET 等先决条件，但不得以其他方式更改系统。

MSI 文件包含适合正在安装的文件的所有文件、服务安装、COM 注册等。您使用的任何更改系统的自定义操作代码都必须在执行序列中，被延迟，并且具有相应的回滚 CA 以撤消它所做的任何事情。 MSI 应该能够独立运行以安装其内容——我发现这是一个有用的指南。 MSI 文件将在没有其 UI 的情况下安装，因此请确保可以在命令行上使用作为属性值传递的参数（包括安装位置）静默安装它们。

Answer 2

很难简短地回答这个问题。请务必使用 Burn 或类似的引导程序，并将运行时及其自己的部署解决方案作为单独的文件来运行 - 默认情况下以静默模式运行。

• 对于家庭用户，您应该安装所有东西，不要问太多问题以避免混淆。
• 对于企业部署，您应该只部署所需的内容，并明确每个包含的部署文件的用途：
  • 编写一个单页 PDF，其中包含部署说明，描述每个文件的作用以及与它相关的运行时。将其称为“DEPLOYMENT README.TXT”或类似名称。这是让您的应用程序获准进行企业部署的最佳方式。对此进行分析可能会令人厌烦。
  • 企业环境中的应用程序打包人员将分析先决条件并确定您的应用程序是否能很好地与他们的标准框架包一起工作。这些标准包将被设置为分发系统中的先决条件。
  • 特别记录需要什么 .NET 框架版本以及其他运行时要求的详细信息。
  • 不要自动安装 Windows 修补程序、msiexec 引擎更新 或 .NET 框架运行时。在您的文本文件中将它们记录为先决条件。这些运行时在企业环境中受到严格控制，并由定制的企业包进行部署。
  • 您可以在 MSI 中包含简单运行时的合并模块，企业环境中的应用程序打包团队可以轻松删除它们。

这个答案并没有变得非常好，但我没时间了。也许也检查一下这个答案： MSI Reference Counting: Two products install the same MSIs