WiX Online Meeting 295 Highlights

WiX v6.0.1

What better way to celebrate the two-month anniversary of WiX v6.0.0 than with a new release. On 5-June, we’ll ship a bug-fix release of WiX v6, imaginatively named WiX v6.0.1.

WiX v6.0.1 currently contains fixes for the following bugs:

• Bundle splash screen showing on removal of previous base version during upgrade, from @yuvnith
• Upgrading to Wix Toolset v6 Causes Build Exception, from @oollie34
• WixBundleSourceProcessPath and WixBundleSourceProcessFolder should be resurrected, from @barnson
• Update registration disappears during upgrade., from @barnson

New issue triage

• Harvest bundle payloads like Files does for package payloads, from @barnson, requests (and supplies) a feature to provide bundle payload harvesting like the Files element does for payloads in a package. This functionality is something Heat is commonly used for and as Heat is being removed, I wanted to provide a built-in replacement.

• Control BottomLine on dialog error seen in logs, from @MikeWilliams-UK, reacts to a fix that @bevanweiss made in WiX v6 to fix a 14-year-old bug. That change corrects the length of the line controls near the bottom of dialogs to extend the full width of the dialogs. So the dialogs look “right” but now show DEBUG: Error 2826 messages in verbose logs. We decided that the needs of the many (everyone looking at dialogs with a critical eye) outweigh the needs of the few (people looking at logs). It helps that searching for value 3 is a more precise way of looking for errors in an MSI log than searching for error.

• Add a PlannedMsiFeature event with Execute action in Burn, from @rkieslinger, requests the ability for a bootstrapper application to see the action state that Burn decided on. The existing OnPlanMsiFeature callback lets a BA change the default request state but there isn’t a corresponding callback once Burn has acted on that state. Typically Burn uses Begin and Complete pairs to request data and report back its plan but that wasn’t done for OnPlanMsiFeature. Therefore, this issue is up for grabs for someone to bring welcome homogeneity to the Burn API.

• Extension decompilers support only their extension’s own tables, from @barnson, come from my discovery that WiX v6 didn’t successfully decompile a package with firewall exceptions that was built with WiX v4. The WixToolset.Firewall.wixext source code explicitly lists the WiX v4 firewall table as something it knows how to decompile but that wasn’t happening. It turns out the core decompiler was only giving extension decompilers the tables that the extension uses. That qualifies as a premature optimization: Extensions should get the opportunity to decompile all custom tables so they can support decompilation from previous versions of WiX. A pull request awaits.

• Update registration disappears during upgrade., from @barnson, is a bug about patch update registration introduced in Burn in WiX v4. Update registration is used to write registry values that can be shown in Add/Remove Programs and documented for the detection of product updates. Burn took effort to ensure the registration was retained during upgrades; that effort was broken in WiX v4 and this pull request brings it back.

Old issue triage

We’re also triaging our old issues. Today we re-triaged issues that we’d previously triaged into our “holding pen” milestone of v.Future. The goal was to bring those issues into WiX a real milestone (e.g., WiX v7) or quit hoarding them and put them up for grabs for others to work on. We could also just close them as no longer a good idea.

And we did it: v.Future is now an empty, ex-milestone.

In future meetings, we’ll consider how we triage other open issues that we’ve accumulated over 20+ years. Some are old enough to vote and are probably obsolete. Others might be toddler-aged but also not really interesting. Let’s go through them, remember all the funny hairstyles from way back then, and clean up our issue tracker.