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的通用MSIC.如何在不使用Permanent标志的情况下妥善处理此问题?

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 Installer从未对其进行跟踪，也不会被卸载
• 最后，用于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的安装程序源文件)，可以通过请参阅Wix链接进行解释).意识到" Wix源包含文件"与合并模块具有完全相同的作用，这是至关重要的-正确计数了其组件的引用，以便在不同的安装程序包之间共享，前提是源文件中的GUID是硬编码的(为此，我建议不要使用自动生成的GUID).我个人认为，应该对通用运行时文件使用第三方合并模块，但是仅 Wix包括用于自己的共享文件.合并模块比Wix包含imho更加难以管理.

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属性

• 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技巧和窍门
• 如何将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.

话虽这么说，但我不喜欢在安装程序中引起过多重叠的依赖关系，原因是本文中列出的原因(也在上面列出):

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屋！