Joy of Setup

Working with multi-gigabyte setups has taught me that compressing cabinets can be very time-consuming. Of course, it can also be vital — Flight Simulator X barely fit on two DVDs; without high compression, it would have required a third disc.

As I work on the WiX tooling and authoring for upcoming products, I knew I needed to support multiple compression levels: no/low compression for developer builds, “normal” MSZip compression for daily builds, and high compression for milestone builds.

By default, a Media element with no CompressionLevel attribute gets MSZip compression, which offers a nice compression-to-time ratio. A typical approach to control compression level outside the authoring is to pass in a preprocessor variable via the MSBuild project and use its value in Media/@CompressionLevel. That works but is kind of clunky.

So I decided to address the clunkiness by adding support to override the default MSZip compression level. Here are the two steps to take advantage of this feature:

1. Author Media elements with a Cabinet attribute but without a CompressionLevel attribute.
2. Pass -dcl:level on the Light command line, where level is none, low, medium, high, or mszip.
   –or–
   Declare the DefaultCompressionLevel property in your MSBuild project file, with a value of none, low, medium, high, or mszip.

There are no changes in behavior with existing authoring or build scripts. If you omit Media/@CompressionLevel and don’t use -dcl or DefaultCompressionLevel, you’ll continue to get MSZip compression.

This change will appear in the next weekly release of WiX v3.

WiX v3.0.3725.0 was released on Friday, 25-Jan-08. You can download it from http://wix.sourceforge.net/releases/3.0.3725.0/.

New features

• The XmlConfig element in WixUtilExtension now supports a Node attribute value of document to rewrite the whole XML document.
• The new switch -swall for candle, light, and lit suppresses all warnings, for when you’re feeling reckless.
• WixUI now validates that the chosen installation directory is valid, to detect as early as possible what would otherwise be a fatal error.
• Code page values can now be specified by number or “Web name.”
• New core WiX elements include SetDirectory and SetProperty, which offer simplified authoring for type 35 and type 51 custom actions, respectively.

Bug fixes

• 1644783
• 1680503
• 1835329
• 1872939
• 1877424

WiX v3.0.3711.0 was released on Friday, 11-Jan-08.

New features

• The WiX MSBuild tasks run repeated commands faster by recycling AppDomains rather than always creating new processes.
• MSBuild tasks are now available for Heat and its extensions.
• The ComponentGroup element can now be a child of Product.
• Binder variables can be used wherever localizable integers are allowed so you can now use !(bind…) in addition to !(loc…).
• Binder variables now include FileVersion and FileLanguage from versioninfo resources, if present. Syntax is:
  !(bind.FileVersion.fileId)
  !(bind.FileLanguage.fileId)
• Multiple .wxl files of the same culture can now be added to a .wixlib. (Multiple .wxl files of different cultures have always been supported.)
• 1867685: An enhancement to the change I discussed in Simplifying the WiX v3 language.
• Localization support for Votive and its templates.

Bug fixes

• The MSBuild wix.targets file is now marked as trusted in the registry to avoid a hackaround to avoid security prompts.
• 1853251
• 1848762
• 1853854: The actual bug was missing localization strings.

Without a marketing budget to declare WiX releases full of NEW! and IMPROVED! features, I thought it might be interesting to dig a little deeper into the changes that are published on a weekly basis (holidays notwithstanding). We maintain a history.txt file that’s published with every drop but it’s usually a bit spare.

So weekly (plus or minus), I’ll post about the most recent weekly release of WiX. Just the highlights; if you want an exhaustive list, check out history.txt and if you want an exhaustive diff, fire up your favorite directory diff tool against the two sets of source. (Beyond Compare works great at this kind of diff.)

We’ll see how this experiment works.

There’s been an increase lately in the number of questions on the wix-users mailing list and elsewhere about extending the WixUI dialog library.

WixUI extensibility past

In WiX v2, WixUI is a simple .wixlib of UI authoring fragments. Navigation between pages of the wizard is handled by properties that contain the previous and next dialog names for each dialog. You can extend the stock dialog sets by inserting custom dialogs into the wizard sequence; set the back and next properties for the dialogs before and after the one you’re inserting. To customize one of the stock dialogs always requires you to copy that dialog’s source file and modify it. You also need to copy the fragment containing the properties for the dialog set; otherwise you’d end up with duplicate properties.

WixUI extensibility present

In WiX v3, WixUI is built as an extension. All the standard dialog fragments, bitmaps, and custom action DLL (to print the EULA) are embedded in it. WixUI v3 takes advantage of several features added to WiX v3:

• WiX variables to point to bitmaps and the license RTF file, to override those included in the extension.
• “Floating” Publish elements move dialog behavior out of the dialog fragments and into the dialog set fragment. That makes it easier to reuse a dialog and still give it different behavior.

Adding a dialog into the wizard sequence means copying the dialog set fragment and changing the floating Publish elements for the existing dialogs and adding new ones for the new dialog.

It’s possible to more easily re-use the stock dialogs but still not possible to modify their appearance. That still requires copying the dialog into your own project. You can still refer to the dialogs you don’t modify from their copies in WixUIExtension.dll and the linker will find them there.

Compare and contrast

If you’ve used one of several “name-brand setup authoring tools” (hereinafter NBSATs), you’ve seen a very different approach:

1. Create a new project.
2. See shiny, happy dialogs listed in your NBSAT IDE.
3. Edit the aforementioned dialogs to your heart’s content.

In general, what’s happening is that the NBSAT is copying its set of dialogs directly into your NBSAT project file. As the NBSAT IDE is the preferred (or only) way of seeing the project, it can hide all those dialogs until you need to edit them.

The WixUI model is different: You don’t get copies of the WixUI dialogs; when you build your project with a UIRef element to a WixUI dialog set, the WiX linker is pulling those dialogs directly from the .wixlib (that in WiX v3 is embedded in WixUIExtension.dll).

WiX could offer the same always-copy model NBSATs use (via a Votive template, for example). The downside is that you’d have all this UI code in your project. Lacking (for the moment) a WiX IDE, there’s no way to hide any code in your project file: It’s always visible in all its XML angle-bracket glory. Keeping the UI authoring in a library keeps it hidden, at the cost of more painful customization.

WixUI extensibility future

That’s another article, coming soon.<g>