...
| Note |
|---|
You need to have WiX installed and the executables for the tools on your path. In addition in order to build a patch you need the platform SDK installed. |
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
| Note |
|---|
If a file name changes you must change the associated component IDs. There will often be two component IDs (one for 32 bits and one for 64 bits). Failure to do this will mean that upgrades will fail. |
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
...
- 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 /qbofCurrent.msiinto a known directory (specified using theTARGETDIRproperty. - Similarly do an administrative install of {{
Updated.msi}}into into another known directory. - Edit the file called
patch.wxsto point to the msi files contained within these two directories - Compile this
candle patch.wxslight patch.wixobj -out patch.pcp
- Run
MsiMsp{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
...