MSI参考计数:两个产品安装相同的MSI

Question

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

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

Answer 1

这个问题首先想到的是有问题的产品是否按照应有的方式进行分解.

作为一般规则,所有MSI文件都认为它们拥有它们安装的任何内容,并且如果引用计数(使用该组件的产品数量)为零,它们将在卸载时卸载附加到MSI内部组件GUID的所有内容.

这条规则有一些资格:

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

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

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

更新和文件替换:

• 至于更新方案,MSI文件替换规则将负责更新较新的文件,具体取决于特殊Windows Installer属性REINSTALLMODE中的整体设置.
• 通常,较高版本的文件会覆盖较低版本的文件.如果未修改,则会覆盖非版本化文件.如果修改它们,则创建和修改的日期戳将不同,文件将保持不变.
• 请记住,整体MSI设计会主动阻止降级文件的问题.如果您需要降级文件(共享或不共享),那么您的设计会出现部署内容.

在这一点上,我会彻底阅读这些答案:

• Windows Installer和WiX的创建 - 用于简短的Wix历史和上下文
• 在wix中更改我的组件GUID？ - 用于组件引用计数
• Wix安装,服务器,客户端或两者 - 用于客户端/服务器打包
• Wix安装多个应用程序 - 用于更改要求和设置问题
• WiX技巧和提示 - 适用于社区Wix提示和技巧
• 如何将wxi文件包含到wxs中？ - 简单了解如何处理Wix包含文件

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

话虽如此,我不喜欢在我的安装程序中导致过多的重叠依赖项,原因是本文中列出的原因(也在上面列出):Wix安装多个应用程序.

为了稳定性,共享组件在被太多设置用作错误修复之前是稳定的至关重要,因为一般规则将需要重新编译共享组件被编译或合并到的所有设置.说出来的简单方法:将文件捆绑在一起进行更改.

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

然后,产品设置应该是经常重新编译的设置,共享模块设置应该设计为最少的重新编译.然后等待改变要求:-).

对我而言,这完全是关于凝聚力和耦合,以及平衡销售,营销和技术需求的难度.