9

当产品 A 和 B 分别安装多个 MSI 并且某些 MSI 相同时，卸载 A 或 B 会影响另一个吗？安装位置重要吗？

另外，如果产品 B 中常见的 MSI C 的版本较高，安装时 B 升级 C，会发生什么情况？现在卸载 B 将删除破坏产品 A 的常见 MSI C。如何在不使用永久标志的情况下优雅地处理这个问题？

4

3 回答 3

14

这个问题首先想到的是所讨论的产品是否按应有的方式分解。

作为一般规则，所有 MSI 文件都认为他们拥有他们安装的任何内容，如果引用计数（使用该组件的产品数量）为零，他们将在卸载时卸载附加到 MSI 内的组件 GUID 的所有内容。

这条规则有一些条件：

  • 如果组件被标记为永久 ，则永远不会卸载
  • 如果文件/注册表项根本没有组件 GUID，它会被安装，不会被 Windows Installer 跟踪，也不会被卸载
  • 最后，MSI 的引用计数允许在多个产品之间共享相同的组件，如果它被其他几个安装程序包注册使用，它将在卸载期间保留在磁盘上

在 MSI 包之间创建共享组件的机制通常是：

  1. 合并模块允许您安装引用计数的共享组件，如果系统上有其他客户端使用 GUID，则在卸载相关产品后将保留在磁盘上。合并模块在编译时合并到其他 MSI 包中。如果你愿意，一种二进制早期绑定的形式。它可以合并到任何包中。
  2. 随着Wix（基于 xml 的安装程序源文件）的出现，可以通过XML 源包含文件而不是合并模块从多个设置中包含相同的文件段。在我看来，这是非常优越的，因为 Wix 更适合源代码控制（请参阅 Wix 链接以获取解释）。认识到“ Wix 源包含文件”这一点至关重要" 与合并模块具有完全相同的效果 - 它的组件被正确地引用计数以在不同的安装程序包之间共享，前提是源文件中的 GUID 是硬编码的（我建议不要将自动生成的 guid 用于此特定目的）。我个人认为你应该为通用运行时文件使用第三方合并模块，但只有Wix 包含你自己的共享文件。合并模块比 Wix 包含 imho 更难管理。

更新和文件替换：

  • 至于更新方案，MSI 文件替换规则将负责更新较新的文件，具体取决于特殊 Windows Installer 属性REINSTALLMODE中的整体设置。
  • 通常，较高版本的文件会覆盖较低版本的文件。未修改的非版本文件将被覆盖。如果它们被修改，则创建和修改的日期戳是不同的，并且文件将被单独保留。
  • 请记住，整体 MSI 设计不鼓励降级文件的问题。如果您需要降级文件（共享或不共享），那么您的设计就会有一些部署问题。

在这一点上，我会彻底阅读这些答案：

如果您使用 Wix，或者您愿意使用 Wix，我认为处理重叠产品的最佳方法是将您的安装程序分解为您根据需要包含在主要安装程序中的Wix 段源文件。这将允许卸载一个产品以保留其他应用程序使用的任何组件。

话虽如此，我不喜欢在我的安装程序中造成太多重叠的依赖项，原因在本文中列出（也在上面列出）：Wix to Install multiple Applications。

为了稳定性，共享组件在被太多设置用作错误修复之前保持稳定至关重要，因为一般规则将需要重新编译共享组件被编译或合并到的所有设置。简单的说法：将一起更改的文件捆绑在一起。

为了抵消这种对大量重新编译的需求，您可以选择提供由一些共享组件组成的独立支持设置。一个或几个可能包含 Wix的此类“共享组件设置”包括以类似的缓慢发布时间表一起更改，然后每个产品的单独设置应该能够在保持平衡的同时满足任何部署需求在可维护性和灵活性之间。

产品设置应该是经常重新编译的产品设置，并且共享模块设置应该设计为最小化重新编译。然后等待不断变化的需求:-)。

对我来说，这完全是关于内聚和耦合，以及平衡销售、营销和技术需求的困难。

于 2014-08-10T11:24:22.960 回答
4

如果产品 A 和产品 B 有一个共同的 MSI C，那么如果安装了产品 A，也安装了 MSI C，现在安装产品 B 时将不会安装 MSI C，因为它已经在系统中可用（如果产品 B 是 WiX基于 Burn，它注册了一个依赖项）。如果产品 A 和产品 B 是基于 WiX Burn 的安装程序或任何其他支持引用计数的引导程序，则会自动处理卸载引用计数，否则 MSI C 将与产品 B 一起删除。

于 2014-07-19T07:12:12.533 回答
1

即使我一直在寻找上述问题的答案，但在 Wix v3.7 及更高版本中，MSI 包由 Burn 引擎自动引用计数。我已经对此进行了测试，并且效果很好。可以在Rob 的博客中查看相同的内容

于 2015-07-02T06:35:01.447 回答