MSI 引用计数:两个产品安装相同的 MSI [英] MSI Reference Counting: Two products install the same MSIs

问题描述

当产品 A 和 B 都安装了多个 MSI 并且其中一些 MSI 相同时，卸载 A 或 B 是否会影响另一个?安装位置重要吗?

When products A and B each install several MSIs and some of the MSIs are the same, will uninstalling either A or B affect the other? Does install location matter?

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

Also, what happens when common MSI C's version is higher in Product B and B upgrades C on install? Now uninstalling B will remove the common MSI C which breaks Product A. How do you handle this gracefully without using the Permanent flag?

推荐答案

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

The first thing that comes to mind with this question is whether the products in question are decomposed the way they should be.

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

As a general rule all MSI files think they own whatever they install, and they will uninstall everything attached to a component GUID inside the MSI on uninstall if the reference count (number of products using the component) is zero.

此规则有一些限制:

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

• If the component is marked permanent it is never uninstalled
• If the file / registry item has no component GUID at all, it is installed, never tracked by Windows Installer, and won't get uninstalled either
• Finally the reference counting for MSI allows the same component to be shared between several products and it will persist on disk during uninstall if it is registered in use by several other installer packages

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

The mechanisms for creating shared components between MSI packages are generally:

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

1. Merge modules allow you to install shared components that are reference counted and that will remain on disk after uninstall of a related product if there are other clients using the GUID on the system. A merge module is merged into other MSI packages at compile time. A form of binary early binding if you like. It can be merged into any package.
2. With the advent of Wix (xml based installer source files), it is possible to include the same segment of files from several setups via an XML source include file instead of a merge module. This is vastly superior in my opinion due to the fact that Wix works better for source control (see Wix link for explanation). It is crucially important to realize that a "Wix source include file" has the exact same effect as a merge module - its components are reference counted properly for sharing between different installer packages, provided the GUIDs in the source file are hard coded (I recommend not to use auto-generated guids for this particular purpose). It is my personal opinion that you should use third party merge modules for generic runtime files, but only Wix includes for your own shared files. Merge modules are harder to manage than Wix includes imho.

更新和文件替换:

• 至于更新方案 MSI 文件替换规则 将负责更新较新的文件，具体取决于 Windows Installer 特殊属性 重新安装模式.
• 一般来说，高版本文件会覆盖低版本文件.如果未修改，则非版本化文件将被覆盖.如果它们被修改，则创建和修改的日期戳会不同，文件将被保留.
• 请记住，整体 MSI 设计积极阻止文件降级的问题.如果您需要降级文件(共享与否)，那么您的设计就会部署有异味.

• As to update scenarios the MSI file replacement rules will take care of updating newer files, dependent upon the overall setting in the special Windows Installer property REINSTALLMODE.
• In general higher version files overwrite lower version files. Non-versioned files are overwritten if they are unmodified. If they are modified the create and modified date stamps are different and the file is left alone.
• Keep in mind that the issue of downgrading files is actively discouraged by the overall MSI design. If you need to downgrade files (shared or not), there is something deployment smelly about your design.

此时我会彻底阅读这些答案:

At this point I would thoroughly read these answers:

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

• Windows Installer and the creation of WiX - for a short Wix history and context
• Change my component GUID in wix? - for component reference counting
• Wix installation, server, client or both - for client / server packaging
• Wix to Install multiple Applications - for changing requirements and setup problems
• WiX tricks and tips - for community Wix tips and tricks
• How to include wxi file into wxs? - for a simple idea of how to deal with Wix include files

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

Provided you use Wix, or you are willing to use Wix, I would think the best way to deal with your overlapping products would be to decompose your installer into Wix segment source files that you include as needed in your main installers. This will allow the uninstall of one product to leave in place any components used by other applications.

话虽如此，我不喜欢在我的安装程序中造成太多重叠的依赖，原因在本文中列出(也在上面列出):Wix 安装多个应用程序.

With that being said, I do not like to cause too many overlapping dependencies in my installers for the reasons listed in this article (also listed above): Wix to Install multiple Applications .

为了稳定性，共享组件在被过多设置使用之前保持稳定作为一般规则的错误修复至关重要将需要重新编译共享组件被编译或合并到的所有设置.简单的表达方式:将一起更改的文件捆绑在一起.

For stability it is crucially important that shared components are stable before being used by too many setups as a bug fix as a general rule will require the recompilation of all setups the shared component is compiled or merged into. The easy way to say it: bundle files together that change together.

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

To counteract this need for massive recompilation, you can chose to deliver a stand-alone supporting setup consisting of some of the shared components. One, or a couple of such "shared components setups" that are likely to contain Wix includes that change together on a similar, slow release schedule, and then separate setups for each product should be able to account for any deployment need whilst maintaining a balance between maintainability and flexibility.

产品设置应该是经常被重新编译的设置，并且共享模块设置应该被设计为最小的重新编译.然后等待更改要求:-).

The product setup should then be the one that gets recompiled often, and the shared modules setups should be designed for minimal recompilation. Then wait for changing requirements :-).

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

To me it is all about cohesion and coupling, and the difficulty of balancing sales, marketing and technical needs.

这篇关于MSI 引用计数:两个产品安装相同的 MSI的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！