This is part of a series of posts about breaking changes in WiX Toolset v4.0.

Previously, I started explaining the breaking changes that were made so that bundles could be available in multiple architectures. In this post, I’m going covering what the -arch switch does for bundles. In v3.x, the value of the -arch switch didn’t do anything for bundles. The bundle was always built from the x86 stub .exe. All Win64 attributes always defaulted to no.

In v4.0-preview.0, the stub .exe is chosen based on the value of the -arch switch. If there is no stub for the specified architecture, then building the bundle will fail (at bind time).

The other change was to replace Win64 attributes with Bitness. The available values are default, always32, or always64. The default value depends on whether the value of the -arch switch was 32-bit or not.

Action Required

Given that the -arch switch didn’t do anything in v3, most people probably didn’t use it and won’t have to do anything. To keep the same functionality as v3, just don’t specify it and it will default to x86.

Back when Burn was first released in 2013, only having an x86 stub was reasonable. It was still common to have an x86 OS. Although it was possible for people to remove WoW64 (x86 emulation) from servers, most people didn’t do it. Today, x86 is still the architecture that will run on most people’s machines. But once Microsoft releases x64 emulation on their ARM64 OS, that may no longer be true.

If you do need a 64-bit flavor of Burn, then make sure to go over all elements that had Win64 especially util:RegistrySearch. If you use a custom BA, you would also need a 64-bit version of it. This is not currently supported since none of the SDK .nupkgs for v4.0-preview.0 have been uploaded to nuget.org.