Updates, upgrades, and patches


New bits for old

Getting the initial version of your application installed on an end- user ‚ s computer is just the beginning. In the real world, software applications are updated all the time, and a significant portion of your time as a setup developer will likely be devoted to planning, organizing, and distributing updates for your product.

This is an area that can initially be the source of much frustration when working with Windows Installer. Part of that frustration for VFP developers was probably due to the version of InstallShield Express (ISX) that shipped with VFP 7, which lacked the ability to create upgrades. The version of ISX that ships with VFP 8 does not suffer from this limitation, but the handling of Windows Installer updates and upgrades is still complicated because there are several ways you can go about it.

As with any software update, the objective is to replace certain ‚“old bits ‚½ on the user ‚ s computer with ‚“new bits. ‚½ With Windows Installer, there are three types of new bits to know about:

  • Small updates

  • Minor upgrades

  • Major upgrades

Although Windows Installer makes a distinction between an update and an upgrade, in this chapter we refer to them collectively as ‚“updates, ‚½ in the general sense of that word, unless talking specifically about one type or another.

The type of update you choose depends mostly on the extent of the changes you are making to your product. The difference as far as Windows Installer is concerned has to do with what gets changed in the MSI file, as shown in Table 2 . This in turn has implications for how the update is installed and how one update may affects subsequent updates.

Table 2. Small updates, minor upgrades, and major upgrades

Type of Install

Package Code

Product Version

Product Code

Upgrade Code

Small update

change

don ‚ t change

don ‚ t change

don ‚ t change

Minor upgrade

change

change

don ‚ t change

don ‚ t change

Major upgrade

change

change

change

don ‚ t change

Looking at Table 2, you can see that whereas the other values change or remain the same according to the type of update, the Upgrade Code remains the same for all types of updates. This makes sense, because as noted earlier, the Upgrade Code is the common identifier across all versions of a given product.

You might observe that there ‚ s a fourth possibility not shown in Table 2 ‚namely, what happens if you distribute a revised MSI file, but don ‚ t change any of these four values? The answer is when Windows Installer processes a setup package whose Package Code is the same as that of a package already installed on the computer, it processes the cached version of the setup package rather than the new one. The result is Windows Installer gives the user a choice to ‚“Modify, Repair, or Remove ‚½ the original product rather than installing any files from the new setup package. Therefore this approach cannot be used to distribute an update even if the new setup package contains updated application files.

Small updates (Example: DFCHAPTER5_MSI101.ZIP)

A small update is an update that does not warrant changing either the product version or the product code. This does not mean the version number of a versioned file such as an EXE cannot be incremented using a small update ‚it can. Be sure to note the distinction between the term ‚“product version, ‚½ which refers to a property of the MSI file itself, and the term ‚“version number, ‚½ which refers to the number assigned to a versioned file within the product. The definition of a small update is the product version of the MSI file does not change.

Windows Installer has a specific set of guidelines for determining whether or not the product code of an update must be changed. Because neither small updates nor minor upgrades change the product code, the changes you can make to your application with either of these two types of updates are limited to those that fall within those guidelines.

A complete list of the guidelines for changing the product code is found in the Windows Installer SDK documentation. [5] Among the important guidelines to be aware of when creating a small update are these:

  • The update cannot change the name of the MSI file

  • The update cannot change the name of a component ‚ s key file

  • The update can add new features and components , but it cannot reorganize the parent-feature / child-feature hierarchy

  • If the update includes a change to the version number of a versioned file, that file ‚ s Version property must be changed in the File table of the MSI database.

Figure 14 is a screenshot from InstallShield Express v4.0, which we used to create the small update package. Note that the Product Version is still 1.0.0, even though the version number of the EXE file (not shown) is 1.0.1. Also note that the Product Code GUID and the Upgrade Code GUID are unchanged from version 1.0.0. The Package Code GUID, however, is unique for this update package.


Figure 14. The Product Version remains unchanged at 1.0.0 for a small update.

Because a small update does not change either the product version or the product code, it must be processed as a reinstallation of the existing product. If not, Windows Installer attempts to process the setup package as a fresh install of the product, which fails with the error message ‚“Another version of this product is already installed. ‚½ This error, which is perhaps the most frequently encountered problem when first distributing Windows Installer update packages, is discussed in more detail in the section entitled ‚“Common problems and what to do about them ‚½ at the end of this chapter.

To avoid this error, you must tell Windows Installer to process the small update as a reinstallation of the existing product. This is done by setting the value of certain properties to indicate it ‚ s a reinstall of an existing product. Specifically, you need to set the value of the REINSTALLMODE property to ‚“vomus ‚½ and the value of the REINSTALL property to ‚“ALL. ‚½ (See Table 4 for an explanation of the REINSTALLMODE codes.) You set these values at installation time by passing parameters to the Windows Installer executable program; more information on how to do this is presented in the section on ‚“MSIEXEC ‚ the Windows Installer executable program ‚½ later in this chapter.

One limitation to be aware of when deploying small updates is the user does not get the opportunity to change any previously selected options, such as where the product is installed. Small updates and minor upgrades should be thought of as reinstallations of the existing product, implying they are applied ‚“on top of ‚½ the existing installation. To change the location of an installed product, you should either uninstall it and reinstall it as two separate steps, or you should create a major upgrade that performs a silent uninstall of the previous version and gives the user the opportunity to specify a different location for the new version.

Note ‚ 

The downloads for this chapter include a series of four setups for the demo app. Version 1.0.0 is the initial installation. Version 1.0.1 is a small update, while version 1.1.0 is a minor upgrade. Neither the small update nor the minor upgrade allows you to change the location of the product. The setup package for version 2.0.0, however, is configured as a major upgrade. It does a silent uninstall of version 1.x and allows you to specify a different location for version 2.0.0.

Because a small update does not change either the product version or the product code, Windows Installer will not subsequently be able to differentiate between the pre-update product and the post-update product. If it will be necessary to differentiate between the two versions of the product in the future ‚for example, if you want to release future updates that apply only to a specific version or versions of the product ‚then you should use a minor upgrade instead of a small update.

Minor upgrades (Example: DFCHAPTER5_MSI110.ZIP)

A minor upgrade is similar to a small update in that neither of them changes the product code, and therefore both of them must observe the rules for creating an update with the same product code as an existing product. Unlike a small update, however, a minor upgrade does change the product version. For example, a minor upgrade could be used to update myProduct version 1.0.0 to myProduct version 1.1.0.

On The Web ‚ 

The downloads for this chapter include a setup package configured as a minor upgrade to the sample application that updates it from version 1.0.0 (or 1.0.1) to version 1.1.0.

Figure 15 is a screenshot from InstallShield Express showing the updated Product Version property for this package. Note that the Product Code GUID and the Upgrade Code GUID are the same as in the original package for version 1.0.0 and for the small update version 1.0.1.


Figure 15. The Product Version changes from 1.0.0 to 1.1.0 for a minor upgrade to the sample application.

As with the small update, the setup package for the minor upgrade has a unique package code GUID. In the files distributed with this update, the version number of the application ‚ s EXE file changes to 1.1.0. Although not required, this in keeping with the general rule of thumb that the version number of the VFP application ‚ s main EXE file be kept in sync with the product version of the MSI file that distributes it.

Like the small update, a minor upgrade is also run as a reinstallation of the product using the same techniques described for small updates in the previous section. The difference is that following the installation of the minor upgrade, Windows Installer is aware that a different version of the product is now installed because the product version is updated.

What about data files updated by the user after the original installation of the product? If the original installation of the product included data files ‚for example, an empty database to be used as a starting point for the application ‚and if the setup package for the small update or the minor upgrade includes the same empty data files as the original setup package, won ‚ t those empty data files overwrite the user ‚ s data when the update is applied?

The answer is no, and the reason is because of the versioning rules Windows Installer uses to determine which files to replace during installation. Any file the user has been updating, such as the application ‚ s data files, has a Modified date that is later than its Create date. Because data files are not versioned files, Windows Installer uses these two dates to determine whether or not the file should be replaced. If the two dates are different, the file is not replaced during reinstallation of the product.

Major upgrades (Example: DFCHAPTER5_MSI200.ZIP)

A major upgrade, as the name implies, represents a significant change to the product. As you know from Table 2, a major upgrade changes both the product code and the product version number. The implication is that if the changes are significant enough to qualify as a major upgrade, they are probably significant enough to warrant a change in the ‚“major version ‚½ portion of the product version number. For example, a change from version 1.0 of a product to version 2.0 of the same product implies a major upgrade.

Although a major upgrade changes both the product code and the product version, it continues to use the same upgrade code as earlier releases of the product. This common upgrade code is what enables Windows Installer to identify any previously installed versions of the product the major upgrade is intended to replace.

Because an upgrade code is required to enable major upgrades later in a product ‚ s life cycle, it is important to include an upgrade code in all releases of a product starting with its very first release. Most if not all third-party Windows Installer-based setup tools automatically insert an upgrade code for you when you first create a setup package, so this is generally not something you have to remember to do manually. What you do need to remember to do, though, is to ensure the upgrade code remains the same in all future setup packages you create for the same product.

Besides changing both the product code and the product version number, one other thing that distinguishes major upgrades from small updates and minor upgrades is the use of the Upgrade table in the MSI database. Every setup package for a major upgrade requires at least one entry in the Upgrade table. The information carried in the Upgrade table includes the upgrade code, the minimum product version number, and the maximum product version number of the product(s) the major upgrade replaces .

To illustrate this, we constructed a major upgrade for this chapter ‚ s sample application. This major upgrade replaces any version 1.x of the sample application with version 2.0. The Upgrade table from the setup package for this major upgrade is shown in Figure 16 . Looking at the UpgradeCode column, you can see it contains the same upgrade code used for versions 1.x of the product. The values in the VersionMin and VersionMax columns in Figure 16 tell Windows Installer this upgrade applies to versions 1.0.0 through 1.1.0 of the product, which in the case of our sample application spans the entire range of earlier versions that were released.


Figure 16. The Upgrade table is used by major upgrades to specify the minimum and maximum versions the upgrade applies to, as well as other information.

The mechanics of building the Upgrade table depends on the particular setup tool you are using. In InstallShield Express, it is done by creating what InstallShield calls an ‚“upgrade path . ‚½ [6] The values you assign to the various properties of the upgrade path in the InstallShield IDE correspond to the values in the Upgrade table of the MSI file created when you build the setup package.

Another important difference between a major upgrade and a small update or a minor upgrade is a major update usually entails the removal of the older version of the product. Windows Installer accomplishes this by performing a silent uninstall of the previous version of the product during installation of the new version of the product. In general, this is a good thing, because it ensures older resources ‚files, registry entries, shortcuts, etc. ‚installed as part of a previous version get removed and aren ‚ t left behind to clutter up the user ‚ s hard drive if they are no longer needed by the new version.

In this way, the state of the computer following installation of a major upgrade is, ideally , the same as the state the computer following a fresh install of the new version.

Removing earlier versions of the product can cause serious consequences, however, if the resources associated with the earlier version of the product include data files. This is of particular concern to VFP developers, whose products almost always involve data files of one kind or another. The risk occurs if the data files were copied to the computer as part of the installation of the product, as opposed to being created when the product was run for the first time. Unless you take steps to prevent it, data files installed with the product are removed from the computer along with the rest of the files from the earlier version of the product during installation of a major upgrade. Needless to say, this could have disastrous consequences for your users.

The solution to this problem is to mark the data files installed with your product as permanent files. In the Windows Installer database, this is done at the component level by setting a bit flag in the Attributes column of the appropriate row(s) of the Component table. A bit flag value of 16 (0x0010) identifies the component as permanent. In InstallShield Express, this is done by right-clicking a file in the Destination Computer ‚ s Files pane of the Files section of the IDE, opening the Properties sheet, selecting the Advanced tab, and marking the Permanent check box, as illustrated in Figure 17 .


Figure 17. In InstallShield Express, you can mark a file as Permanent on the Advanced tab of the Properties dialog.

The effect of marking a component as permanent is to add 16 to the value of the Attributes column in this component ‚ s row in the Components table. If you are making this change manually with Orca, remember these are bit flags, so to apply more than one attribute you add the values together. Referring back to Figure 8, you can see an Attributes value of 18 for the two data files in the demo app; this is the sum of the value 2, meaning optional, plus the value 16, meaning permanent.

Note that Figure 17 also shows a check box labeled ‚“Never Overwrite. ‚½ Like the Permanent setting, Never Overwrite is a bit flag in the Attributes column of the Component table. The bit flag value for Never Overwrite is 128 (0x0080). The difference between Never Overwrite and Permanent is Never Overwrite means the component will not be overwritten during installation or reinstallation, but it does not prevent the component from being uninstalled. Use Permanent if you want to prevent components such as your data files from being uninstalled , either during installation of a major upgrade or when the user uninstalls the product manually. If used, the Never Overwrite and Permanent settings should be established beginning with the first release of your product.

Patches

A patch is actually a different kind of entity from either an upgrade or an update. In fact, any of the three types of upgrades and updates described above can be distributed as a patch package instead of as a full setup package. It is customary, however, to use patches only for small updates and minor upgrades.

A patch package is essentially the difference between two full setup packages. Unlike a full setup package, a patch file does not contain all of the information necessary to perform a complete installation of the product. Instead, a patch file contains only the information necessary to transform an existing setup package from one version to a different version. Because of this, patch packages by themselves cannot be used to install a product. Rather, they must be applied to an existing setup package already present on the user ‚ s network or local computer. Patch files have an MSP file extension to differentiate them from ordinary MSI setup files.

One advantage of using patch packages to distribute product updates is patch packages are usually much smaller than full setup packages. One disadvantage of patch packages, however, is that depending on how you construct them you may need a separate patch package for each incremental update to the product. The difference has to do with whether you include a full replacement copy for changed files or whether you include only the different bits. The latter approach results in a smaller patch package, but then that patch only applies to one specific version of the earlier setup.

For example, if you previously deployed versions 1.0, 1.1, and 1.2 of a product and you now want to release version 1.3 as a patch, you may want to create one patch for updating version 1.0 to 1.3, another for 1.1 to 1.3, and another for 1.2 to 1.3. Alternatively, you could create a series of patches, one for each minor version update; this would result in one patch for updating version 1.0 to 1.1, another for 1.1 to 1.2, and a third for 1.2 to 1.3.

The first approach is easier for the end user because they can use whichever patch is appropriate to get to the latest version in one step, but it ‚ s harder on you as the developer because you have to create a geometrically increasing number of patches as new versions of your product are released. The second approach is easier for you as the developer because you only have to create one patch for each new version, but it is more cumbersome for the end user because they may have to apply a series of patches, in the correct order, to update their product across several minor versions.

To create a patch package for your product you need a tool capable of doing so. The Windows Installer SDK contains a pair of files, MSIMSP.EXE and PATCHWIZ.DLL, for this purpose. Your favorite Windows Installer-based setup tool may also provide a way to create patch packages. For example, InstallShield Express 4.0 comes with QuickPatch Technology, a wizard-based tool for creating and managing patch packages. See ‚“Appendix A ‚ How To: InstallShield Express ‚½ for more information on creating patches.

A patch package is stored in a file with an MSP file name extension. The MSP file can be distributed to users, who can then use it to apply the patch to their current installation of the product. Patches can also be created and distributed as an UPDATE.EXE file, which is generally much easier for the user to understand and to install. When created as an UPDATE.EXE, the MSP file is embedded in the executable file much the same way an MSI file is embedded in a single-image SETUP.EXE file.

[5] The Windows Installer SDK documentation is the definitive reference for everything to do with Windows Installer. This documentation, distributed as an HTML Help file named MSI.CHM, is included in the MSDN Library subscription and can be found under Setup and System Administration Setup Windows Installer. It is also distributed as part of the Windows Installer SDK, and available on the Microsoft MSDN Web site at http://msdn.microsoft.com/library/en-us/msi/setup/windows_installer_start_page.asp .

[6] One major limitation of the version of InstallShield Express distributed with Visual FoxPro 7.0 is the ability to create an upgrade path is disabled. The version of InstallShield Express that ships with VFP 8 does not have this limitation.




Deploying Visual FoxPro Solutions
Deploying Visual FoxPro Solutions
ISBN: 1930919328
EAN: 2147483647
Year: 2004
Pages: 232

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net