WiX Online Meeting 281 Highlights

In the past three weeks, we shipped a bunch of security releases, a WiX release candidate, HeatWave and HeatWave Build Tools releases, the WiX v5 release, and celebrated the 20th anniversary of the first time WiX was publicly available. Yeah, yeah, time to quit slacking...

WiX v5 released

When last we left our intrepid heroes, exhausted from multiple security releases and finalizing WiX v5...they did it! WiX v5 shipped as planned on the 20th anniversary of WiX's first open-source release, way back in 2004:

• v5.0.0-rc.1 on 8-Mar-2024 (done!)
• v5.0.0-rc.2 on 22-Mar-2024 (done!)
• v5.0.0 on 5-Apr-2024 (done!)

WiX v6 schedule and Git strategy

As the two-release-candidate-and-an-RTM schedule worked well for WiX v5, we're using it again for our next annual release, WiX v6:

• v6.0.0-rc.1 on 4-Feb-2025
• v6.0.0-rc.2 on 4-Mar-2025
• v6.0.0 on 5-Apr-2025

Development of WiX v6 continues in the wix repo on GitHub as it did for WiX v4 and WiX v5. One difference is that we've moved away from the GitFlow branching model to a variant of ReleaseFlow. For WiX v6, all development happens on the main branch and we'll create branches for releases, as needed, and cherry-pick commits into those release branches.

We'll start putting together our plans for WiX v6 and discussing them in future meetings.

WiX lifecycle update

If there's one thing we learned from all the work we put into the WiX security releases this year, it's that the more releases we need to make, the crazier they make us. The WiX maintainer team is (collectively) smarter than your average bear, granted, but it's still just the two of us. As we move into our new annual-release model, we need to also cut back on how many releases we support. So here's how it will work going forward:

• If you're a FireGiant customer, consult your support contract -- that determines your support, bug-fix, and security-fix lifecycle for all versions of WiX.
• If you're not a FireGiant customer, then:
  • You should test WiX release candidates as soon as they're available. Bug reports we receive during the release candidate phase are likely to get fixed or at least documented. That happened several times during the WiX v5 release candidate phase.
  • Bugs reported after a major version has been released are candidates for the next major version and only rarely in the just-shipped major version.
  • Security fixes will be available for 10 months after the next major release, so given our annual release schedule, that means 22 months of security-fix support.
• Maintainers (:waving_hand_emoji:) may create patch releases to backport security fixes, customer bug fixes, and other bug fixes that, in their discretion, are high priority (important, embarrassing, annoying, the magic 8 ball said so, and so forth).

In short, if you're a customer, you're covered and if you're not, your best bet for prompt bug fixing is to find your bugs and report them during the time of the release candidates.

Issue triage

• Files-In-Use checking picks up files that correctly handled by the uninstall, from @wixbot, came back to our attention with the detail that ordering ServiceControl rows affects MSI's ability to properly detect that a running service will be shut down by one of the aforementioned ServiceControl rows. That, of course, is crazy...but just crazy enough to be real. Unfortunately, without an explicit column like Sequence, there is no guaranteed order for reading rows for MSI tables. Still, WiX could do what's possible to try to get the rows in a particular order, so this issue is open to investigate that idea.

• Overwrite="no" not working for certificate element, from @kennethgracilla, came back and as Jacob was in attendance, he volunteered to take a look at the issue.

• A second bal:Condition fails the bundle although evaluating to true, from @tda-ableton, was one of the last-minute WiX v5 bugs that Rob fixed after WiX v5.0.0-rc.2 was released.

• Files element sometimes add source path into target directory, from @barnson, is another post-v5.0.0-rc.2 bug with a pre-v5.0.0 fix.

• Setting the "Scope" property to "perUser" results in an unexpected INSTALLFOLDER path, from @antoinebj, combines two issues: MSI automatically retargets directories when using its support for packages that handle both per-user and per-machine scopes -- but not when using a strictly per-user package -- and Burn's current inability to handle dual-mode packages. Rob volunteered to take a look at the former for WiX v6 and I'm curious about tackling the Burn issue, though probably not until next year, for WiX v7.

• Icon no longer displayed in the Burn bundle window title and Windows taskbar after upgrading to WiX 5.0.0, from @doomlaur, is a bug introduced by moving bootstrapper applications out-of-process: Other processes won't inherit the parent bundle's icon without some extra work. Rob volunteered to fix this in WiX v6.

• Bundle generates WIX8011: Failed to update resources in the bundle after upgrade to 5.0.0., from @RichardJFoster, reports our favorite error (#5) when the build process tries to stamp version resources in the bundle .exe. Unfortunately, I couldn't reproduced it using Visual Studio, MSBuild, or dotnet build. Naturally, overly aggressive real-time antivirus is always a viable culprit, as they like to lock executable files while they subject them to interrogation about their known associates and plans while visiting. Here at FireGiant, I'm well-known for recommending use of Process Monitor to, you know, monitor processes and pinpoint the guilty party for unnecessarily locking files.

• Overriding scheduling of FindRelatedProducts results in error WIX7009, from @avivanoff, is fallout from the introduction of virtual and overridable symbols in WiX v5. All the standard actions are virtual (overridable) by default but the language used to express the scheduling of standard actions doesn't let you indicate an override of the default scheduling. Rob volunteered to fix this.

• Default major upgrade is not working if ProductSearch is used, from @smilinger, reminds us that WiX a native ProductSearch element, in addition the one introduced more recently (~12 years ago). The native ProductSearch element creates a row in the Upgrade table with the "detect-only" flag set. The default major upgrade is supplied if there are no rows in the Upgrade table -- but detect-only rows aren't "real" upgrades and shouldn't enter into the decision to supply the default major upgrade. I volunteered to make the default major upgrade a bit smarter in WiX v6.

• WiX v5 auto-harvest file conflict errors should be more meaningful, from @NEngelberth-Nucor, suggests that getting an error referencing an id generated from a hash of unknown source material could be more useful. Sure, I suppose. The problem in this case is that duplicate symbols are detected in the linker, well past all the rich data available in earlier phases of the build. It should be possible to do more duplicate detection in the optimize phase of the build so better error messages are possible. That's not on my radar for WiX v6 so the issue is up for grabs for someone looking to scratch that particular itch.

• WiXToolset.Dtf.WindowsInstaller No Longer Supports .NET prior to 4.6.2, from @chrpai, comes from a choice we made in WiX v5 to cut the "tail" of .NET Framework versions that Microsoft no longer supports -- meaning that net462 was our lowest version. But as DTF currently needs only .NET 2.0 support, and .NET Framework 3.5SP1 is supported for another five years, Rob agreed to retarget DTF for net20.

• WiX UI Dialogs not appearing in the taskbar when using WixInternalUIBootstrapperApplication, from @davidneale, reports that, somehow, WixInternalUIBootstrapperApplication manages to keep Windows Installer internal UI dialogs from appearing on the Windows taskbar. That's an impressive trick. The issue is up for grabs for someone to discover the magic involved.

• WixStdBA: Options - Browse opens folder browser dialog in My Documents instead of predefined path (or its parent), from @dallmair, requests that when you click the Browse button on the WixStdBA Options page, the folder picker go to the directory associated with the edit control the button is neighbors with. WixStdBA could do that, so up for grabs it goes.