As we continue our supercharged triaging of issues -- both freshly incoming and older, already-triaged issues -- we also discuss design issues that benefit from real-time, almost face-to-face communication.
Issue triage
v4-preview.0 build action does not generate an .msi file, from @canihavesomecoffee, started out as a bug report -- that WiX v4 Preview Zero wasn't creating MSI packages -- and turned into a suggestion that wix.exe's default output path of the %TEMP% directory is pretty silly. Rob volunteered to change the default to something slightly less silly.
wix.exe -help needs to print semantic version, from @rseanhall, requests better version information instead of the fairly uninformative
4.0.0.0
. Rob agreed and volunteered to fix.Can't download WiX v3.14 from website in Chrome, from @rseanhall, is a problem with Chrome not allowing HTTP downloads from an HTTPS source. Rob promised to do some kind of web magic to make it work.
Bundle doesn't delete cache for msi package during minor upgrade, from @JuGGerNaunT, reveals a caching bug in Burn. Unfortunately, neither Sean nor I could figure out how to fix it, at least off the top of our (respective) head. Deeper research is required, so we took the bug into WiX v4.x.
Visual Studio 2022 integration?, from @nbelyh, requests Votive support for Visual Studio 2022. Given that the first preview of the new 64-bit Visual Studio was recently released, that's not too surprising. Luckily, in true open-source spirit, @virzak is already on the case.
error WIX0094: The identifier 'CustomAction:UninstallCertificates_X86' could not be found, from @matbech, reports a not-unexpected bug, because WixIIsExtension isn't one of the extensions we verified for WiX v4 Preview Zero. I took the issue to get the other extensions ready for WiX v4 Preview One.
Add StandardDirectory element description to the Wxs schema reference, from @jan-tosovsky-cz, suggests that documentation on new WiX v4 features would be a good idea. We concur. Rob has some of that documentation already written, just not yet committed to Git.
WiX v4 doesn't verify Component/Feature mapping, from @BMurri, started from a discussion and revealed a bug in that WiX v4 is no longer performing the check that every component is associated with at least one feature. Rob volunteered to fix this and restore order.
Erroneous function call in Touchfile.cpp and Errors logged during package installation are malformed, from @cpuwzd, are two minor bugs that were reported and fixed almost simultaneously. Thanks, @cpuwzd!
CoreIntegration test host crashed with AccessViolationException during MsiDatabaseImport, from @rseanhall, is an intermittent crash happening during the build of WiX itself. Rob volunteered to investigate.
WixBundleExecutePackageCacheFolder
is not accessible in the BA process for per-machine packages, from @rseanhall, reported that theWixBundleExecutePackageCacheFolder
variable is only available for per-user packages, not for per-machine packages. That's an unfortunate oversight, which Sean volunteered to fix.
Design discussion
Today we discussed one of a small handful of remaining open issues we want to discuss in real time. This one involves the "mend" feature we at FireGiant added to Burn in WiX v4.0 to support "soft repair," which we called "mend." (A "repair" in Burn reinstalls any components whose key files are missing or an older or equal version. In contrast, mend reinstalls components whose key files are missing or an older version. Repairs are more thorough but increase the likelihood of files in use or required reboots.)
Sean noticed a related feature request to gain more control over the REINSTALLMODE
property. That feature request wanted control over REINSTALLMODE
to work around default MSI behavior of preventing files from being downgraded.
Providing support for controlling (at least some) aspects of REINSTALLMODE
would also allow control over how repair works versus mend. Our discussion concluded that letting a bootstrapper application choose the kind of file versioning rule in REINSTALLMODE
provides the right level of flexibility and safety.
WiX v4.0 old issue triage
We continued triaging old issues assigned to the WiX v4.0 milestone. As a reminder, we decided to put them all into one of the following buckets:
closed
because we no longer believe the issue should be implemented.v4.x
because we don't believe it's necessary for WiX v4.0 but want it eventually.v.Next
because we don't believe it's necessary for WiX v4.0 and want it but it involves a breaking change that can't be made in a WiX v4.x release.wix.4.0-preview.1
because we believe it needs to be implemented in WiX v4.0.