When today's meeting started, we had only four new issues to triage and all were from Sean. Rob tempted the wrath of the whatever from high atop the thing by saying that because Sean opened them, discussion would be minimal. It turns out, gentle readers, that discussion was not minimal.
Issue triage
/xlog does not cause elevated process to log at DEBUG level, from @rseanhall, dares to suggest that the change I made to support verbose logging with the new
/xlogswitch isn't entirely functional. To defend my honor, I volunteered to investigate and, in the unlikely event of a bug, fix it.wix.exe can't find non-global installed extension during build, from @rseanhall, is a hopefully-simple bug that Rob volunteered to fix.
bal:SuppressDowngradeFailure should cause wixstdba to not even try to Plan or Apply, from @rseanhall, is yet another critique of a feature I implemented ages ago in WixStdBA. The
SuppressDowngradeFailureattribute was supposed to be an easy way to make a redistributable do nothing if a later version were already installed: It let setup developers say "install this if needed, but if you already have this or a later version installed, please don't complain." Unfortunately, it accomplishes this lack of complaint by installing the older bundle when it should simply exit. That's a reasonable thing to implement in WiX v4, so I volunteered to do so.
Design discussion
Instead of our regularly-schedule design discussion, today the design discussion happened in the context of one of Sean's bugs: Detect MinorUpgrade MsiPackages independently of the base product
It's a bit of a meta-issue that covers issues going back to the first release of Burn. Here's the story: Consider a typical bundle with MSI packages and a newer version of that bundle with newer MSI packages that upgrade those in the older bundle. When upgrading from the older bundle, the newer bundle fails and rolls back halfway through. The newer bundle had installed its newer MSI packages, which upgraded the older MSI packages.
There's an inconsistency in how Burn v3 handles rollback: Major upgrade packages are removed and minor upgrade packages are left behind. Either way, the machine is left in an inconsistent state: There's no sign of the newer bundle, and the old bundle is still installed, but its MSI packages are either missing or the wrong version.
This is a design weakness in Burn, but one that presents the least-worst option and comes from a lack of better alternatives: Once a package has been upgraded, the old version is gone. Restoring it would require reinstalling the old version of the package, which is probably cached by Burn (but maybe not) and might require passing custom properties to be able to install at all.
Uninstalling the packages meant that the user could be given instructions to go back to the older bundle and run a repair to get the whole product back in a working state. Leaving the upgraded package installed, as happens for minor upgrades, was another option but that assumes that the newer package would work with any of the older packages that were left behind. During design discussions back in the day, that mixed state was considered potentially worse: The old product might not work and a repair of the old bundle wouldn't restore the machine to the state prior to the upgrade attempt.
The inability to roll back to a previous version of an MSI package was one of the reasons that multi-package transaction support was added to Windows Installer. Burn supports MSI transactions, thanks to @nirbar and @rseanhall, though there are some known weaknesses (sometimes referred to as bugs) and, of course, they're only useful for MSI packages, not EXE packages.
Today we hashed through this story and Sean volunteered to investigate both making upgrade rollback consistent and automatically triggering the older bundle on rollback of an upgrade. We think it doesn't need a repair, just a normal "install" operation which will detect the missing packages and install them.
If this can come in WiX v4, it would resolve one of the biggest gaps in chaining functionality missing in Burn.