In a rare reversal of end-of-year weather fortune, my driveway in Michigan is dry and Rob's in Washington is snow-covered. (I'm entirely confident that this will not hold true over the next several months.) Before Rob got out the snow shovel, we quickly reviewed a couple of open issues and reviewed some pull requests, mostly from Sean, whose driveway is an unknown state, but likely also snow-free.

Issue triage

Pull request review

Sean requested that we review three of his pull requests, to address questions he had during the process of coding for the aforementioned pull requests.

  • 3421 - Reinstall packages that were uninstalled during failed upgrade bundle addresses the open issue Burn uninstalls upgraded MSIs during rollback, specifically that a failure installing a newer bundle could well leave the machine in a bad state, having upgraded some of the packages in the newer bundle but leaving older packages from the older bundle behind. The solution we came up was to reinstall (not repair) the older bundles as part of rolling back the install of the newer bundle. Sean brought up some details that we hadn't previously considered, like the fact that there might be multiple bundles being upgraded. In the end, we decided to take the simplest approach to reinstall all upgraded bundles, in ascending order by version, as the safest way of getting a machine back to its original state.

  • 6348 - Deunify FilesInUse messages in Burn is a pull request that undoes work done in WiX v3 to try to unify the files-in-use behavior or MSI, MSI and Restart Manager, and the .NET Framework redistributable chainer. The impetus behind Sean's deunification (not a word, but I'll allow it) comes from When getting a files in use message on .NET chainer the response is wrongly returned to .NET installer, from @nirbar. The original unification wasn't completely successful and the interfaces and responses are different enough that unification should be done outside the Burn engine. With that decision, Sean declared the pull request ready to be merged and did so shortly after the meeting concluded.

  • 4858 - Add ability to uninstall MSIs separately was a partial implementation of idea prompted by my feature request Add UninstallMsiPackage/@ProductCode to let Burn uninstall packages. The problem I was trying to solve was to work around a "broken" MSI package that failed during a typical MSI major upgrade. Instead, it needed to be uninstalled before a newer version could be installed. Unfortunately, the need for that kind of remediation isn't uncommon. (Pay heed to the words of the FireGiant Enterprise Support team: Eat your vegetables and always test your patches and upgrades before releasing, not after.) There are a number of security and functionality needs this feature would introduce, so Sean suggested it wouldn't be a priority for him in WiX v4.0.

We also looked at a non-Sean pull request that Rob has already reviewed (kind of): Add semver to help command, from @MarkStega, prompted Rob to suggest two things:

  1. Before starting work on a pull request, talk with the assignee of the original issue or start a thread on the wix-devs mailing list mailing list to glean any details that aren't written down.
  2. When adding review comments to a pull request on GitHub, be sure to submit the review so everyone else can see them.