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.
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.
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
ProgramFiles64Folder, respectively). In WiX v4, it's easier:
ProgramFiles6432Folderis available as a placeholder directory that is replaced at build time by the appropriate platform-specific directory.
- A package's architecture is set when building. In WiX v4 Preview Zero, that's the
-archswitch on the
wix buildcommand 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
-archswitch at the candle.exe command line or the
InstallerPlatformproperty in a .wixproj MSBuild project. When you specify
intel64—(Ed. note: No, really, Itanium! Of course, in 2021,
arm64is 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
default (the current behavior).
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:
DownloadUrl so that using those doesn't require using multiple elements.