MSI Reference Counting: Two products install the same MSIs

Question

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?

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?

Answer 1

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

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.

There are some qualifications to this rule:

• 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

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

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.

Updating and file replacement:

• 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 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

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.

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.

Answer 2

If Product A and Product B has a MSI C in common then If Product A is installed, also MSI C is installed, now when Product B is installed MSI C will not be installed since its already available in the system (if Product B is WiX Burn based, it registers a dependency). In case of uninstallation reference counting is automatically handled if Product A and Product B is WiX Burn based installer or any other Bootstrapper which supports reference counting else MSI C is removed along with Product B.

Answer 3

even I was looking for the answer of the above question, but in Wix v3.7 and higher, the MSI packages are automatically reference counted by the Burn engine. I have tested this, and works perfect. The same can be checked in Rob's blog