2021 continues to be a thrilling year, giving us our longest WiX Online Meeting in recent (or distant) memory, all for one issue triaged and two designs discussed.

Issue triage

  • RollbackBoundary is always discarded when at the beginning of the chain and New minimum OS for v4, both from @rseanhall, are issues that Rob asked us to postpone until the next meeting to discuss. Thus did our triage time get compressed.

  • Include PlanDump in release builds of Burn, also from @rseanhall, prompted a bit of discussion about the trade-offs of including additional debugging output in the log—PlanDump definitely qualifies—versus the size increases in the Burn engine that affect all bundles. The Burn engine has increased by a bit under 200KB since its first release in WiX v3.6. We agreed it would be good if we could avoid ongoing expansion—true in other areas of life as well—but we agreed the debugging value of the low-level bundle plan was worth the 5KB growth.

WiX v4 design discussions

We had half a dozen WiX v4 design issues to discuss and when Rob suggested we pick two, I suggested the issues weren't that controversial, so maybe we could do more. My naïvety was amply demonstrated and I will endeavor to re-learn that lesson.

Replace Win64 Attribute with a new attribute named similar to 'Always32Bit'

This issue is around "fixing" how easy it is to do an unnecessary thing. More specifically: In WiX v3, to have one set of WiX authoring from which you can build both x86 and x64 packages requires changes in both your projects and your authoring, for example, to account for different default directories (under ProgramFilesFolder and ProgramFiles64Folder, respectively). In WiX v4, it's easier:

  1. ProgramFiles6432Folder is available as a placeholder directory that is replaced at build time by the appropriate platform-specific directory.
  2. A package's architecture is set when building. In WiX v4 Preview Zero, that's the -arch switch on the wix build command line.

That brings us to today's topic: Several elements in the WiX language have a Win64 attribute that can be used to control whether the underlying resource (such as a component) is marked as 64-bit (Win64="yes") or 32-bit (Win64="no"). As I mentioned back in 2010:

Or, just let WiX handle it for you: Specify the -arch switch at the candle.exe command line or the InstallerPlatform property in a .wixproj MSBuild project. When you specify x64 or intel64—(Ed. note: No, really, Itanium! Of course, in 2021, arm64 is the other 64-bit flavor.)—, Candle automatically sets the package and components in the file being compiled as 64-bit. It’s still useful to be able to say Win64='no' for those components that are 32-bit even in 64-bit packages. Of course, that’s also legal in 32-bit packages, so it’s safe to hard-code.

Given that WiX does the right thing by default, the only time you need to worry about a component's bitness is when you're including 32-bit components in a 64-bit package. To make that clearer in the WiX language, we decided (after lots of discussion) to specify that with a Bitness attribute with values always32, always64, and default (the current behavior).

Allow separation of package and payload in chain

I created this issue as a lament at how it required a lot of duplicated WiX authoring to substitute one package payload for another. For example, the .NET Framework redistributable installer package groups in WixNetFxExtension have almost identical authoring except for the payload itself. Sean proposed a solution, so we got busy nit-picking. The nits centered on balancing the clean language design of completely separating package definition from its payloads and the usability of requiring multiple elements for common cases. We settled on duplicating two attributes: SourceFile and DownloadUrl so that using those doesn't require using multiple elements.