Windows Installer Upgrades
As a Windows Installer installation routine is a database technology, upgrading in installed version of a product (or patching that product) is theoretically simple and reliable. The technology has its own rules regarding upgrades which must be follows for the upgrade to occur.
- A later version of a particular product will upgrade an earlier version if it is present on a machine.
- Delta files (a file containing the differences between two products) can also be created and deployed instead of just deploying the later version. These files are created by comparing the two versions of a particular product.
Software developers who are producing packages for external release will want to spend a considerable amount of time in testing upgrade procedures between versions of products.
Why Upgrading is a problem within an organisation
Note that this was written nearly a decade ago when many organisations were experimenting with MSI upgrade concepts. I am no longer aware of any major organisations still following this approach. The accepted wisdom is now to uninstall older versions of products and install new versions cleanly! ... Ed.
Adopting an upgrade philosophy within a corporate organisation:
- Increases complexity of developed packages
- Increases the amount of manual labour required with each package
- Increases failures with vendor supplied installations
- Multiplies testing time for every version upgrade scenario that exists for both packaging and testing teams.
- Increases the chances of clean installations differing from upgraded installations in the enterprise.
A number of organisations view the ability of MSI packages to upgrade previous installations as a business advantage as it reduced deployment time of an install. The vast majority of organisations now schedule software deployments to occur at night so normal business activity is not negatively affected so I am far from convinced on the rationale of this business benefit.
My own experience suggests that organisations that utilise upgrades require packaging teams three times larger than organisations that do not. An organisation supporting 5000 staff can be serviced by a packaging team of three when policy dictates the complete removal of previous versions of a package and all testing on clean machines. A comparable organisation using upgrades seems to have packaging teams with around nine staff members.
Virtually all testing occurs with clean machines. The potential problems that affect upgrades will occur on dirty machines in production. For my way of thinking, increasing the chances of application failure in production environments is an unacceptable risk, especially when the business advantage for that risk is difficult to quantify.
Windows Installer Package rules
Applications are uniquely identified by two entries from their Property table. These are the Package Code and Product Code entries. Both entries are unique GUIDs.
- A Package Code is unique to a particular package. Every new package should have a new Package Code.
- A Product Code could consistent throughout all separate versions of a particular product, in practice though Product Codes are generally changed between releases due to issues with upgrading when the codes are retained..
Before Windows Installer installs a new MSI, it will first check on a target workstation to see if an application with the same Package Code and Product Code exists. It a package with the same Product code exists, it may be possible to do an upgrade of your previous package so a further GUID known as the upgrade code is consulted.
To keep packaging simple, our deployment rules state that old versions of applications will be removed before a newer version is installed. Patching and upgrades represents a massive increase in complexity that should be avoided unless absolutely necessary.
The important piece of information is to remember to that Package code should be unique for every application we repackage.
Windows Installer will assess package versions based on three of four version segments based on the ProductVersion filed in the property table. The valid format of these version fields is as follows:
00.00.00000.00000
When shortened versions are referred to such as 1.1.3, remember to always pad out the numeric values with zeros from the left to see the value the same way that Windows Installer will. With the example just mentioned, the official version will be seen as 01.01.00000. The remaining four character segment of the version field is not functionally used by the installer and is purely for internal differentiation of builds.
Windows Installer File Version rules
Windows Installer maintains its own rules when installing files onto target workstations. The file table of the MSI contains version information that determines how a file is handled.
When the installer considers replacing an existing file the logic that determines the possibility of file replacement is:
- The highest versioned file wins
- A file with a version will replace a file with no version
- A file with no version will not replace another file without a version because they would be classed as “data” files.
Upgrading an Existing Package
As we have discussed, a Windows Installer package consists of at least one Feature and multiple Components. Each of those components will generally hold files, shortcuts, INI entries and everything else physically installed.
Product: MyApp
Version: 1.0
|
Feature |
Component1 |
FileA |
|
|
Component2 |
FileB |
|
|
Component3 |
FileC |
|
|
Component4 |
FileD |
Windows Installer doesn’t care what names we have put on our features or components, when the technology evaluates what is installed it uses the unique GUID identifiers for determining that a particular component is already installed. Because the GUID of every component installed on a machine is written to the registry, the technology will be able to determine if an upgrade has introduced new components that aren’t already present.
The technology will also be able to use file versioning rules to determine if a file installed as part of an earlier component has been upgraded.
Windows Installer will view the Application package in the following way:
Product: ProductName
Version: Version
|
Feature |
{GUID} |
File |
|
|
{GUID} |
File |
|
|
{GUID} |
File |
|
|
{GUID} |
File |
When an updated package is created, the only time an existing Component is altered is if a file within that component is being upgraded with a different file of the same name. In this scenario, file versioning rules will affect the replacement of this file on another machine. In any other scenario, a new file or resource must be added to a new component of its own.
Product: MyApp
Version: 1.1
|
Feature |
Component1 |
FileA |
|
|
Component2 |
FileB |
|
|
Component3 |
FileC |
|
|
Component4 |
FileD |
|
New component -> |
Component5 |
FileE |
Note that the Feature name must remain the same between releases of the product!
Upgrade Code
Windows Installer will utilise PackageCode and ProductCode GUID’s to determine any relationship between packages. As a recap:
- ProductCode is unique to a Product and spans multiple versions
- PackageCode is unique to every Windows Installer Package created
Windows Installer can tell when two MSI’s have the same ProductCode that they are from the same suite. It can also tell based on the Version property which package represents that later version of the product. The technology will also utilise the Upgrade Code property to see if a product may be upgraded
By convention, when a product has multiple releases, minor releases that can be upgraded will share the same upgrade code.
When future versions of the product discover that an earlier package with the same ProductCode and version exist on a machine, the Upgrade table in the later version of the product will be consulted to see if the exiting install can be upgraded.
The Image above is a representation of the Upgrade table for Acrobat Reader. The UpgradeCode field contains the upgrade codes that were published with earlier versions of the product.
RemoveExistingProducts
Upgrades work on target platforms due to the standard MSI action RemoveExistingProducts. If an upgrade occurs, this action will remove earlier installations of that particular product from a machine
Installshield approach upgrades in a completely different way to Microsoft and Wise. The approach is determined by the InstallExecute sequence.
The way Windows Installer was originally intended to work (and used by Wise) is based on the fact that every component has a unique GUID. When an upgrade is available, there is no need to uninstall everything - especially if the update only involves upgrading or adding a couple of files. Windows Installer is able to evaluate what new components need to be added when a new package from a Product family is installed. Windows Installer reconciles the differences so any "patching" of the installed version occurs & the last thing it does is then remove unwanted & orphaned components from the previous version of the product.
Because all the evaluation and reconciliation has to occur before any components or features are removed, if any existing components are to be left on the machine, the RemoveExistingProducts entry must be last in the InstallExecute sequence. This is what MSI templates from the Windows Installer Resource Kits and Wise do.
Installshield has the RemoveExistingProducts before installinitialize. The advantage is that you don’t really need to follow the Windows Installer Upgrade rules properly because any existing version will be stripped off a machine before the "upgraded" version's install occurs. The problem with this approach is that if something goes wrong during the install of the later package, rollback can't put the earlier package back on the machine. The whole benefit of rollback to an organisation is lost if the RemoveExistingProducts action is at the start of the InstallExecute sequence.
Additional problems can occur when the RemoveExistingProducts action is placed at the start of the installation sequence. http://support.microsoft.com/kb/905238
Generally, packaging for the enterprise environment doesn’t involve dealing with Upgrades as scripts are normally run to ensure that no existing installation of a Product exists on a machine when a new release is being deployed. Getting upgrades to work takes a lot of time and analysis when the benefits for most places are minimal.
When to change Package, Product and Upgrades Codes
The official concept of upgrades can be represented with the following table
|
Update |
Productcode |
ProductVersion |
Description |
|
Small Update |
No change |
Changed |
An update to one or two files that is too small to warrant changing the Major or Minor ProductVersion fields. |
|
Minor Upgrade |
No change |
Changed |
A small update making changes significant enough to warrant changing the Minor ProductVersion section of the ProductVersion property. |
|
Major Upgrades |
Changed |
Changed |
A major update of the product that involves changes in the Feature Tables of the package. This alters the major |
Note: The Instllshield approach was to always change Productcodes with each software release!
Upgrading Installed MSI’s – Syntax
When deploying a newer versioned MSI over the top of an existing installation, two properties must be set otherwise an error is produced such as the one below:
These Properties are:
REINSTALL=ALL
REINSTALLMODE=voums
The “v” in the Reinstallmode property tells Windows Installer to update the machine using the new MSI database instead of the cached copy.
The syntax of an upgrade command would be:
MsiExec.exe /I project.msi REINSTALLMODE=voums REINSTALL=ALL
- Log in to post comments