Patch Sequencing

InstallShield 2013

Project: This information applies to the following project types:

Basic MSI
InstallScript MSI
QuickPatch

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.

Sample Application Lifecycle for Patches Applied with Versions of Windows Installer Earlier than 3.0

Application Package

Product Version

Previous Setups Targeted by Package

1. Base installation

1.0

2. Minor upgrade

1.1

1.0

3. Minor upgrade

1.2

1.0, 1.1

4. Minor upgrade

1.3

1.0, 1.1, 1.2

5. Minor upgrade

1.4

1.0, 1.1, 1.2, 1.3

6. Major upgrade

2.0

1.0, 1.1, 1.2, 1.3, 1.4

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.

Sample Application Lifecycle for Patches Applied with Windows Installer 3.0

Application Package

Patch Sequence Number

Product Version

Previous Setups Targeted by Package

1. Base installation

1.0

2. Small update

1

1.0

1.0

3. Small update

2

1.0

1.0

4. Small update

3

1.0

1.0

5. Small update

4

1.0

1.0

6. Minor upgrade

1.1

1.0

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:

If you want your minor-upgrade patch to essentially remove all of the patches up to the RTM version of the product (or the most recent major upgrade of the product, if one has been installed) before applying the current minor-upgrade patch, select Yes for this property. With this option, all patches (with or without sequencing data) are removed. You do not need to target additional baseline versions and thus increase the patch payload. All end users can successfully apply the patch without applying any intermediate patches.
If you do not want your minor-upgrade patch to remove all of those earlier patches, select No. If you select this option, it may be necessary for your patch to contain the information needed to target each of the earlier minor upgrades that were created after the RTM (or the most recent major upgrade of the product, if one was created).

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:

Select Yes for the Uninstall Superseded Component setting for an individual component to indicate that you want it to be uninstalled if appropriate. If you select Yes, InstallShield adds the msidbComponentAttributesUninstallOnSupersedence attribute to the component in the Component table.

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.

To indicate that you want all superfluous components in a superseded patch to be uninstalled, set the value of the Windows Installer property MSIUNINSTALLSUPERSEDEDCOMPONENTS to 1. You can set the value of the property from the command line or by adding this property to your project through the Property Manager view.

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

See Also