InstallShield Upgrade Strategy

Quite a concern with customers is what strategy should they follow when delivering future updates to their application. The confusion as to what to delivery (Small Updates, Minor Updates, Major Upgrades, Patches) leaves the customer paralyzed with indecision. Couple that with having a part-time InstallShield developer (or consultant), and you will need to evaluate a strategy that blends reliability with ease in creating and QA testing an upgrade.

In this post, I would like to outline a roadmap for your Upgrade Strategy, giving both Pros and Cons as well as realistic guidance that experience has provided.

Packaging Options

First, let’s discuss the various packaging options that are available to you.

• Each upgrade can be packaged for delivery as a full MSI installation which can offer existing clients a method to deliver just the updated files, or a full replacement of the original package. The advantage of creating a full MSI installation is that it can be delivered to new customers and they will be able to install and configure as easily as the original installation.
• An upgrade can be packaged as a Windows Installer patch file that offers existing customers a smaller footprint, and will apply binary file differences that will upgrade a file from the previous version to the newer version. The effort to create this is relatively simple, but must be tested as much as a full upgrade package. In addition it can only deliver updates to existing customers after a full installation – a new customer cannot install a Patch package and have a working program.

Windows Installer GUID Codes

The GUID Codes associated with each InstallShield package play a major role in how Windows Installer determines whether the package being installed is considered a new installation, or an update that is being handled as a Major or Minor upgrade.

• Package Code – must change for each build. Pretty much ignored for your requirements.
• Product Version – MSI Property – Only 1^st three fields used by Windows Installer for version comparisons (Build # ignored)
• Product Code– MSI Property – GUID of product. If two packages with same name have different ProductCode’s, MSI treats both packages as different!
• Upgrade Code – MSI Property holds GUID of family of products – used for patching purposes. Essentially never change for life of application!

 

Here is a matrix that graphically displays when each GUID should be changed:

Now, let’s discuss the various vehicles that InstallShield provides to deliver updates to your customer.

Small Update

This type of update is characterized by just some simple product changes – so small in scope that you don’t alter the Product Version number. Some requirements you must adhere to when preparing the installation to be delivered as a Small Update:

• Can add a new component to an existing feature
• Can add a new component to a new feature
• Can add new sub-feature with new components
• Cannot change MSI Package name
• Cannot move or delete a feature
• Cannot move/delete component
• Cannot change Component GUID
• Cannot change the Key file of a component

In practice, delivering a new full MSI Package without changing the Product Version ensures you will have no means to track which customer has received this package. Granted the Package Code will always be regenerated, but that is not easy for the customer to determine. Realistically this might be a method to rebuild the package while it’s in the QA stages – I just don’t see a practical use for delivery to customers.

Minor Upgrade

This is the typical solution that most developers deliver to their customer base. Characterized by a full rebuild of the package with the Product Version changing (goes from version 2.1.3.xx to 2.2.0.xx), it most often will contain newly compiled binary files that resolve a customer reported defect. When the new customer receives this package, a full installation will occur with all of the User Dialogs presented with version 2.2.0.xx installed.

When an existing customer (v2.1.3.xx) receives this package, they will see a small dialog asking “Do you want to upgrade the application? Y/N) – and then they would just see the progress bar as the updated binaries are applied. Note that no User Dialogs will appear, the same destination drive/directory are maintained, plus any features selected within original installation are preserved with no ability to change.

A patch can be created that provides a method to deliver the Minor Update changes in a smaller footprint versus delivering a full MSI package.

Note that it is critical that you have followed “Best Practices” when creating the components – and key files are set for all versioned binary files. If you keep all of the non-versioned files in a component, it would be recommended that you select a versioned file as the Key file of the component.

Some requirements you must adhere to when preparing the installation to be delivered as a Minor Upgrade:

• Can add a new component to an existing feature
• Can add a new component to a new feature
• Can add new sub-feature with new components
• Cannot change MSI Package name
• Cannot move or delete a feature
• Cannot move/delete component
• Cannot change Component GUID
• Cannot change the Key file of a component

 

Major Upgrade

This is the method by which developers introduce a significant change to the application, which would require the user to completely uninstall the original application and then the new application is installed. With the authoring of a Major Upgrade entry, this process is accomplished seamlessly when the new installation is executed by an existing customer.

Most importantly, you decide when a new release qualifies as a Major Upgrade, for example version 2.2.0.xx to 3.0.0.xx might qualify, but you may want to have 2.2.0.xx to 2.3.0.xx be handled as a Major Upgrade, especially if a new feature is introduced and you want the customer to be able to choose it during installation.

Some requirements you must adhere to when preparing the installation to be delivered as a Major Upgrade:

• Can add a new component to an existing feature
• Can add a new component to a new feature
• Can add new sub-feature with new components
• Can change MSI Package name
• Can move or delete a feature
• Can move/delete component
• Can change Component GUID
• Can change the Key file of a component

As you can see, it’s pretty flexible since the original installation is being removed you have free rein in doing anything you want with Features and Components.

You can specify the behavior of how the Major Update is applied, you have the following choices:

1. Completely remove the original application, registry entries, and files, then install the new application. Note that none of the original files are preserved or backed up during the process.
2. Overwrite the original application, then weed out obsolete files as necessary.

Realistically, I always choose option #1, because it offers the customer the flexibility of choosing a different drive and destination folder.

 

Considerations

Here are the Pros and Cons that I am aware of with each upgrade approach ( I am ignoring Small Updates completely):

Minor Update

Pros

• Works consistently when a versioned binary files has newer version number (matches InstallShield product version).
• Allows you to create small “Patches/Updates” from this new MSI package.
• Process is typically “built” into an installation, requiring overt entries to the Upgrade table. Accomplished simply by altering the Version number.
• Can use Patch process to deliver changes in a smaller footprint

Cons

• No user dialogs presented, so customer has to live with the original drive and directory.
• If package delivers a registry entry, which is modified by InstallScript Custom Actions – or during the user dialogs, this may not be done during Minor Update, consequently you might have empty variables in the registry after the update. Modifying the REINSTALLMODE properties can prevent the registry from being rewritten. Creating a new Custom Action that runs with Condition=Installed will also work towards resolving this issue.
• Application files that are configured by the customer during application execution should be preserved – but you have to watch to ensure they are not overwritten by the template within the CAB files. Sometimes a InstallScript Custom Action that preserves the user configuration files before the Upgrade process and then another to restore it after the Upgrade process is necessary.
• Delivering new non-versioned files (XML, INI, CFG, etc) may not be delivered consistently (Refer to link regarding File Versioning rules). Only alternative to ensure new non-versioned files are consistently delivered are to modify the REINSTALLMODE properties to force all files to be delivered (overkill at best), or create an InstallScript Custom Action before the update step to delete the critical non-versioned files to ensure that they are always delivered.
• Cannot make significant changes to organization of the package (for example, restructure the Features)

 

 

Major Update

Pros

• Allows unlimited reorganization of Features and Components – essentially a vastly different package than the original one
• Allows you the ability to wipe out troublesome packages that were originally delivered that are not easy to properly apply updates to.
• Full user dialogs presented, allows existing customers to choose different Features, specify a different drive or destination folder
• Removes existing product silently at beginning
• To denote a Major Update, you must:
  • Regenerate the Product Code GUID
  • Change the Version Number
  • Author a Major Upgrade entry in the Updates table

   

  Notes:

1. to run a Custom Action during uninstall of Original Product, use condition “Remove=”ALL” not “UPGRADINGPRODUCTCODE”
2. To run a Custom Action during upgrade, use condition “UPGRADINGPRODUCTCODE

Cons

• Must be mindful that the uninstall may not completely remove all or the original installation, which could pose problems for the new installatino

 

Recommendations

These recommendations are based on years of providing consulting services to small development shops that don’t have a Full Time Dedicated InstallShield Developer. Consequently, your upgrade strategy should focus on creating Upgrade packages that are:

• easy for the customer to apply and relatively Bulletproof so that valuable hours are not wasted dealing with customer upgrade issues.
• Able to consistently build with repeatable results
• QA can handle the iterative testing to ensure files are delivered correctly in all scenarios

 

1. Small Update – don’t even think of them in a customer environment!
2. Realize that creating Minor Upgrades will require extensive InstallShield package testing and particular attention to the treatment of non-versioned files. Don’t create a Minor Update unless you are going to devote the testing to ensure all files correctly updated.
3. Patches require extensive testing, far beyond their worth in the field – which is mainly a smaller download size. I would just create Minor Updates, test correctly and release this to both existing and new customers.
4. If you have no user configured data to be concerned with, then I recommend that you consider every release a Major Upgrade. It removes the requirement to ensure non-versioned files are correctly, and you are sure everyone is correctly updated at the end. If you don’t have a dedicated InstallShield developer, or limited QA testing time this is the way to go.

   As far as the treatment of user configuration data/files goes, if you put in the System Search and/or InstallScript Custom Actions, and they are proven to work correctly – then releasing a Major Upgrade becomes quite straightforward and easy to manage for future releases.

    

Hope this helps!

ShieldMaster

Advertisement