Today we saw the effects of "documentation-driven development," which is what happens when someone tries to write some documentation about a feature and finds out the feature is hard to write about. Make the feature easier to use and it's better for millions of users, and, more importantly, the writer. Though sometimes it complicates triage.

WiX v4 release plan

Tomorrow, 24-February, we're shipping WiX v4.0.0-rc.3 as planned. RC4 is still planned for 24-March. RC2 had a similar number of bugs as RC1 but they tended to be simpler or narrower in scope (according to the metrics of "gut feelings"), so we're hoping that trend continues. As always, we're getting close to the point at which we can say that WiX v4 is ready for the masses. If you'd be so kind, please check our math on that and if you find a bug we just have to fix, report it.

Issue triage

  • Add search capability inside XML file, from @fyodorkor, is coming back at the request of the opener, who wants to work on it. We've requested a WIP, so we can talk about things like the schema of the custom element.

  • Simplify QuietExec authoring with compiler extension, from @barnson, suggests that some of the boilerplate involved in using the WixQuietExec custom action family could be hidden away inside a compiler extension. That suggestion is, of course, both brilliant and accurate, so this issue is now open as up for grabs.

  • Add sys.BUILDARCHSUFFIX preprocessor variable, from @barnson, came about from my ongoing documentation work. This issue came with a draft pull request so now the sys.BUILDARCHSHORT preprocessor variable is available to simplify (writing about) the WixQuietExec custom action family.

  • Revisit need/desire for WixQuietExec64, from @barnson, is, perhaps unsurprisingly, yet another issue that came from writing about the WixQuietExec custom action family. In WiX v3, WixQuietExec64 was a 32-bit custom action that knew how to access 64-bit parts of the file system. WiX v4 has platform-specific custom actions everywhere, so theoretically, there's no longer a need for WixQuietExec64. Or is there? Rob brought up a potential edge case that we need to research to confirm or deny. So we'll leave WixQuietExec64 in WiX v4, do the research, and make a decision in a future release.

  • WiX v4 should support .NET Framework 4.8.1, from @barnson, came to me after I threw a tantrum and switched from trying to write WixQuietExec documentation to writing about the WixToolset.Netfx.wixext WiX extension. The latest version of .NET Framework is v4.8.1 and came out last year, so I figured WiX v4 should support it. I also figured there would be throngs of people volunteering to address the issue that I so thoughtfully opened. Alas and alack, my hopes were dashed, so instead I volunteered to add .NET Framework 4.8.1 support to WixToolset.Netfx.wixext.

  • WIP: Support multi-targeting ProjectReferences from a .wixproj, from @robmen, suggests that Rob really likes playing around deep inside MSBuild. With this issue -- which Rob has already implemented -- multi-targeting other projects from a .wixproj is now a lot simpler. Rather than specifying one target at a time, you can now specify multiple targets per project at once. For example, it simplifies the projects in WiX's own extensions, which need to package up custom actions for x86, x64, and Arm64 platforms. This work also allows multi-targeting against .NET frameworks, runtime identifiers, and configurations.