产品A和B各安装多个msi，其中一些msi是相同的，卸载A或B中的一个会影响另一个吗?安装位置重要吗?
另外，如果产品B中常见的MSI C版本较高，而B在安装时升级了C，会发生什么?现在卸载B将删除破坏产品a的常见MSI C。您如何在不使用永久标志的情况下优雅地处理此问题?
对于这个问题，首先想到的是所讨论的产品是否按照它们应该的方式进行了分解。
作为一般规则所有MSI文件都认为它们拥有它们安装的任何东西，并且如果参考计数(使用该组件的产品数量)为零，它们将在卸载时卸载MSI中附加到组件GUID的所有内容。
这个规则有一些限定条件:
- 如果组件被标记为permanent它永远不会卸载
- 如果文件/注册表项有没有组件GUID它被安装了，从未被Windows安装程序跟踪，也不会被卸载 最后MSI的引用计数允许在几个产品之间共享相同的组件，如果它被几个其他安装程序包注册使用，它将在卸载期间保留在磁盘上
创建共享组件的机制MSI包之间一般为:
- 合并模块允许您安装引用计数的共享组件，并且在卸载相关产品后，如果系统上有其他客户端使用GUID，这些组件将保留在磁盘上。合并模块在编译时被合并到其他MSI包中。二进制早期绑定的一种形式如果你愿意的话。它可以被合并到任何包中。
- 随着Wix的出现(基于xml的安装程序源文件)，可以通过xml源文件包含来自多个设置的相同文件段。而不是合并模块。在我看来，这是非常优越的，因为Wix在源代码控制方面工作得更好(请参阅Wix链接以获得解释)。至关重要实现一个">Wix源代码包含文件"具有与合并模块完全相同的效果-如果源文件中的guid是硬编码的，则其组件被正确地引用计数，以便在不同的安装程序包之间共享(我建议不要使用自动生成的guid用于此特定目的)。这是我个人的意见，你应该使用第三方合并模块的通用运行时文件，但只有Wix包含用于您自己的共享文件。合并模块比Wix包含更难管理。
更新和文件替换:
- 对于更新场景，MSI文件替换规则将负责更新新文件，这取决于特殊Windows安装程序属性REINSTALLMODE中的总体设置。
- 一般来说，高版本文件覆盖低版本文件。未修改的非版本文件将被覆盖。如果它们被修改，则创建和修改的日期戳是不同的，并且文件保持不变。 请记住降级文件的问题总体MSI设计是不鼓励的。如果您需要降级文件(共享或非共享)，那么中存在一些部署问题关于你的设计。
在这一点上，我将仔细阅读这些答案:
- Windows安装程序和WiX的创建-用于简短的WiX历史和上下文 在wix中更改我的组件GUID ?-用于组件引用计数
- Wix安装，服务器，客户端或两者-用于客户端/服务器打包
- Wix安装多个应用程序-用于更改需求和设置问题
- WiX技巧和技巧-社区WiX技巧和技巧
- 如何包含wxi文件到wxs?-关于如何处理Wix包含文件 的简单想法
如果您使用Wix，或者您愿意使用Wix，我认为处理重叠产品的最佳方法是将您的安装程序分解为Wix段源文件根据需要包含在主安装程序中。这将允许卸载一个产品，而保留其他应用程序使用的任何组件。
话虽如此，我不喜欢在我的安装程序中造成太多重叠的依赖项。由于本文中列出的原因(上面也列出了):允许安装多个应用程序．
共享组件至关重要在被太多设置使用之前是稳定的一般来说，修复bug需要重新编译编译或合并到共享组件中的所有设置。简单的说法是:将一起更改的文件捆绑在一起.
为了消除这种大规模重新编译的需要，您可以选择交付由一些共享组件组成的独立支持设置。一个或几个这样的">共享组件设置"，可能包含Wix包含的更改在一个类似的，缓慢的发布时间表，然后为每个产品单独设置应该能够考虑任何部署需求，同时在可维护性和灵活性之间保持平衡.
产品设置应该经常被重新编译，共享模块设置应该被设计成最小的重新编译。然后等待需求的变化:-)。
对我来说，这都是关于凝聚力和，以及平衡销售、市场和技术需求的困难。
如果产品A和产品B有一个共同的MSI C，则如果安装了产品A，也安装了MSI C，现在当安装产品B时，MSI C将不会安装，因为它已经在系统中可用(如果产品B是基于WiX Burn的，它会注册一个依赖项)。如果产品A和产品B是基于WiX Burn的安装程序或任何其他支持引用计数的引导程序，则在卸载时自动处理引用计数，否则MSI C将与产品B一起删除。
即使我正在寻找上述问题的答案，但在Wix v3.7和更高版本中，MSI包由Burn引擎自动引用计数。我已经测试过了，效果很好。同样可以在Rob的博客
查看。