Patch Sequencing

InstallShield 2019

Project • This information applies to the following project types:

InstallShield enables you to specify the order that Windows Installer version 3.0 or later should apply small-update patches to an installed product, regardless of the order in which they are provided to the target machine. With patch sequencing data, you can ensure that Windows Installer knows the intended relationships among the upgrades packaged within a family of patches. Consequently, applying patch 1 of a product after patch 2 has already been applied will register patch 1 without overwriting patch 2 files. For versions of Windows Installer earlier than version 3.0, the patch sequence is ignored, and any small-update patches are applied to the product in the order that they are provided to the target machine.

The patch sequencing functionality available with Windows Installer 3.0 and later simplifies the patch creation process. The following sections show how.

Creating Patches to Be Applied with Versions of Windows Installer Earlier than 3.0

If you need to create your patches so that they can be applied to your product via versions of Windows Installer earlier than 3.0, it is recommended that you avoid creating small updates. Small updates do not change the product version; therefore, external programs, including installers for later versions of your product, cannot distinguish a product with the small update applied from one without the small update. For scenarios limited to versions of Windows Installer earlier than 3.0, you need to plan around such limitations of the installer, thus targeting an increasing number of possible earlier product states. The sample application lifecycle presented in the following table illustrates the resulting complexity.

Creating Patches to Be Applied with Windows Installer 3.0

With the patch sequencing functionality available with Windows Installer 3.0 and later, you can safely use a small-update patch to deliver a discrete upgrade for several different versions of a product, even though small updates do not change the product version. Unlike a small update, a minor upgrade changes the product version. Minor upgrades also form the framework for the sequencing of small-updates patches. If a small update for version 1.1 of a product is applied to version 1.2, the installer registers the small update on the target system and applies it as if it were encountered before the 1.2 minor upgrade was applied.

Small-update patches also enable Windows Installer 3.0 and later to maintain a valid product state as other patches are applied and removed individually from the product. In addition, patch sequencing lets you generate upgrade packages from a smaller set of earlier product states without requiring you to consider every possible combination of patches that could exist on the target machine. The sample application lifecycle presented in the following table illustrates this advantage.

All of the small updates in the table above belong to the same patch family. Windows Installer 3.0 and later uses the patch family to compare a small-update patch with all of the other patches within the same family and determine the order in which each of the patches should be applied to the target machine. Patch sequences are added to the MsiPatchSequence table of the patch package database. This table defines the relationships between patches that target the same family of patches.

Creating Patches to Be Applied with Windows Installer 3.1

The patch sequencing functionality available with Windows Installer 3.1 enables you to further simplify the patch creation process with respect to minor upgrades. The Minor Update to Target RTM Version (MSI 3.1 Required) property on the Advanced tab of the Patch Design view lets you specify whether you want a minor-upgrade patch to target the release to manufacturing (RTM) version of the product (or the most recent major upgrade of the product, if one has been installed). You have two options for this property:

For example, if you are creating a minor-upgrade patch for service pack 2 and you select No for this property, your patch needs to target the minor-upgrade patch for service pack 1. You could also optionally target other baselines (such as RTM); doing so would increase the patch payload. Note that if you do not target the RTM version, any end user who has the RTM version but not the service pack 1 minor-upgrade patch would need to install service pack 1 before service pack 2.

Creating Patches to Be Applied with Windows Installer 4.5

If a superseded patch installs a component for the product but later a superseding patch removes that component, the component’s feature state may be changed to advertised, and it may not reinstalled. In addition, none of the remaining components associated with that feature can be maintained. This can be a problem on target systems that have Windows Installer 4.0 or earlier. The patch sequencing functionality available with Windows Installer 4.5 offers enhanced supersedence robustness to avoid this issue.

You can specify that a component in the current patch should be flagged for uninstallation in order to avoid leaving this component orphaned on the target system after a future superseding patch is applied. If a subsequent patch is installed and it is flagged to supersede the first patch, Windows Installer 4.5 can unregister and uninstall this component if appropriate.

Windows Installer 4.5 supports two methods for flagging superfluous components for uninstallation if they are superseded:

To access the Uninstall Superseded Component setting, open the Components view and then select the component that you want to configure. The setting is displayed in the grid on the right. The default value of this setting is No.

Windows Installer 4.0 and earlier ignore the msidbComponentAttributesUninstallOnSupersedence attribute and the MSIUNINSTALLSUPERSEDEDCOMPONENTS property.

See Also

MsiPatchSequence Table (Windows Installer Help Library)

Sequencing Patches

Open topic with navigation