InstallShield 2019 Express Edition
Project • This information applies to the following project types:
| • | Express |
| • | QuickPatch |
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 upgrade:
| • | 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 QuickPatch that contains only the changed data (.msi data and byte-level file differences) between the versions to be updated. |
Full-Installation Packages
A major upgrade acts like a first-time installation if an earlier version of the product is not present. If an earlier version is present, a major upgrade typically uninstalls the earlier version and then installs the new version.
QuickPatch Packages
QuickPatch packages 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 an upgrade with a small footprint.
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 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 QuickPatch. The following table serves as a guide to help you determine which type of upgrade best suits your needs. If any one of the requirements for your upgrade is not appropriate for a QuickPatch, you should create a full-installation upgrade.
|
Requirement for the Upgrade or QuickPatch |
Create a Full-Installation Upgrade? |
Create a QuickPatch? |
Note |
|
Ability to apply many cumulative updates that upgrade a base package |
Yes |
Yes, if you are using QuickPatch streamlining |
If you are not using QuickPatch streamlining, you cannot patch more than 15 times. For more details, see Specifying Whether to Streamline the QuickPatch Package. |
|
Change the name of the .msi package |
Yes |
No |
The default file name is taken from the Product Name property, provided the .msi file is not compressed in a Setup.exe installation launcher. |
|
Enable end users to install earlier versions and the latest version on the same machine |
Yes |
No |
|
|
Add a new subfeature |
Yes |
No |
|
|
Add, modify, or remove a file |
Yes |
Yes |
|
|
Add, modify, or delete registry data |
Yes |
Yes |
All new registry data being added with a QuickPatch must be associated with a feature that already exists in the original product. |
|
Add, modify, or delete a shortcut |
Yes |
No |
|
|
Add, modify, or delete custom actions |
Yes |
Can only delete custom actions that were included in the original base installation. |
|
|
Add or remove a redistributable |
Yes |
No |
|
|
Add, modify, or remove ODBC resources |
Yes |
No |
|
|
Edit an .ini file |
Yes |
No |
|
|
Configure server settings such as IIS Web sites and component services |
Yes |
No |
|
Also note the following details when you are determining what type of packing option you should use to update an earlier version of your product:
| • | 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 QuickPatch. Creating a QuickPatch for a package that spans this schema inflection point can be problematic. |
| • | 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 QuickPatch. 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 QuickPatch 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 QuickPatch. If you use a QuickPatch in this scenario, a repair to the target system may not work, a subsequent QuickPatch 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 QuickPatch. |
| • | If your original installation had more than 32,767 files but your latest installation has fewer than 32,767 files, a QuickPatch will fail. Similarly, if your original installation had fewer than 32,767 files but your latest installation has more than 32,767 files, a QuickPatch 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 QuickPatch.
See Also
Preventing the Current Installation from Overwriting a Future Major Version of the Same Product
Working with Upgrades and QuickPatch Projects
Packaging Options for Upgrades
InstallShield 2019 Express Edition Help LibraryApril 2019 |
Copyright Information | Flexera |