...

Building Installation packages

Setting the context

The variables which control file version names, source directories, product versions and the like are all stored in a file called Versions.wxi

On the other hand if a file name remains unchanged, but the contents differ then you should be aware of the file version rules (link not added since msdn links they rot; Google for "file version rules site:microsoft.com"). Basically if the new contents have a more recent version then they will be updated, if the version goes backwards then it won't.

If you are preparing a new release package you must give the new package a new product id. These are found in the files ShibbolethSP-main-x64.wxs and ShibbolethSP-main-x86.wxs.

Building the merge modules

The sources for all the merge modules are contained in the msi\Wix\MergeModules directory and is compiled using the compile.bat command.

Building the Installers

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

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.