WiX v5.0.0-rc.1, the first release candidate of our first annual release cadence, is now available for your packaging pleasure. Download it, use it -- it's an easy job to switch from WiX v4 -- and report any bugs you discover.

After a couple of hiccups, WiX v5.0.0-rc.1 is now available. WiX v5 represents a change in how we're treating major releases of WiX. Previously, major releases of WiX were years-long releases -- many years-long releases, in the case of WiX v4 -- and so many changes accumulated that moving to the latest release was a nontrivial exercise. Sometimes big changes are necessary (see below) but our plans to make annual releases help us say no to big changes "just because." In fact, for the first time in the (almost) 20 years of WiX history, a major release of WiX is (almost) 100 percent backward compatible with the language in the previous version.

What's new in WiX v5?

The WiX v5 for WiX v4 users pages cover the new features in WiX v5 so I'll engage in a bit of self-plagiarism to whet some appetites:

File harvesting

The new Files element integrates file and directory harvesting as a core feature of the WiX language.

Files takes wildcarded paths to include and exclude files, traverses the specified directories, and generates components and files for each file.

Combined with other features in this list, you can now build a package with potentially thousands of files with some impressively compact WiX authoring:

<Wix xmlns="http://wixtoolset.org/schemas/v4/wxs">
    <Package Name="MyProduct" Version="" Manufacturer="Example Corporation" UpgradeCode="B0B15C00-1DC4-0374-A1D1-E902240936D5">
        <Files Include="path\to\files\**" />

Naked files

Naked files are, in fact, rather more sedate than their name might suggest.

WiX v5 adds support for so-called "naked" files, which are files without the XML overhead of enclosing Component elements. Wherever Component elements can appear, so can File elements. In the compiler, WiX conjures appropriate components for each file. Simple authoring is now simpler.

<ComponentGroup Id="Files" Directory="MyFolder" Subdirectory="bin">
  <File Source="foo.exe" />
  <File Source="bar.dll" />
  <File Source="baz.db" />


No release of WiX would be complete without a set of language simplifications. This time, they're the "provide reasonable defaults so setup developers don't need to specify boring stuff over and over" features. WiX v5 includes:

  • Default major upgrade, which provides the same major upgrade authoring that you'd get with a MajorUpgrade element -- including a DowngradeErrorMessage that comes from the new WiX Standard Library. (The message is in US-English but you can provide your own string for other languages or even English if you prefer your own wording.)
  • Default installation folder, which is a directory with id INSTALLFOLDER that points to the ProgramFiles6432Folder directory with a name of the Package/@Manufacturer and Package/@Name attribute values.
  • Default feature lets you skip authoring a Feature, which is handy if your package is small or just doesn't need a complicated feature tree. If you don't have a Feature, WiX provides one and automatically adds all the package's components to it.

In all three cases, the default appears only if you need it. For example, if your package already has an INSTALLFOLDER directory, the default INSTALLFOLDER stays hidden away. That means that there's never a conflict between your authoring and the magic defaults.

What's the "almost" when it comes to compatibility?

Virtual and overridable symbols

Virtual and overridable symbols are a generalization of WiX's existing support for "overridability."

WiX v5 introduces the concept of virtual and override access modifiers for symbol identifiers, which are very similar to the same keywords you find in languages like C# and C++:

  • virtual declares that the identifier can be overridden.
  • override declares that the identifier overrides the corresponding virtual identifier.

If you attempt to override a virtual identifier without using the override access modifier, you'll get an error message that tells you how to fix it.

Bootstrapper application processes

Bootstrapper applications are now separate processes rather than hosted by the Burn engine, to increase reliability and security. Being out-of-process also increases compatibility, as Burn no longer needs special support to host .NET or any other language/runtime, for that matter. Want to write a BA in COBOL? You do you.

If you have written your own custom bootstrapper application, you will have to make changes to your project to adopt the new Burn/BA communication model. Details are forthcoming but you can see the changes in the BAs that come with WiX and test BAs in the WiX repo on GitHub.