Creating a patch with InstallShield Express 4.0

InstallShield Express 4.0 introduced a new feature for creating simple patch packages. This feature, which InstallShield calls its QuickPatch technology, allows you to create a patch capable of updating or adding files and registry entries to previously installed versions of your product.

Like full setup packages, patch packages created by InstallShield Express are Windows Installer patch packages. Unlike a full setup package, a Windows Installer patch can only be applied to a previous Windows Installer setup. This means that in order to apply a patch to your product, the previous version of your product must have been installed using Windows Installer. For example, VFP 8 SP1 is a patch and can only be installed on machines with the original release of VFP8 already installed.

Patches created with QuickPatch are intended for situations where all you need to do is update or add a few files and/or registry entries to a previously installed product. One reason to consider using a patch package in these situations is because a patch package is usually much smaller than the corresponding full update package would be.

Overview

It only takes a few simple steps to create a patch, but the process can seem a bit confusing at first. The following overview of the patch creation and deployment process should help you understand what ‚ s involved before we get into the details.

1. Create a new InstallShield Express QuickPatch project.

2. Identify the Windows Installer setup package to patch.

3. Specify the files to update or add.

4. Specify the registry entries to change or add (if any).

5. Build the patch package.

6. Deploy the patch package to your users.

The QuickPatch project wizard

When you tell InstallShield Express to create a new QuickPatch project, the first thing it does is launch the QuickPatch project wizard. This wizard, which really has only one step if you don ‚ t count the Welcome and Finished dialogs, prompts you to enter a name for your new project file and asks you to identify the Windows Installer setup package on which the patch is going to be based. The QuickPatch Project Wizard is shown in Figure 27 .

Figure 27. The QuickPatch Project Wizard prompts you for a project name and for the location of the original setup package.

The QuickPatch project name can be whatever you want it to be. Like the names for other update packages, we suggest you consider using a name that includes a reference to the product ‚ s version number. When you have dozens of project files for the same product, a naming scheme like this makes it easier to identify a particular project file later on.

In the second field shown in Figure 27, you specify the setup package used to deploy the original version of the product. To do this, you need access to the SETUP.EXE or MSI file from this original deployment package. In this example, we are creating a patch to update the Appendix A Demo App from version 1.0.0 to version 1.0.1. The patch is therefore based on the original setup package for version 1.0.0, which is contained in the single-image build file SETUP.EXE we created earlier.

You might wonder why a wizard is necessary just to gather two pieces of information. The answer is the wizard does one other very important thing when it finishes, and that is to create a base image of the original setup. The base image is an uncompressed copy of the files in the original setup package. The QuickPatch Project Wizard creates the base image by performing an administrative installation of the original setup package. An administrative install extracts the files from the setup package and writes them to disk, but does not actually install the product.

The files extracted from the original setup package by the administrative install are written to a sub-folder named BASEIMAGE, created underneath the project folder as shown in Figure 28 . After the administrative install is finished, the BASEIMAGE folder and its subfolders contain the MSI file from the original installation along with all of the files the original setup installs .

Figure 28. The QuickPatch Project Wizard performs an administrative install of the original setup package and writes the files to the BASEIMAGE folder.

The QuickPatch IDE

As soon as the QuickPatch Project Wizard finishes and the administrative install is complete, the new QuickPatch project opens in the InstallShield IDE. The IDE for a QuickPatch project, of course, is different from the IDE for a regular setup project. There are only three steps in the QuickPatch IDE. As we work through them, keep in mind the overview of the patch creation process presented earlier in this section.

General Information view

The General Information view of the QuickPatch IDE has three parts : Product Properties, Build Settings, and History.

Product Properties

The Product Properties view is where you specify the path to the original setup package. Because we arrived at this view directly from the QuickPatch Project Wizard, this information is already filled in for this project, as you can see in Figure 29 . Note that the value in the Original Setup Path field in Figure 29 references the BaseImage folder we described in the previous section. This is the setup package on which the patch is based.

Figure 29. The QuickPatch IDE has three steps. In the General Information step, the Product Properties view identifies the path to the original setup package on which the patch is based.

In the Project Properties view you can also specify a new Product Version for your product. The Product Version is a Windows Installer property, and in general it is a good idea to update this whenever you deploy a patch because it enables future updates to determine which version of the product is currently installed on the user ‚ s computer. Although there is no hard and fast rule about what value to use for the Product Version, it makes sense to us to make it the same as the version number of the app ‚ s main EXE file. In Figure 29 you can see we are updating the Demo App from version 1.0.0 to version 1.0.1 with this patch.

Build Settings

The Build Settings view allows you to specify where you want to write your patch package. The default is a sub-folder underneath the current project folder. This view also allows you to decide whether you want to create an UPDATE.EXE. If you choose to create an UPDATE.EXE, you can include the Windows Installer engine and/or the .NET framework if you want to. If you do not create an UPDATE.EXE your patch is created in the form of a Windows Installer MSP file. While the MSP file may be preferable for distributing a patch in some administrative deployments, an UPDATE.EXE is much easier for the typical end user to install because all they have to do is run it.

History

The History view lists the base image and all of the interim releases based on it up to and including the one you are currently working on. The purpose of this view is to allow you to specify which of the interim releases you want to include in this project. If you plan to include earlier releases in future projects, be sure not to modify them after they are deployed or your future projects may not work as intended, if at all.

Files View

The Files view of the QuickPatch IDE is where you identify the files to update with this patch. You can also use this view to add new files to the setup if necessary. The Files view is shown in Figure 30 .

Figure 30. The Files view is where you specify the files to be patched.

To specify that this patch update a particular file, right-click Files To Patch in the lower left pane and choose Patch Existing File from the shortcut menu. This opens a list of files for you to choose the one to be patched. You can also select a file from the Original Setup Files tree in the upper left pane and drag it to the Files to Patch tree in the lower left pane.

After a file is added to the Files To Patch tree, selecting it in the lower left pane displays its patch properties in the right-hand pane. The most important property, of course, is the location of the updated version of the file. In Figure 30, you can see the updated version of DEMOAPP.EXE is being brought into the patch project from the C:\DEPLOYFOX\DEMOAPP\ folder. Lower down in that same pane you can see the original file ‚ s version information and the new file ‚ s version information, which provides visual confirmation of what the patch will do.

There are two other properties you can set for each file in the Files view. The first is the Overwrite Any Existing File option. When this option is selected, the patch contains the new version of the file in its entirety, enabling the patch to overwrite any previous version of the file. If this option is not selected, the patch contains only the bits that are different between the original version and the new version; this results in a smaller patch package but means the patch can be applied only to that one specific version of the original file.

The other property you can set in the right-hand pane is a setting to make the patch delete the file from the setup. Marking a file for deletion means it is removed from the user ‚ s computer during installation of the patch. This can be useful if a file used by the previous version is no longer needed by the newer version.

Note ‚ 

Our testing of patch packages revealed that a file marked for deletion in a patch is removed even if the file was marked as ‚Permanent ‚ in the original install. On the other hand, a non-versioned file (such as a DBF or TXT file) marked as ‚Never Overwrite ‚ in the original install is not overwritten even if that file is marked as ‚Overwrite Any Existing File ‚ in the patch package. We recommend you do your own testing if these situations arise as part of your own deployment scenarios.

Repeat the above procedure for each file to update, add, or delete with your patch. If you add a new file as part of a patch, you need to specify a destination folder and associate the file with one of the features of your product. By default, a new file is associated with the AlwaysInstall feature and its destination folder is set to [INSTALLDIR].

Registry View

The Registry view in the QuickPatch IDE allows you to modify, delete, or rename registry entries from the original setup package, as well as add new registry entries if needed. The layout of the Registry view is very similar to the Files view, and like the Files view, it populates a tree with the entries from the original setup, making it easy to locate and change them.

Building the patch

Once you complete all of the entries in the QuickPatch project, building the patch package is as simple as clicking the Build button on the InstallShield Express toolbar. As it builds the patch package, InstallShield Express creates additional sub-folders for the updated image files, the Windows Installer patch creation properties (PCP) file and a patch creation log file, and the patch package itself. Figure 31 shows the folder structure under the project folder after the patch is built.

Figure 31. After the patch is built, the project ‚ s folder tree contains sub-folders for the updated image files, the patch creation file and a log file, and the patch package itself.

As explained in Chapter 5, ‚“Windows Installer Inside and Out, ‚½ a patch package is the difference between two setup packages. This implies you need two setup packages to create a patch package. The setup package for the original version of the product already exists ‚it ‚ s the one you specified at the beginning of the patch creation process. But where did the second setup package come from?

The answer is InstallShield Express creates a new package for the updated setup and writes it to the UPDATEDIMAGE folder during the build process. If you look in the UPDATEDIMAGE folder tree after building your patch, you ‚ ll see each of the updated files is there along with a new MSI (Windows Installer database) file. Once the updated setup package is created, InstallShield Express can then generate a file that contains the instructions and resources necessary to transform the original setup package into the updated setup package. This file is the patch package you deploy to your users.

Deploying the patch

To deploy the patch you just created, simply send out the patch package created by the build process above. If you chose to create an UPDATE.EXE in the Build Settings view, then the only thing your users need to do to apply the patch to their existing installation of your product is run UPDATE.EXE. If you did not choose to create an UPDATE.EXE, then your patch package is in the form of a Windows Installer patch file with an MSP file name extension. To install a patch from an MSP file, right-click it and choose ‚“Apply Patch ‚½ from the shortcut menu.

Either way, building a patch enables you to deploy an update for your product in a package that is considerably smaller than the corresponding full update package would be.