WiX Online Meeting 294 Highlights

WiX v6

WiX v6 shipped as scheduled on 7-April. (The nominal release date for WiX annual releases is 5-April but weekends can interrupt that schedule. WiX v7 would ship on a Sunday, so we might have to wait until WiX v8 on Monday, 5-April-2027 to get back on schedule.)

WiX v6 is the first release of WiX to ship binaries with an Open Source Maintenance Fee EULA. Show your appreciation for those hard-working, brilliant, and humble open-source maintainers.

Also of note is that HeatWave v1.0.6 and HeatWave Build Tools v6.0.0 are available with support for WiX v6.

Issue triage

• Investigate Fix default feature to respect sections. alternative fixes, from @barnson; Default feature attempts to include components defined in unreferenced fragments, from @mediawolf; Spurious WIX1113 for advertised Shortcut nested in naked File, from @chrullrich; ICE17 Button is a Do Nothing Button, from @chrpai; IEngine.SetDownloadSource out of date, from @barnson; and IEngine.SetUpdateSource out of date, from @barnson were issues opened between last month’s meeting and the release of WiX v6. They were all fixed for the WiX v6 release so we’re not really triaging these issues, but merely noting their existence and peaceful resolution for posterity—and highlighting that reporting bugs during the release-candidate phase of a WiX release can and does result in bug fixes shipping in that release. Other bugs we triaged today were reported only after the release and now have to wait for a release.

• Support install-time bundle scope is a feature I’m proposing to add support to Burn for switching between per-user and per-machine bundles as a user choice at install time. There are still some open questions to be resolved but after my research, I’m comfortable I can implement this in the WiX v7 timeframe. Wish me luck.

• v5: Burn engine fails to elevate, from @MatthiasRInst, is an issue opened from discussions happening in the GitHub Discussions area. The problem is intermittent and challenging to debug but we’re hoping to get more eyes on the problem.

• Directory symbol ‘TARGETDIR’ conflicts with a virtual symbol in a Merge Module, from @chrpai, reports confusing messages when using “legacy” directory authoring. WiX v4 simplified directory authoring by eliminating the need to expose the MSI concept of TARGETDIR. There’s a warning message recommending the use of the new-to-v4 StandardDirectory element but we agree that TARGETDIR could get its own targeted message saying that it can simply be omitted. I volunteered to add those words.

• WiX 5 Bundle project unexpectedly fails to build when NUGET_PACKAGES environment variable exists, from @KutanaDev, suggests that there’s a problem when using the environment variable that lets you redirect NuGet package storage from its default location, filling up your C: drive. I can label this issue works_on_my_machine because I use NUGET_PACKAGES to keep my C: drive tidy (and to take advantage of Dev Drive to tame wild antivirus scanning). But this particular issue reports that NUGET_PACKAGES is pointing to a network share. That introduces another layer of complexity that I’m personally happy to avoid in favor of speedy local storage, please and thank you. So this issue is up for grabs for someone interested to investigate.

• ArpEntry fails to uninstall when UninstallString uses rundll32.exe, from @nirbar, highlights the truly bizarre fact that some custom installers register themselves in the Programs and Features app (known as ARP to old-timers) to uninstall using rundll32.exe. Why any software would do that is beyond comprehension. But at least one does and we agreed that Burn should support it, albeit distastefully. @nirbar provided a pull request, which Rob volunteered to review.

• Upgrading to Wix Toolset v6 Causes Build Exception, from @oollie34, is my annual opportunity to fix a bug that I introduced and that should have been caught in a release candidate. The root cause is using Files when having multiple unnamed bindpaths, but you get one unnamed bindpath for every ProjectReference in your .wixproj. So it happens easily and I lament that it wasn’t caught in a release candidate. The fix, with tests to detect the root cause, is out for review.

• WixBundleSourceProcessPath and WixBundleSourceProcessFolder should be resurrected, from @barnson, requests that a couple of bundle variables come back. WixBundleSourceProcessPath and WixBundleSourceProcessFolder are variables that were introduced with the Burn clean room and removed with the removal of the clean room (in WiX v5 due to bootstrapper applications no longer running in the Burn process). But they’re generally useful even without the clean room. I helpfully provided a pull request that brought them back.

• Heat is deprecated and should be removed, from @barnson, is my request to get Heat out of the WiX build, now that WiX v6 has shipped. Heat has a long history in WiX; it was introduced in WiX v3 with some grand ideas but most never came to fruition. Did you know that Heat was originally envisioned as extensible to harvest data from sources like IIS and the Windows Firewall? That didn’t work out, and the extensibility came at a complexity cost, one that is overkill given that it’s mostly used to harvest files. So we bid it a “fond” farewell and remember that it will stay available on NuGet.org forever [citation needed] and will keep working as long as the WiX compiler keeps accepting the WiX v6 language.

• Support setting Platform via Runtime Identifier, from @robmen, came from a rude user being rude but with a kernel of a useful suggestion, which is that the dotnet build switch --arch for selecting output architecture should work for WiX outputs too. Rob’s interested enough to make it work in WiX v7.