Determining the Best Upgrade Solution

InstallShield 2020

The methods used to create an upgrade for a product depend on how the original installation package was developed. If the original installation was created with a Windows Installer–based project, you will essentially create a major upgrade, a minor upgrade, or a small update to update your product. If the original installation was created with an InstallScript project, you will create a differential or full release to update your product. Both types of projects are discussed below.

Basic MSI and InstallScript MSI Projects

The first step in creating an installation for any type of upgrade is identifying whether you want to address target systems that do not have any earlier version of your product. Then you can determine what type of method you should use to package the upgrade. The following table presents a general overview to help you decide which method you should use. For a more in-depth discussion of the techniques for packaging the upgrade, see Packaging Options for Upgrades.

Possible Upgrade Solutions for Windows Installer–Based Projects

Status of the Target Systems

Type of Installation Needed

Technique for Packaging the Update

Some of the target systems have an earlier version of the product, and some do not have any version of the product.

If file size is not an issue, you can create one installation that does both of the following:

Behaves as a first-time installation if an earlier version of the product is not already present on the target system
Updates an existing product if it is already installed on the target system

Create a major or minor upgrade and package it as a full installation.

Some of the target systems have an earlier version of the product, and some do not have any version of the product.

If you want a small installation for end users who need to update an earlier version of the product, you can create two separate installations:

A full installation that behaves as a first-time installation.
A smaller installation that updates one or more earlier versions of an already installed product. Since this installation consists of only the changed data between the versions to be updated, it usually enables you to deploy your upgrade using much less bandwidth than that required to deploy a full-installation package.

For the first-time installation, create a major or minor upgrade and package it as a full installation. For end users who have an earlier version of your product, create a major or minor upgrade and package it as a patch.

Tip:In some cases, a patch is not appropriate. For more guidelines on determining whether a patch is appropriate for your upgrade, see Packaging Options for Upgrades.

Note:A patch package is not a type of upgrade; it is simply a mechanism for distributing an upgrade with a small footprint.

All of the target systems have an earlier version of the product.

You can create a small installation that updates one or more earlier versions of an already installed product. Since this installation consists of only the changed data between the versions to be updated, it usually enables you to deploy your upgrade using much less bandwidth than that required to deploy a full-installation package.

Do either of the following:

Create a major or minor upgrade and package it as a standard patch.
Create a QuickPatch project.

The QuickPatch technology in InstallShield enables you to create simple patches for previously installed products. Although customization is somewhat limited when you create a patch by using a QuickPatch project, the creation of a QuickPatch project is a simpler alternative to creating a standard patch. For more details, see Patch vs. QuickPatch Project.

Note:Like a standard patch, a QuickPatch is a mechanism for distributing an upgrade with a small footprint.

InstallScript Projects

If the original installation was created with an InstallScript project, you can create one of two types of update releases:

Differential release—This type of release contains the files that are absent from—and/or have a different date, time, size, or attribute than the version in—one or more of a specified set of existing releases. A differential release is used to update the versions of your product that were installed by those existing releases.
Full (non-differential) release—This type of release behaves as a first-time installation if an earlier version of the product is not already present on the target system. It also is capable of installing over an earlier version and replacing that version completely.

Since a differential release consists of only the changed files between the versions to be updated, it usually enables you to deploy your update using much less bandwidth than that required to deploy the full release. However, only a full release can be installed on a system on which no version of your product is currently installed. For more details, see Differential Releases and Full Releases.

See Also