“last-write-wins” patch sequencing behavior of MSI 2.0 has changed for MSI 3.0

  • Article

With MSI 2.0, there was no ordering of patches other than the chronological order in which patches are received. In MSI 3.0, the engine enforces the logical ordering of patches as defined by the MsiPatchSequence Table [Windows Installer]. 

Let’s say for example you have a package with a Custom Action Type 51 [Windows Installer] SetKBName which sets a property called KBName to the value in the Target column. Now let’s say for patch 102, the CustomAction.Target value is "[Update](KB222222)" and for patch 104, the CustomAction.Target value is "[Update](KB111111)".

The order of application of the updates within a transform in a patch is based upon the order of application of the patches. In MSI 2.0, that's chronological order. In MSI 3.0, that's logical order. If you install the patches as 104 and then 102, you see the following:

MSI 2.0 Engine (chronological order)
Update for SetKBName for 104 patch occurs, altering the CustomAction.Target value to [Update](KB111111).
Update for SetKBName for 102 patch occurs, altering the CustomAction.Target value to [Update](KB222222)

MSI 3.0 Engine (logical order)
Regardless of the fact that 102 is applied last, it's still sequenced first since the MsiPatchSequence table says that's where it should be sequenced.
Update for SetKBName for 102 patch occurs, altering the CustomAction.Target value to [Update](KB222222)
Update for SetKBName for 104 patch occurs, altering the CustomAction.Target value to [Update](KB111111)

(Disclosure: this content is gleaned from the internal Microsoft Setup Authoring community. It struck me as so interesting; I thought it worth posting for folks outside Microsoft.)