As usual, today's meeting covered triage mixed with design discussions galore. Then, in response to questions from Ron watching live, we talked about how the WiX integration tests run during the CI build in virtual machines and how developers could run them on local VMs. Finally, Rob briefly announced a new prerelease build of WiX v3.14 is now available for download, containing all the latest changes and fixes in that branch.

Issue triage

  • MSI version rules should be applied at compile time, from @rseanhall, requests that the validation that WiX applies to MSI product versions happen during compilation to get error messages immediately, rather than after linking and before the MSI packages are built. In the past, we've preferred to do validation during compilation, but the changes in the WiX v4 build pipeline allow more targets than just MSI packages and bundles. Now, more validation is happening in the "backend" of the build pipeline because that's where we can do validation that's specific to an output type. It also needs to happen in the backend to do validation on bind-time variables like localization strings. That being the case, we declined this issue.

  • Allow MSI version of 1.2.3.abc or 1.2.3.9876543210, from @rseanhall, seemed a bit incongruous with the previous issue, but Sean and Rob seemed to think it makes sense to allow MSI product versions to contain arbitrary characters because Windows Installer explicitly ignore anything beyond the first three version fields. I personally consider that to be cuckoo banana pants, but I admit I've lost that battle. Rob suggested that because Burn consumes MSI packages, however we support this scenario, it needs to be compatible with Burn. We decided to close this issue and Sean opened another one -- Allow MSI ProductVersion to be any valid WixVersion -- that we'll discuss at our next meeting for a Burn-compatible design.

  • SendEmbeddedError and SendEmbeddedProgress should support additional data, from @barnson, came about from some recent work I did using Burn's "embedded" support to pipe progress and error information to a "host" program. Neither progress nor error information includes much in the way of useful context, not even the id of the package that the information applies to. Unfortunately, as this information is sent over named pipes in a particular format, keeping it backward compatible is challenging. I took this issue to look at a backward-compatible design in a future WiX release.

  • Wix toolset visual studio extension not getting installed with Visual studio community edition, from @Sandeep2000gupta, includes reports of a couple of issues some users have had installing Votive in Visual Studio 2022. Unfortunately, we haven't been able to reproduce these issues -- It Works On My Machine™ -- and we have very little insight into how Visual Studio installs VSIX packages. We're keeping this issue open until our next meeting in the hopes we can help users diagnose the problems.