Today we celebrated our dog days of summer special-savings event! All the triage and design discussion you can ask for, for the low-low price of free with zero percent APR financing. Come on down and let's get you into your favorite gently preowned issue!

Issue triage

  • ExePackage should support @RepairCondition, from @wixbot, was an issue I opened, we discussed, and put back in the triage queue to get consensus on what, if anything, we wanted to do with it. I did that by asking "Revive/kill?" and the answer we chose was "Kill."

  • Restart doesn't work on non elevated burn installers launched on Windows Server 2019, from @vanni-giachin, is an old issue I wanted us to discuss again, which is a mistake because the end result of the discussion is that somehow ended up assigned to the issue. I'll investigate to see if a fix in WiX v4 is feasible assuming days continue to have just 24 hours each.

  • During bundle upgrade, packages that get a Major Upgrade are planned with Rollback:Uninstall, from @MatthiasRInst, is a duplicate of some bugs from early in Burn's history. If an upgrading bundle installs major-upgrade packages and the bundle fails and rolls back, the major-upgrade packages will be uninstalled. Ideally, a rollback would reinstall the previous versions of the packages. However, that might not be feasible, so the current behavior ensures that the previous bundle can be repaired to get the system back into a known-good state. Automating the repair is something we continue to ponder as a decent solution.

  • Rollback of bundle upgrade breaks dependencies, from @MatthiasRInst, sounds similar to #6509 but is in a different part of the failure/rollback forest. In this case, there isn't an immediate failure but the dependency data is removed, meaning that Burn might remove a package even if another bundle still depended on it. Nobody immediately volunteered to investigate the issue but we pulled into the WiX v4.0 milestone so we'll review at least once more.

  • MSI generated with "High Mandatory Level" when Visual Studio runs as admin, from @forderud, complains that the output of a WiX build invoked from an elevated instance of Visual Studio inherits the high integrity level of the elevated Visual Studio process. That's not too surprising but other project types in Visual Studio don't produce the same results. Rob posited that the WiX v3 behavior of resetting the ACLs of generated files when running elevated might be involved but since suggesting that in the issue, the reporter came back and said that suppressing that behavior did not fix the problem. Well, bummer. So the issue is now open for investigation.

  • Support bundle automatic containering like in MSI, from @nirbar, requests that building bundles support the same "autocabbing" that MSI packages get today with the MediaTemplate element. Multi-gigabyte bundles are a fun challenge, so we're interested in the feature but need a WIP to document some of the differences inherent in bundles -v- MSI packages.

Design discussion

Today's design discussion was about how it's just a little weird that the way you have to author searches in bundles is via an element in an extension. Searches for MSI packages -- like RegistrySearch and DirectorySearch -- are in the "core" WiX Toolset namespace. Burn's equivalents are in the WixUtilExtension namespace, so to do searches for a bundle, you have to reference WixUtilExtension in your bundle project and add the XML namespace to the .wxs file. That's not difficult or anything, and the bundle project templates already do that for you, but it is an extra step. Architecturally, it's weird because WixUtilExtension handles the compiling of those search elements but the actual implementation lives inside Burn, not WixUtilExtension.

So there's been thought for years now to clean up the weirdness: Either by moving the Burn search code out of Burn and into the new-to-WiX-v4-thanks-to-Sean feature of Burn extensions or by moving the Burn search elements into the core WiX namespace.

Slightly complicating the discussion is that the Burn searches are more powerful than those that MSI provides and wouldn't it be nice to provide that power as a set of custom actions that worked off the same search authoring as Burn? Yes it would but it's a nontrivial amount of work that hasn't piqued the right person/people yet. Whatever we decide to do shouldn't preclude someone eventually doing that work, though.

The decision for now is to do nothing: It's late in the WiX v4 cycle to make a change that might require a language change. Also, the only people it likely annoys are the same people who'd have to make the change. Eventually, it'll happen because architectural purity tastes oh so sweet. But not in WiX v4.

WiX v4.0 old issue triage

We continued reviewing old issues in the WiX v4.0 milestone. Some are moving out, some are going away, but most are sticking around and getting scheduled for WiX v4 Preview One, the feature-complete milestone for WiX v4.