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

Question

背景

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

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

事先知识

我是一个很好的InnoSetup，但我刚刚开始使用Windows Installer技术进行read into。

题

据我所知，对于任何多步骤/“复杂”设置要求，包括先决条件和东西，只使用一个裸MSI文件是不行的。 （正如所有不同的boostrappers的存在所证明，包括与WiX捆绑的那个，Burn）

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

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

是否所有（通常可见的）UI都驻留在引导程序中，或者您是否将其中的一部分放入MSI文件中？

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

---

基本上，应用程序（套件）需要支持点击式平均用户场景，其中设置处理所有内容，并且企业客户端需要能够分成MSI文件，这些文件仅包含我们的东西减去依赖性，如.NET运行时， SQL Server，......将由客户的企业IT处理，我们的软件MSI将由客户IT自动部署。

那么，所有胶水和依赖脚本都应该进入引导程序并且只使用非常简单的MSI文件吗？或者某些“逻辑”应该进入（某些）MSI文件？

Answer 1

简短回答：

当存在多个MSI文件时，由Burn引导程序处理UI是正常的，因为您确实希望看到组合进度，而不是所有单独的MSI UI。如果您真的将多个MSI打包为产品​​，则还应该在一个MSI发生故障的情况下设置多个MSI的适当回滚，因此如果一个MSI失败则需要退出。

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

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

Answer 2

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

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

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