The Phoenix lander found water ice on Mars. That’s cool, but even cooler (from a terribly geeky setup perspective) is the Phoenix team’s need to service the software running on the lander:

The confirming discovery came despite some technical glitches, including an incident with Phoenix’s onboard filing and data storage system that caused the lander to produce thousands of duplicate copies of file-maintenance data files and clog things up. The software issue was promptly diagnosed and should be "patched" no later than Tuesday, according to Barry Goldstein, Phoenix project manager, of the Jet Propulsion Laboratory (JPL).

More details here. Imagine installing a patch from 171,410,657 miles away (plus or minus). I hope there are no prompts for source…

Posted in Agility at June 21st, 2008. No Comments.

Burn is the name of the new WiX chainer. (Burn is brought to you by the letter B, which stands for bootstrapper.) Though we’re working to ship WiX v3 without Burn, work on Burn continues — it turns out that several members of the WiX virtual team need a chainer for their day jobs. As I’m one of them, I thought I’d blog about the work I’m doing. To start that, this post covers the layers in Burn and how they fit together:

  • Core: The Burn core is where the actual chaining and installation code lives. This is, not surprisingly, the biggest chunk of code in Burn, with several thousand lines of code. The core supports installing .msi and .exe packages, with .msp patch package support planned. The core is a static library.
  • UX: UX, which stands for User eXperience, handles user interface. Burn includes StdUx, which provides a basic UI. StdUx can be replaced by any DLL that adheres to the Burn UX interface.
  • Stub: The Burn stub is an .exe that handles standard command-line processing and startup. It loads the manifest, UX DLL, and packages — any of which might be embedded in the .exe — and lets the UX take over.
  • BurnExe: BurnExe is the manifest compiler and bundle builder. The package manifest is an XML file that specifies the list of packages to be installed; BurnExe resolves references to packages and extracts metadata like the product code and product version. BurnExe also optionally builds a bundle — a copy of a stub with embedded data. For example, right now, BurnExe supports embedding the resolved manifest so setup.exe can be signed to help ensure the manifest hasn’t been tampered with. The plan is to also support embedding the UX DLL and packages to provide a single setup.exe download.

Any layer of Burn can be replaced. For example, I expect someone on my team to create a custom UX for Train Simulator 2. The Burn design focuses customizability in the UX so the other layers can be used as-is.

There’s plenty more work to do, so that’s it for today. More to come as more of Burn matures!

Posted in Burn, WiX at June 21st, 2008. No Comments.

WiX v3.0.4220.0 was released on Friday, 20-June-08. You can download it from http://wix.sourceforge.net/releases/3.0.4220.0/.

New features
Bug fixes
Posted in WiX at June 21st, 2008. 1 Comment.

When you include deferred custom actions — that somehow modify the machine — in your setup, you have two big responsibilities:

  1. Provide rollback custom actions that "undo" what the deferred CAs do so that the installation transaction is actually transactional.
  2. Test.
  3. Test.
  4. Test.

OK, so numbers 2 through 4 are kinda the same but not really: Even a simple installation (say, without patching or upgrades) has three different scenarios you need to test when you have deferred/rollback custom actions:

  1. Installation rollback.
  2. Repair rollback.
  3. Uninstallation rollback.
  4. All of the above.

The right behavior for each kind of rollback is usually the opposite action. Rolling back installation is uninstallation. Rolling back uninstallation is installation. Rolling back repair is usually installation. Mixing installation, repair, and uninstallation is possible if your package has user-selectable features and users go into maintenance mode to turn on and off features. And, of course, it’s always an option from the msiexec.exe command line using the ADDLOCAL/ADDSOURCE/ADDDEFAULT, REMOVE, and REINSTALL properties.

Testing rollback means testing failure

Windows Installer initiates rollback when an action fails, so to test rollback you need to cause a failure. WiX includes an easy way to trigger failure: The WixFailWhenDeferred custom action, part of WixUtilExtension, triggers a failure when it’s executed. Include it in your package by referencing WixUtilExtension (in your Votive .wixproj or via the -ext switch to the light.exe command line) and adding a CustomActionRef to your package authoring:

<CustomActionRef Id="WixFailWhenDeferred" />

WixFailWhenDeferred automatically schedules itself in InstallExecuteSequence before InstallFinalize, with a condition of:

WIXFAILWHENDEFERRED=1

The condition means that you can have one package to test all the different possible combinations of "normal" installation and rollback. Just pass the WIXFAILWHENDEFERRED=1 property value on the msiexec.exe command line to trigger rollback. For example:

msiexec /qb- /i intermediate.msi /L*vx installfail.log WIXFAILWHENDEFERRED=1
msiexec /qb- /i intermediate.msi /L*vx install.log
msiexec /qb- /fvamus intermediate.msi /L*vx repairfail.log WIXFAILWHENDEFERRED=1
msiexec /qb- /fvamus intermediate.msi /L*vx repair.log
msiexec /qb- /x intermediate.msi /L*vx uninstallfail.log WIXFAILWHENDEFERRED=1
msiexec /qb- /x intermediate.msi /L*vx uninstall.log

WixFailWhenDeferred has been in WiX v3 weekly releases since April.

Posted in WiX, Windows Installer at June 18th, 2008. 5 Comments.

WiX v3.0.4214.0 was released on Saturday, 14-June-08. You can download it from http://wix.sourceforge.net/releases/3.0.4214.0/.

New features
  • DTF can now load assemblies from the GAC.
  • Candle’s -platform switch has been renamed -arch to match the sys.BUILDARCH variable. There is no change to the .wixproj InstallerPlatform switch.
Bug fixes
Posted in WiX at June 14th, 2008. No Comments.