MSI Upgrade Mechanism

In windows Installer technology there is also support for upgrading applications (MSI). Upgrading an application means removal of old application from the target machine and installation of the new application. the upgrade is performed by enforcing several rules at Component level.

Package Attributes use to determine types of Upgrade

• Package Code
• Product Version
• Product Code

Upgrade Types

All updates require changing of the Package Code.

Small Update

A small update is typically a small number of files; a small update cannot rearrange the feature component structure.

Minor Update

A minor update can add files and features however cannot manipulate the current feature/component structure. A minor update also requires the Product Version property to be changed. Minor updates can be shipped as full product installers or MSP patch files.

Major Update

A major update can add files / features and also manipulate the feature component tree. The major upgrade requires that new ProductCode, PackageCode, and ProductVersion’s are set.

The following table summarizes the changes required for each update type.

Update Type   Package Code       Product Version     Product Code

  Small              Change
  Minor             Change                    Change
  Major             Change                    Change                   Change

The different upgrade types are controlled by below Windows Installer Standard actions.

FindRelatedProducts Action

The FindRelatedProducts action runs through each record of the Upgrade table in sequence and compares the upgrade code, product version, and language in each row to products installed on the system. When FindRelatedProducts detects a correspondence between the upgrade information and an installed product, it appends the product code to the property specified in the ActionProperty column of the UpgradeTable.

The FindRelatedProducts action only runs the first time the product is installed. The FindRelatedProducts action does not run during maintenance mode or uninstallation.

This action queries the following table Upgrade Table.

The FindRelatedProducts action uses the UpgradeCode property and the version and language information authored into the Upgrade table to detect installed products affected by the pending upgrade. It appends the product code of detected products to the property in the ActionProperty column of the UpgradeTable.

FindRelatedProducts only recognizes existing products that have been installed using the Windows Installer with an .msi that defines an UpgradeCode property, a ProductVersion property, and a value for the ProductLanguage property that is one of the languages listed in the Template Summary Property.

Sequence Restrictions:

The FindRelatedProducts action must come before the MigrateFeatureStates action and the RemoveExistingProducts action.

MigrateFeatureStates Action

The MigrateFeatureStates action is used during upgrading and when installing a new application over a related application. MigrateFeatureStates reads the feature states in the existing application and then sets these feature states in the pending installation. The method is only useful when the new feature tree has not greatly changed from the original.

The MigrateFeatureStates action only runs the first time the product is installed. The MigrateFeatureStates action does not run during maintenance mode or uninstallation.

MigrateFeatureStates action runs through each record of the Upgrade table in sequence and compares the upgrade code, product version, and language in each row to all products installed on the system. If MigrateFeatureStates action detects a correspondence, and if the msidbUpgradeAttributesMigrateFeatures bit flag is set in the Attributes column of the Upgrade table, the installer queries the existing feature states for the product and sets these states for the same features in the new application. The action only migrates the feature states if the Preselected property is not set.

Sequence Restrictions:

The MigrateFeatureStates action should come immediately after the CostFinalize action. MigrateFeatureStates must be sequenced in both the InstallUISequence table and the InstallExecuteSequence table.

The installer prevents MigrateFeatureStates from running in InstallExecuteSequence if the action has already run in InstallUISequence.

RemoveExistingProducts Action

The RemoveExistingProducts action goes through the product codes listed in the ActionProperty column of the Upgrade table and removes the products in sequence by invoking concurrent installations. For each concurrent installation the installer sets the ProductCode property to the product code and sets the REMOVE property to the value in the Remove field of the Upgrade table. If the Remove field is blank, its value defaults to ALL and the installer removes the entire product.

The installer only runs the RemoveExistingProducts action the first time it installs a product. It does not run the action during a maintenance installation or uninstallation.

Sequence Restrictions:

·        Between the InstallValidate action and the InstallInitialize action. In this case, the installer removes the old applications entirely before installing the new applications. This is an inefficient placement for the action because all reused files have to be recopied.

·        After the InstallInitialize action and before any actions that generate execution script.

·        Between the InstallExecute action, or the InstallExecuteAgain action, and the InstallFinalize action. Generally the last three actions are scheduled right after one another: InstallExecute, RemoveExistingProducts, and InstallFinalize. In this case the updated files are installed first and then the old files are removed. However, if the removal of the old application fails, then the installer rolls back both the removal of the old application and the install of the new application.