As anybody following this blog knows, today, 5-April-2024, is an exciting day! Obviously, it's the -39th anniversary of Star Trek First Contact Day, when humans and Vulcans first meet. I'm not saying I dressed up, but...oh, right, it's also the +20th anniversary of the first open-source release of the WiX Toolset and, not coincidentally, the release date of the sparklingly-new WiX v5.

WiX v5 is the first of our frequent-features-faster annual releases. The adoption of NuGet as the primary distribution method for WiX means that adopting a new version of WiX is easier than it's even been. (The configuration management curmudgeons among us might argue that the WiX v2 model of "just unzip it into source control" is even easier, but I digress...) Now you can pick up a bug fix or new feature by changing a couple of digits in your projects (or just once, if you're using central package management). We're taking advantage of that in two ways:

  • Shipping WiX more frequently (both bug-fix and major releases)
  • Avoiding big language changes that make it hard to pick up new releases

WiX v5 is just the first such release but we're confident we can keep up this approach and get out of the bad habit of "big bang" major releases with breaking changes every few years.

So as soon as we're recovered from the 20th anniversary celebrations, we're off to start the frequent-features-faster WiX v6.

In the meantime, take a look at all the new goodness in WiX v5:

What's new in WiX v5?

Here's what I had to say about the new features in WiX v5 when we shipped WiX v5.0.0-rc.1. You should read the WiX v5 for WiX v4 users pages for more detail and pretty sample code.

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="">
    <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, like WixStandardBootstrapperApplication for native code and WixBA.