WiX v3.0.4311.0 was released on Friday, 11-July-08. You can download it from http://wix.sourceforge.net/releases/3.0.4311.0/.

New features

  • Neil Enns, late of the MSBuild team and now working on secret stuff, contributed a new section of how-to topics for WiX.chm. (This was actually new in v3.0.4220, but I didn’t catch it. Mea culpa!)
  • Neil also added support for multiple .wxl (loc-string collection) files in .wixproj projects.
  • The SecureObj custom actions, triggered by the use of the PermissionEx element in WixUtilExtension, now support 64-bit systems, including both x64 and IA64.
  • Jason added support for MSI 4.5 multi-package transactions to DTF.
  • I added new file-i/o functions (FileReadPartial and FileWrite) and error reporting for XML parsing errors to the dutil library.
  • Aaron added new documentation in addition to fixing WixUI bugs.
  • Votive now has fancy new high-res/high-color icons on Windows Vista.

Bug fixes

Posted in WiX at July 12th, 2008. 6 Comments.

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.

As I mentioned previously, one of my favorite examples of a tight, clean Windows Installer package for a real product–VirtualBox–succumbed to a dreaded VBScript custom action when they released v1.6.0. Predictably, it caused errors (during uninstallation, because this custom action ran during uninstall only).

VirtualBox 1.6.2 dropped that custom action. The VirtualBox installers still have a few ICE errors and warnings so here’s hoping the VirtualBox team continues cleaning those up.

Posted in Windows Installer at June 13th, 2008. No Comments.

As Rob mentioned, one of the things we’re looking at fixing in a WiX v2 service release is to downgrade the version of mergemod.dll to one that doesn’t have a particular bug. For more information on the bug, see Rob’s original blog post and bugs 1965131 and 1911165.)

Until that release, you can download the latest WiX v3 release, extract mergemod.dll from the .zip file, and replace your copy of mergemod.dll with it. (If you installed via the Votive installer, it will be in Program Files\Windows Installer XML\bin.)

We’ll get that v2 SP1 out to solve the problem instead of just working around it.

Posted in WiX at June 9th, 2008. No Comments.

WiX v3.0.4207.0 was released on Saturday, 7-June-08. You can download it from http://wix.sourceforge.net/releases/3.0.4207.0/. Note that WiX v3.0.4206.0 was released on Friday but contains a bug that breaks MSBuild-based projects.

New features
  • All the command-line handling for tools like Candle.exe was refactored to simplify repetitive code and do better error-checking.
  • Project reference preprocessor variables are now populated by the project reference name rather than the project base name itself.
  • When adding a new component to a new feature in a patch, the feature is now automatically added to the patch.
  • .wixproj projects now define project output groups.
  • Votive projects now support x86, x64, and ia64 platforms (dropping the invalid AnyCPU platform).
Bug fixes
  • An intermittent DTF bug setting property values.
  • The DTF ComponentInfoCollection and FeatureInfoCollection enumerators now work correctly.
  • 1793251
  • 1983810
  • 1985794
Posted in WiX at June 7th, 2008. 4 Comments.

WiX v3.0.4130.0 was released on Friday, 30-May-08. You can download it from http://wix.sourceforge.net/releases/3.0.4130.0/.

New features

  • The sources .zip file now contains more of the non-binary files needed to build. There are still binaries you need to build that aren’t included; they can be picked up from CVS.
  • Candle now provides better error messages when duplicate preprocessor variables are specified.

Bug fixes

Posted in WiX at May 31st, 2008. No Comments.