1.2.3 What is a Patch?

A Patch is used to deliver a set of changes to a software product that has been installed using the Windows Installer. A software product can be upgraded by installing a new Version Installer file or by applying a Patch Installer file.

• A Patch is typically used to apply modified compiled objects, shortcuts and executables.
  You should NOT use a patch to deploy database changes as they are complex to manage and can easily result in a corrupted database, though a Patch Installer file does support this if you understand the risks involved.

• A Patch is identified by its Patch Number.
  The Patch number has a direct relationship to the Version or Patch it was based on, for example Patch 1.0.0.1 would be the first patch against Version 1.0.0.

• To create a Patch, copy a parent Version or Patch.
  In this way the Patch inherits the parent definition including the objects to be deployed.

• When the Patch is built, a full MSI file is built in exactly the same manner as the parent Version or Patch was built.
  The resulting MSI file is compared with the Version's MSI file to produce a difference file – the MSP file. The MSP file may be referred to as a Patch Installer file.

• Note that only the Patch Installer file is installable.
  The interim MSI is deleted once the MSP has been constructed.

The Patch Installer file is a self-contained package that contains updates to the software product and describes which Version can receive this Patch. In many cases it is advisable to service products by delivering a Patch because an Patch Installer file is typically much smaller.

If a patch is only to be used to ship updated objects and there are no new objects, then nothing needs to be changed in the Package Definition. Just save the Package and build it. Any differences between the Version and the current state of objects will be included in the Patch.

A Patch is usually created from the last Patch definition, so that it includes any changes made to the Package Definition, like the addition of new objects.

The order of the application of Patches does not change the installed result. If Patch 1 contains MYFORM.DLL version 1.0.0.1 and Patch 2 contains MYFORM.DLL version 1.0.0.2 then whether Patch 1 is installed first or Patch 2 the result is that MYFORM.DLL version 1.0.0.2 is installed.

Similarly, when a Patch is uninstalled. If Patch 1 is now uninstalled, it will only affect the version of DLLs which it installed. As version 1.0.0.2 is installed, uninstalling Patch 1 will not replace MYFORM.DLL with version 1.0.0.0. It will still be version 1.0.0.2. Only when Patch 2 is then uninstalled will it be restored to version 1.0.0.0.

This may sound neat, but it can become complex to manage if Patches are created that are not cumulative. Each Patch should include all the changes that have come before, or back them out if necessary, and be considered as the ONLY patch required to move the installation to that Patch level. So no matter what Patch level a user has chosen to install, to get to the latest version they just need to install the latest Patch. No interim Patches are required.

Note: By creating patches sequentially from a single build machine and not restoring any objects to a prior state will ensure that Patches are cumulative.

Also see

1.2.2 What is a Version? for information on versioning.