WiX v3.0.3711.0 was released on Friday, 11-Jan-08.
- 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:
- 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.
- The MSBuild wix.targets file is now marked as trusted in the registry to avoid a hackaround to avoid security prompts.
- 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.
Two recent changes that simplify the WiX language will be available in the next weekly release of WiX v3. The goal of both changes is to make simple setup authoring simpler and help reduce redundancy.
Assigning components to features via attribute
The Component element now has a Feature attribute; when set, that component is parented to the specified feature. So the following snippets are equivalent:
<Component Id=”FooComp” Feature=”BarFeature” … />
<Component Id=”FooComp” … />
<ComponentRef Id=”FooComp” />
Component/@Feature supports one feature reference. You can still parent one component to multiple features using Feature or FeatureRef and ComponentRef. This change is to simplify the more common case of one component parented to one feature.
Default File Id and Name from Source
Typical File element authoring has several attributes with similar values. A File’s Id, Name, and Source elements might all mention the same file name, for example. WiX v3 already has several defaults that simplify File element authoring, like defaulting the Name attribute value to that of the Id attribute.
The File element now takes the default for the Id attribute from the file name portion of the Source attribute. The Name attribute then gets its default value from Id, so authoring a File element can now be as simple as:
<File Source=”$(env.Bits)\foo\bar\baz.exe” />
The equivalent would be:
<File Id=”baz.exe” Name=”baz.exe” Source=”$(env.Bits)\foo\bar\baz.exe” />
Simple change, simple benefit
The code changes for these two features were trivial. But I think they represent the kind of schema changes you’re likely to see as we head to a WiX v3 stabilization, as Rob mentioned earlier this year. A simpler language makes it easier for designers to generate clean code and for those who prefer hand authoring to minimize unnecessary typing.
My second project at ACES Studio, the Flight Simulator X: Acceleration expansion pack, has gone gold. Well, 12.5 percent of it has: We sent the English release to manufacturing but we have seven more languages we’re shipping over the next couple of weeks. So while the extra-long days are a bit more normal now, the weekends are still fairly busy, coordinating builds and releases with our international folks in Dublin and Tokyo.
Acceleration was a “small” release, but only by the standards of a 14GB, two-DVD Flight Simulator X. Here are some mildly interesting statistics:
|Number of DVDs
|Number of files
|Compressed byte count
|Uncompressed byte count
|WiX version used to build installer
|Visual C++ version used to build setup UI and custom actions
|Number of new custom actions
||5 (plus rollback and scheduling CAs)
|Number of new custom tables for data-driven deferred custom actions
|Number of WiX custom actions consumed
|Percentage of WiX custom action enhanced for Acceleration where enhancements were contributed back to WiX
Seven more languages to go!
Apple’s Safari browser is now available in public beta on Windows. A little spelunking shows that it uses Windows Installer packages and that they’re built with WiX. Sadly, they didn’t use WixUI.<g>
On a more serious-but-sad note, the packages have ICE validation errors (other than the typical ones), contain VBScript custom actions, and the main Safari package uses a custom action to install the Apple Software Updater package (instead of using a chainer). Already there’s a forum report of a 2738 error with the VBScript CA. And I guess the only way to report bugs is via forum posts…? It’s not clear. The “Report Bugs to Apple” command on the Help menu seems focused on rendering problems. Too bad. After all, Setup Development Is Just Development.