Open topic with navigation
Project: This information applies to the following project types:
When you want to prepare an installation that updates a version of your product installed on an end user’s machine, you can consider two different methods for packaging your major upgrade, minor upgrade, or small update:
|•||You can package your upgrade as a full installation that updates an existing product if an earlier version is installed, or behaves as a first-time installation if no earlier version is present.|
|•||You can package your upgrade as a patch that contains only the changed data (.msi data and byte-level file differences) between the versions to be updated.|
Both a minor upgrade and a small update act like first-time installations if an earlier version is not present, or they install over an existing installation of a product. A major upgrade also acts like a first-time installation if an earlier version is not present; however, a major upgrade typically uninstalls any earlier version and then installs the new version.
Patches enable you to distribute just the bits and portions of the database necessary to update your application’s files to a specific version, possibly resulting in a much smaller package than an upgrade packaged as a full installation. This enables you to deploy your upgrades using much less bandwidth than that required to deploy a full-installation package.
Note: A patch is not a type of upgrade. Patching is simply a mechanism for distributing a major upgrade, a minor upgrade, or a small update with a small footprint. In fact, creating a patch involves first designing the upgrade and then packaging it as a patch. Before you create a patch, it is recommended that you test the upgrade as a full-installation package.
Determining the Best Packaging Option for Your Upgrade
The topic Determining the Best Upgrade Solution includes a table that you can review to determine what type of packing option you should use to update an earlier version of your product. In some cases, a standard patch or a QuickPatch may be seem to be the ideal mechanism for packaging your upgrade. However, under certain conditions, you should package your upgrade as a full installation instead of a patch. For example:
|•||If the target image was created with Windows Installer 1.2 or earlier, and the upgraded image is created with Windows Installer 2.0 or later, you should package your upgrade as a full installation, but not as a patch. Creating patches for packages that span this schema inflection point can be problematic. For more information, see Val0011, which describes the associated validator for upgrading and patching validation.|
|•||If you want your upgrade to move one or more files on the target system from one location to another, you should package your upgrade as a full installation, but not as a patch. If your end users install a patch for an upgrade that moves files on the target system, problems may occur. For example, the patch may not work, a repair to the target system may not work, a subsequent patch may not work, or end users may not be able to uninstall the product. As a workaround, you can create your patch so that it deletes the files in the old location and adds the files to the new location.|
|•||If you want to change your installation from compressed to uncompressed, or vice versa, you should package your upgrade as a full installation, but not as a patch. If you use a patch in this scenario, a repair to the target system may not work, a subsequent patch may not work, or the end user may not be able to uninstall the product.|
|•||If you need to move files from one .cab file to another, or if you need to change the order of files in a .cab file, you should package your upgrade as a full installation, but not as a patch.|
|•||If your original installation had more than 32,767 files but your latest installation has fewer than 32,767 files, a patch will fail. Similarly, if your original installation had fewer than 32,767 files but your latest installation has more than 32,767 files, a patch will fail. In either case, you should package your upgrade as a full installation.|
Note that if both the original installation and the latest installation have more than 32,767 (or both have fewer than 32,767 files), you can package your upgrade as a patch.
|•||Patches cannot be created for major upgrades of InstallScript MSI projects. Therefore, if you need to distribute a major upgrade for an InstallScript MSI project, you should package it as a full installation.|
Preventing the Current Installation from Overwriting a Future Major Version of the Same Product
InstallShield 2014 Help Library
|Copyright Information | Contact Us|