How should I handle product upgrades in a WiX installer?

Question

I have a reasonably large WiX installer (250 Mb plus) and I am trying to come up with a suitable upgrade strategy.

Most of the files in the installer will not change and we would prefer not to have to distribute the whole package when only one or two files have changed.

I have looked into major and minor upgrades and my understanding is that a major upgrade will happen if the Product ID changes, so long as the Upgrade ID stays the same and minor upgrade patches can be used if both of these values stay the same.

My feeling is that a minor upgrade using a patch would be the best option to handle the cases where only a few files change and only to rebuild the whole installer when a substantial number of files change.

I have tested this using "torch" to produce a "wixmst" file based on the differences between two "wixpdb" files, then building a patch from that. However, I found that I can only patch from one version to another (e.g. 1.0.0 to 1.0.1, then 1.0.1 to 1.0.2 but not 1.0.0 to 1.0.2). Is it possible to target a minimum version for a patch and support any version above it?

Answer 1

Patching is a pain so get ready for a lot of it as you learn to master it. Here's another strategy that might work for you. Split your MSI out into 2 MSI ( Microsoft calls this Micropackages ). Have a Base MSI that contains the bulk of your content that is expected to not change and a Second MSI that is much smaller that contains your files you expect to be high churn.

Then use Burn is a bootstrapper to handle chaining these together and uninstalling them together. This is similar to what Visual Studio does.

Now you can just ship major upgrades of your second MSI.

Answer 2

I believe that it is possible to patch in the scenario you described above, as long as the patches are uninstallable. An example scenario would be:

1. Install msi (v1.0)
2. Install msp (v1.0 - v1.1)
3. Uninstall msp (back to v1.0) then install msp (v1.0 - v1.2)

For more information on uninstallable patches, see the wix documentation: http://wix.sourceforge.net/manual-wix3/patch_restrictions.htm and the Windows documentation: http://msdn.microsoft.com/en-us/library/aa372102.aspx.

Note that to create uninstallable patches there are certain restrictions and you must be at WiX 3.0 or greater.

Like Christopher mentioned, patching can be a pain. I have found that in many cases, my managers may ask for the ability to do patch upgrades when all they really mean is for the user to be able to upgrade without manually installing first, which can be accomplished by a major upgrade just fine.

That said, if you have customers that require many small updates that get downloaded frequently, then patching may be worth the extra effort.

Answer 3

While Christophers answer is awesome in that he suggests the wix bootstrapper, I would discourage the route of doing major updates for the "high-churn" package. The problem is that after you have done your bootstrapping patch which internally does a major upgrade of your volatile libs in the HighChurn.msi from version v1.0 to v1.1, the bootstrapper will not, to my knowledge, re-install the previous package of HighChurn.msi in v1.0.

There's another path: you can certainly author patches which target the release of your main package. Given what you wrote I'm not entirely sure, but if your 1.2 patch can only be applied to 1.1, then you probably diffed your 1.2 only against 1.1, and not against 1.0.

Here's a neat guide how to create patches: https://www.firegiant.com/wix/tutorial/upgrades-and-modularization/patchwork/

Follow that guide, do superseding patches ([PatchFamily/@Supersede], it'll make v1.2 invalidate everything which v1.1 shipped, so you are basically forced to make v1.2 patch v1.0 and not v1.1), and add this flag to the patch element to target the major release, even though higher versions are present: Patch/@MinorUpdateTargetRTM="yes". Always diff your patches against the release installer (HighChurn.msi v1.0), never against the installer you used for a patch (HighChurn.msi v1.1).

There are of course situations where you might want to require a certain upgrade installed for patches: A well planned fixpack/servicepack scheme, for example, where patch 1.1.1 requires service pack 1.1 installed on top of the release 1.0.

A final word on patching your volatile data (I'm presuming versioned libraries here): You might want to have an eye on which libs you could basically replace in the patch. Then you can create patches with very few data, by only giving the changed libraries a higher version. If you increase the version on all of your libraries, all libraries are going to be patched, resulting in larger patches. This might require a slightly more complicated build workflow (God knows it did for us).