...

The sources for modules which make up the installers are contained in the msi\Wix directory and are compiled and linked using the compile.bat command.

Building Patches

This uses exactly the technology described in..Patches will usually only be needed if a merge module has changed (since a change to a Shibboleth component will usually engender a new version and hence a new installer). Because of some issues about patches and merge modules it has not proved possible (don't ask why) to use purely Wix.

Hence we need to patch using patch creation properties. This seems daunting in the referenced web page but isn't. See the page for details but the gist is that one does an administrative install the old and the new. One then prepares (via a WiX file) a file which describes these two directories. You then run a Microsoft program which takes this file and generates a patch.

• Assume the current msi is called Current.msi. Save this somewhere
• Rebuild whatever is needed, rebuild the merge modules and hence the installers. Lets us call the new msi Updated.msi
• Do an administrative install (msiexec /a /qb of Current.msi into a known directory (specified using the TARGETDIR property.
• Similarly do an administrative install of {{Updated.msi}}into another known directory.
• Edit the file called patch.wxs to point to the msi files contained within these two directories
• Compile this
  • candle patch.wxs
  • light patch.wixobj -out patch.pcp
• Run MsiMsp{ (available in the platform SDK)
  • (("\Program Files\Microsoft SDKs\Windows\v7.1\Bin\MsiMsp.Exe" -s patch.pcp -p patch.msp -l patch.log
• Install the update via msiexec /p patch.msp

File Versions

It appears that the version rules are followed when patches are applied. However I have noticed that a file whose version differs only in the fourth number will be replaced. So a patch from version 1.5.0.0 -> 1.4.99.0 is not be applied but one from 1.5.0.0 to 1.5.0.1 is.