Highlights of WiX

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.

Simplifying the WiX v3 language

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” … />

and

<Component Id=”FooComp” … />

<FeatureRef Id=”BarFeature”>
<ComponentRef Id=”FooComp” />
</FeatureRef>

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.

Flight Simulator X: Acceleration releases to manufacturing

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 1
Number of files 7121
Compressed byte count 2,567,158,638
Uncompressed byte count 4,014,683,859
WiX version used to build installer 3.0.3304.0
Visual C++ version used to build setup UI and custom actions 8.0
Number of new custom actions 5 (plus rollback and scheduling CAs)
Number of new custom tables for data-driven deferred custom actions 2
Number of WiX custom actions consumed 2
Percentage of WiX custom action enhanced for Acceleration where enhancements were contributed back to WiX 100

Seven more languages to go!

Apple Safari setup built with WiX

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.

New system information custom actions coming soon to WiX v3

The Windows Home Server folks have an SDK for extending the server with what they call “add-ins.” Their deployment sample is written with WiX. I love to see that, so I’m looking into what setup functionality would make a useful WHS extension for WiX. Right now, it doesn’t look like there’s much required — the requirements of a WHS add-in installer are pretty minimal over and above a good installer in general.

One thing they mention is detecting WHS if your add-in requires it. It’s not one of the standard Operating System Properties that MSI provides (yet, at least). The WHS SDK recommends calling the GetVersionEx API function. Clearly, it’s time for a custom action: Enter WixQueryOsInfo.

I wanted to follow the same model as MSI; that is, set a property if the OS running the package is of a particular edition or supports a particular feature. That lets you use them in conditions for features or components that only make sense when the user is running a supported OS or configuration.

As I’d be writing a CA to call GetVersionEx, I looked at what else it could detect that MSI didn’t already support. There were several, though sometimes the MSI naming convention didn’t match how GetVersionEx named them. So I decided to set properties for everything GetVersionEx offered using its naming convention. That way, it’s easy to mentally translate from the GetVersionEx doc to the properties WixQueryOsInfo sets.

Then, while I was in there, I added another CA to do something similar: WixQueryOsDirs sets properties for the “special folders” Windows defines for system and user directories. MSI already supports a long list of System Folder Properties but there are extra ones that Windows supports. For WixQueryOsDirs, I didn’t duplicate the ones MSI already supports.

Using WixQueryOsInfo and WixQueryOsDirs

The CAs are part of WixUtilExtension so you need to link with the “-ext WixUtilExtension” switch. Your WiX source must reference the CAs via their properties, to cause the linker to pull in the DLL and sequencing:

<Product …>
<PropertyRef Id=”WIX_SUITE_SINGLEUSERTS” />
<PropertyRef Id=”WIX_DIR_COMMON_DOCUMENTS” />
</Product>

Note that WixQueryOsInfo and WixQueryOsDirs both always set all the properties that apply, regardless of which you specify via PropertyRef. The PropertyRef just pulls in the CA, the DLL in the Binary table, and InstallExecuteSequence and InstallUISequence scheduling.

Look for OSInfo in the next weekly release of WiX v3.

Here’s the documentation page that’s part of WiX.chm:

OSInfo custom actions

The WixQueryOsInfo and WixQueryOsDirs custom actions in wixca (part of WixUtilExtension) set properties over and above the MSI set for OS product/suite detection and standard directories. Here’s a complete list:

WixQueryOsInfo properties

WIX_SUITE_BACKOFFICE

Equivalent to the OSVERSIONINFOEX VER_SUITE_BACKOFFICE flag.

WIX_SUITE_BLADE

Equivalent to the OSVERSIONINFOEX VER_SUITE_BLADE flag.

WIX_SUITE_COMMUNICATIONS

Equivalent to the OSVERSIONINFOEX VER_SUITE_COMMUNICATIONS flag.

WIX_SUITE_COMPUTE_SERVER

Equivalent to the OSVERSIONINFOEX VER_SUITE_COMPUTE_SERVER flag.

WIX_SUITE_DATACENTER

Equivalent to the OSVERSIONINFOEX VER_SUITE_DATACENTER flag.

WIX_SUITE_EMBEDDEDNT

Equivalent to the OSVERSIONINFOEX VER_SUITE_EMBEDDEDNT flag.

WIX_SUITE_EMBEDDED_RESTRICTED

Equivalent to the OSVERSIONINFOEX VER_SUITE_EMBEDDED_RESTRICTED flag.

WIX_SUITE_ENTERPRISE

Equivalent to the OSVERSIONINFOEX VER_SUITE_ENTERPRISE flag.

WIX_SUITE_MEDIACENTER

Equivalent to the GetSystemMetrics SM_SERVERR2 flag.

WIX_SUITE_PERSONAL

Equivalent to the OSVERSIONINFOEX VER_SUITE_PERSONAL flag.

WIX_SUITE_SECURITY_APPLIANCE

Equivalent to the OSVERSIONINFOEX VER_SUITE_SECURITY_APPLIANCE flag.

WIX_SUITE_SERVERR2

Equivalent to the GetSystemMetrics SM_SERVERR2 flag.

WIX_SUITE_SINGLEUSERTS

Equivalent to the OSVERSIONINFOEX VER_SUITE_SINGLEUSERTS flag.

WIX_SUITE_SMALLBUSINESS

Equivalent to the OSVERSIONINFOEX VER_SUITE_SMALLBUSINESS flag.

WIX_SUITE_SMALLBUSINESS_RESTRICTED

Equivalent to the OSVERSIONINFOEX VER_SUITE_SMALLBUSINESS_RESTRICTED flag.

WIX_SUITE_STARTER

Equivalent to the GetSystemMetrics SM_STARTER flag.

WIX_SUITE_STORAGE_SERVER

Equivalent to the OSVERSIONINFOEX VER_SUITE_STORAGE_SERVER flag.

WIX_SUITE_TABLETPC

Equivalent to the GetSystemMetrics SM_TABLETPC flag.

WIX_SUITE_TERMINAL

Equivalent to the OSVERSIONINFOEX VER_SUITE_TERMINAL flag.

WIX_SUITE_WH_SERVER

Windows Home Server. Equivalent to the OSVERSIONINFOEX VER_SUITE_WH_SERVER flag.

WixQueryOsDirs properties

WIX_DIR_ADMINTOOLS

Per-user administrative tools directory. Equivalent to the SHGetFolderPath CSIDL_ADMINTOOLS flag.

WIX_DIR_COMMON_ADMINTOOLS

All-users administrative tools directory. Equivalent to the SHGetFolderPath CSIDL_COMMON_ADMINTOOLS flag.

WIX_DIR_COMMON_DOCUMENTS

All-users documents directory. Equivalent to the SHGetFolderPath CSIDL_COMMON_DOCUMENTS flag.

WIX_DIR_COOKIES

Per-user Internet Explorer cookies directory. Equivalent to the SHGetFolderPath CSIDL_COOKIES flag.

WIX_DIR_HISTORY

Per-user Internet Explorer history directory. Equivalent to the SHGetFolderPath CSIDL_HISTORY flag.

WIX_DIR_INTERNET_CACHE

Per-user Internet Explorer cache directory. Equivalent to the SHGetFolderPath CSIDL_INTERNET_CACHE flag.

WIX_DIR_PERSONAL

Per-user documents directory. Equivalent to the SHGetFolderPath CSIDL_PERSONAL flag.

To use the WixQueryOsInfo and WixQueryOsDirs custom actions, add PropertyRef elements for the properties above you want to be set and add WixUtilExtension to your link options (a.k.a. the Light command line). For example:

<PropertyRef Id="WIX_SUITE_SINGLEUSERTS" />
<PropertyRef Id="WIX_DIR_COMMON_DOCUMENTS" />

WixUtilExtension automatically schedules the custom actions as needed after the AppSearch standard action.