Today's meeting covered triage and discussion of the perils of relying on the cloud (aka other people's computers). It was prime. Literally, as 229 is a prime number. In fact, it's the 50th prime number, which must be an important anniversary deserving of celebration.
Removing bundles during upgrade should be done in order, is an old-old request to provide a stable order for how related bundles are executed. (Apparently, GUID order isn't good enough for some people!) Sean accomplished this request in Burn should ensure upgrade related bundles are always planned to execute last to maintain inter-bundle dependencies., just in a different order. We discussed it and decided the exact order doesn't matter but that there was a stable order does.
Wix deployed config files - merging, from @greengumby, requested support for merging configuration settings during upgrades. You can do this today with
XmlConfigauthoring, though, obviously, that works only for XML-based configuration files. A
JsonConfigextension would be interesting, if anyone's looking for some exciting weekend coding.
Add ability to force uninstall bundle is Sean acknowledging that sometimes, to be sure, you just have to nuke the entire bundle from orbit. Specifically, if a bundle stays registered because of a failure in the uninstall chain (or maybe, just possibly, because of bugs), some users are wont to pull out a registry "cleaner" in an attempt to uninstall it. Rather than suggesting such an abomination, we agreed that a new, scary switch
-unsafeuninstallwould instruct Burn to remove the bundle even if it would otherwise leave it registered.
VSExtension needs to support VS2022, from @rseanhall and Visual Studio Extension add support to detect 2022, from @chrpai, both requested support for Visual Studio 2022 in WixVSExtension. I already did that for WiX v4 and we agreed we'd take a pull request for WiX v3.14.
Enhance Burn's SetVariable so that it can evaluate a formatted string, from @rseanhall, is a request to enhance the already-new-to-WiX-v4 feature
SetVariable, which lets bundle authors directly set a variable to a new value. Currently, it supports only static values, instead of being able to format the value to resolve other variables. We agreed this was good functionality, and Sean volunteered to implement it.
GitHub Actions problems
Starting Tuesday night -- coincidentally (but probably not), February's Patch Tuesday -- the GitHub Actions builds that build our pull requests and the
develop branch, started failing with messages indicating the build was canceled. By whom...or what?...we don't know. Rob has used The Power of Twitter™ to ask GitHub to investigate. In the meantime, Sean restored the AppVeyor builds we'd been using before, so we can verify that pull requests aren't introducing failures. More news as the situation develops.