Easier Authoring for Slipstreaming Patches

Slipstreaming Windows Installer patches is, technically, installing the MSP simultaneously with the MSI as a single transaction. This is, effectively:

msiexec /i D:\product.msi PATCH=D:\patch.msp

The applicable transforms (both the authoring changes and patch transforms) are applied to the MSI and the MSI is installed with those changes from the start. Both the MSI and MSP are cached in the Windows Installer cache. The slipstreamed MSP(s) can even be removed later if desired (unlike admin patching).

WiX v3.6 has supported this for a while in the Burn engine using the following fragment:

<PackageGroup Id="Product">
  <MsiPackage Id="Product" Name="packages\product.msi">
    <SlipstreamMsp Id="Patch"/>
  MsiPackage>
  <MspPackage Name="packages\patch.msp"/>
PackageGroup>

The problem with this syntax as your bundle grows in scale is that you need to determine which MSP(s) target which MSI(s). You also need to go back and modify any existing PackageGroups or the Chain for RTM to add all the SlipstreamMsp elements in addition to your MspPackage elements. This task may not be trivial and requires the developer to do a lot of extra work.

We recently added support to make this easier by figuring all this out at build time using the following fragment:

<PackageGroup Id="Product">
  <MsiPackage Id="Product" Name="packages\product.msi"/>
  <MspPackage Id="Patch" Name="packages\patch.msp"/>
PackageGroup>

By setting the new MspPackage/@Slipstream attribute to “yes” you can let WiX figure out which MSP(s) to slipstream with which MSI(s). This allows developers to simply add MspPackages to the end of the chain (or anywhere, really) while still providing for explicit control if, for some reason, you didn’t want an applicable MSP to slipstream with a particular MSI (not recommend).

Also note that patches that are slipstreamed to products within the bundle will still automatically be applied to products that are already installed. This includes the products in the bundle, but also any other products to which the patch applies. This behavior is not optional in bundle authoring, but if for some reason the setup developer wants to avoid that, either remove the would-be target products from the patch authoring before building or override the plan to apply those patches in the bootstrapper application (BA) implementation.