当产品A和B各自安装多个MSI并且某些MSI相同时,卸载A或B会影响另一个吗?安装位置是否重要?
此外,当产品B中的常见MSI C版本较高且安装时B升级C时会发生什么?现在卸载B将删除打破产品A的常见MSI C.如何在不使用永久标志的情况下优雅地处理此问题?
答案 0 :(得分:13)
这个问题首先想到的是有问题的产品是否按照应有的方式进行分解。
作为一般规则,所有MSI文件都认为它们拥有自己安装的任何内容,并且如果引用计数(使用该组件的产品数量),它们将卸载在卸载时MSI内部组件GUID附加的所有内容)是零。
此规则有一些资格:
MSI包之间的创建共享组件的机制通常是:
更新和替换文件:
此时我会彻底阅读这些答案:
如果您使用Wix,或者您愿意使用Wix,我认为处理重叠产品的最佳方法是将您的安装程序分解为您包含的 Wix段源文件您的主要安装人员需要。这将允许卸载一个产品以留下其他应用程序使用的任何组件。
由于这一点,我不希望在我的安装程序中导致过多的重叠依赖项,原因是本文中列出的原因(也在上面列出): Wix to Install multiple Applications < / strong>。
对于稳定性,共享组件在被太多设置使用之前稳定作为一般规则的错误修复至关重要将需要重新编译共享组件编译或合并到的所有设置。 说出来的简单方法:将文件捆绑在一起。
为了抵消大量重新编译的需要,您可以选择提供由一些共享组件组成的独立支持设置。一个或几个此类&#34; 共享组件设置&#34;可能包含Wix的内容包括在类似的缓慢发布计划上一起更改,然后每个产品的单独设置应该能够在维护时考虑任何部署需求可维护性和灵活性之间的平衡。
然后,产品设置应该是经常重新编译的设置,共享模块设置应该设计为最少的重新编译。然后等待改变要求: - )。
对我来说,这完全是关于凝聚力和耦合,以及平衡销售,营销和技术需求的难度。
答案 1 :(得分:4)
如果产品A和产品B具有共同的MSI C. 如果安装了产品A,则安装MSI C,现在安装产品B时,MSI C将不会安装,因为它已经在系统中可用(如果产品B是基于WiX Burn,它会注册依赖项)。如果卸载,如果产品A和产品B是基于WiX Burn的安装程序或任何其他支持引用计数的Bootstrapper,则会自动处理引用计数,否则MSI C将与产品B一起删除。
答案 2 :(得分:1)
即使我在寻找上述问题的答案,但在Wix v3.7及更高版本中,MSI软件包会被Burn引擎自动引用计数。我测试了这个,并且完美无缺。 可以在Rob's blog
中查看相同的内容