Uninstallable Patches
Whether a patch can be uninstalled depends upon how the patch was authored, the version of Windows Installer used to install the patch, and the changes made by the patch to the application. If a patch is not uninstallable, then the only way to remove the patch is to uninstall the entire application and reinstall without applying the patch being removed.
You can call for the uninstallation of patches applied with Windows Installer version 3.0 by using Command Line Options, the MsiRemovePatches function, or the RemovePatches method as described in the Uninstalling Patches section. The Windows Installer verifies that each of the patches listed for removal in the MSIPATCHREMOVE property is uninstallable. If the user does not have privileges to remove the patch, the patch is unknown for the product, patch policy prevents removal, or the patch was marked as not uninstallable, the installer returns an error indicating a failed installation transaction.
Windows Installer 2.0: Not supported. Patches applied using a version of Windows Installer that is earlier than Windows Installer 3.0 are not uninstallable.
Patches that are Not Uninstallable
A patch (.msp file) applied to an installed application is not uninstallable in the following cases. The only method to remove a patch that is not uninstallable is to uninstall the patched application and then reinstall the application without reapplying the patch. In this case, you must reapply any patches that you do not wish to be removed from the application.
Patches applied using a version of Windows Installer that is less than Windows Installer 3.0 are not uninstallable.
Patches applied to applications installed on a computer that has had the DisablePatchUninstall policy set by an administrator are not uninstallable. When this machine policyhas been set, no patches on the computer can be uninstalled, even by an administrator.
Patches that do not have a MsiPatchMetadata table in their database are not uninstallable.
Patches that do not include the following row in their MsiPatchMetadata table are not uninstallable. The patch is not uninstallable for other values of Company, Property, and Value.
| Company | Property | Value |
|---|---|---|
| AllowRemoval | 1 |
The patch has been applied to an application installed in a context for which the user has insufficient privileges to uninstall patches. The words «Not Allowed» in the following table indicate that an administrator or non-administrator user cannot uninstall patches from patched applications installed in this context. The word «Allowed» in this table means that privileges do not prevent an administrator or non-administrator user from uninstalling patches, however for any of the other reasons discussed in this section, it still might not be possible to uninstall the patch.
| application Installation Context | Administrator Uninstall of Patch | Non-Administrator Uninstall of Patch |
|---|---|---|
| Per-Machine | Allowed | Generally Not Allowed The only exception is if the patch was applied using (LUA) patching. A patch marked as a LUA patch is uninstallable by either administrators or non-administrators. LUA patching is only available for packages installed per-machine from media and require special authoring. |
| Per-User Non-Managed for Current User | Allowed | Allowed |
| Per-User Non-Managed for Different User | Not Allowed | Not Allowed |
| Per-User Managed for Current User | Allowed | Not Allowed |
| Per-User Managed for Different User | Not Allowed | Not Allowed |
A major upgrade applied by a patch is not uninstallable. Major Upgrades of an application should be performed by installing the upgraded application (.msi file) rather than a patch.
Patches applied to an administrative installation are not uninstallable. Patching administrative installations is not recommended. The current set of patches should be applied on the user’s computer after the user installs the application from the administrative image. This can prevent the package code cached on the user’s computer from becoming different than the package code on the administrative installation. If the package code cached on the user’s computer becomes different from that on the administrative installation, reinstall the application from the administrative installation and then patch the client computer.
When a patch adds new content to any of the tables in the following list, Windows Installer marks the patch as being not uninstallable. An uninstallable patch can add new files, assemblies, registry entries, components, or features to an installation by adding new rows to database tables that are not included in this list.
Patching and Upgrades
Because an installation package can contain the files that make up an application as well the information needed for their installation, Windows Installer can be used to update the application. The installer can update information in the following parts of the installation package:
- The .msi file.
- The files of the application.
- The Windows Installer registration information.
The type of update can be characterized by the changes the update makes to the application’s product code, product version, and package code. The application’s product version is stored in the ProductVersion property. The application’s product code is stored in the ProductCode property. The application’s package code is stored in the Revision Number Summary Property.
An update that changes the application into another product is required to change the ProductCode of the application. For more information about which updates require changing the ProductCode see Changing the Product Code. The update can change the ProductVersion and leave the ProductCode unchanged if future versions of the application will need to differentiate between the updated and nonupdated versions of the current product. The Package Code uniquely identifies the installation package and should always be changed whenever update or upgrade changes any information in the installation package.
When deciding whether to change the product version, you should consider If future versions of the application will need to differentiate between the updated and nonupdated versions of the current product. To ensure differentiation in the future, a minor upgrade should be used instead of a small update.
- If an update changes the .msi file and application files, but does not change the ProductCode property or ProductVersion property, it is termed a small update.
- If the update changes the ProductVersion, but does not change the ProductCode, it is termed a minor upgrade.
- If the update changes the installation into an entirely different product, the ProductCode must change and the update is termed a major upgrade.
To ensure differentiation of versions of the current product in the future, a minor upgrade should be used instead of a small update.
The following table summarizes the different types of updates.
| Type of update | Productcode | ProductVersion | Description |
|---|---|---|---|
| Small Update | No change | No change | An update to one or two files that is too small to warrant changing the ProductVersion. The package code in the Revision Number Summary Property does change. Can be shipped as a full installation package or as a patch package. |
| Minor Upgrade | No change | Changed | A small update making changes significant enough to warrant changing the ProductVersion property. Can be shipped as a full installation package or as a patch package. |
| Major Upgrades | Changed | Changed | A comprehensive update of the product warranting a change in the ProductCode property. Shipped as a patch package or as a full product installation package. |
The Windows Installer can install an application, or an update, for all users of a computer (per-machine context) or for a particular user (per-user context) depending on the access privileges of the user, the value of the ALLUSERS property, and the version of the operating system. Application developers should consider in which context updates will be installed. If the contexts of the application and update are different, the application may not be updated as expected.
Users can update to an application by reinstalling a Windows Installer package for the application. Note that Minor Upgrades can be applied in the same way as Small Updates. For more information about updating an application by reinstalling the application, see these sections:
An update to an application can be provided to users as a Windows Installer patch package. A patch can contain an entire file or only the file bits necessary to update part of a file. This means that the user can download an upgrade patch that is much smaller than the entire product and that preserves user customizations through the upgrade. Note that Minor Upgrades can be applied in the same way as Small Updates. For more information about updating an application using a patch, see these sections:
Sequencing Patches
Beginning with Windows Installer 3.0, authors can add patch sequencing information to the patch package database in the MsiPatchSequence table. The installer can use this information to determine which patches are applicable to an installation package, to determine the best patching sequence, and to install patches in an constant order independent of the order they are provided to the system.
Windows Installer 2.0: Not supported. Windows Installer versions previous to Windows Installer 3.0 install patches in the order that they are provided to the system regardless of whether they contain an MsiPatchSequence table.
The following are required to use the patch sequencing functionality.
- Patch packages (.msp files) must have a MsiPatchSequence table containing sequencing information. The installer installs patches that do not have a MsiPatchSequence table in the order that they are provided to the system.
- Patches are installed using Windows Installer 3.0 or later.
Windows Installer version 3.0 has the following functions that applications can use to determine the best patching sequence.
- The MsiDeterminePatchSequence function takes a list of patches and determines in what sequence they can be applied to an installed product. This function accounts for any patches or products that have already been installed on the system.
- The MsiDetermineApplicablePatches function takes a list of patches and determines in what sequence they can be applied to an installed product. This function does not account for any patches or products that have already been installed on the system.
Windows Installer version 3.0 can apply multiple patches to a product in a single patching installation. The group of patches can contain patches that include patching sequence information (a MsiPatchSequence table) and patches that do not. The Windows Installer installs the patch packages without this table in the order that they are provided to the system. The installer accounts for patch packages that lack a MsiPatchSequence table, but that have been marked as obsolete or superseded patches by the method described in the following section.
When Windows Installer version 3.0 installs multiple patches, it follows these steps to determine the sequence in which individual patches are applied to the product:
Installed patches without a MsiPatchSequence table are put in the sequence in the order that they were applied to the product. The first patch that was applied is placed first in the sequence.
New patches without a MsiPatchSequence table are put in the sequence. These patches are being applied by the current patching installation. They are put in the order that they are provided to the system, and placed after all the patches in step 1.
Obsolete patches are eliminated from the sequence of patches.
A patch package can specify in the Revision Number Summary property an explicit list of obsolete patches to be removed by the patch. This list is intended for use by Windows Installer versions earlier than version 3.0. Windows Installer version 3.0 removes the patches marked as obsolete from the sequence, only if the patches do not have the MsiPatchSequence table.
The installer steps through the patching sequence and determines which patches are applicable in the given sequence. When multiple patches are applied to a product, each patch in the sequence also transforms the product’s installation database (.msi file). A patch is applicable in a particular sequence only if its database transform is capable of taking the product code, version, language, and upgradecode that result from applying the transforms of all preceding patch packages to the product database. The installer eliminates any inapplicable patches from the sequence.
The installer begins placing patches that have sequencing information in their MsiPatchSequence table. Minor upgrade patches that have the MsiPatchSequence table are placed in the sequence after the patches that were sequenced in previous steps and in the order of their lowest to highest product versions after being upgraded. Windows Installer then eliminates any minor upgrade patches that are inapplicable in this sequence.
Small update patches targeting minor upgrades having a MsiPatchSequence table, are assigned to the highest version of the minor upgrade patch in the sequence.
All small update patches that remain unassigned after the previous steps, and that have the MsiPatchSequence table, are put in the sequence before the first minor upgrade that has the MsiPatchSequence table, and after the .msi installation database and any patches without the MsiPatchSequence table. Windows Installer then eliminates any small update patches that are inapplicable in this sequence.
Windows Installer version 3.0 eliminates superseded patches from the sequence. When a patch supersedes patches that occur earlier in the patch sequence, the patch contains all the fixes in the earlier patches. The earlier patches are no longer required. The Windows Installer requires the information in the MsiPatchSequence table to eliminate superseded patches.
Patches intended to supersede an earlier set of patches must be authored to supersede the earlier patches in all patch families. Small update patches can only supersede small updates. Minor upgrades can supersede both small updates and other minor upgrades.
Small update patches that carry MsiPatchSequence tables, get sequenced within product versions according to the sequencing information in their MsiPatchSequence tables. This determines the final patching sequence.
A patch that should no longer be used can be eliminated from the patching sequence. For more information about how to eliminate patches from the patching sequence, see Eliminating Patches.
For an example of how the MsiPatchSequence table can be used to apply patches in the order in which they are authored, see the Multiple Patching Example.
