WiX Online Meeting 291 Highlights

Retirement

WiX v3 and WiX v4 go out of consumer support the first week of February. The WiX lifecycle lays out the dates and the date formulas used to determine the consumer-support lifetimes. (FireGiant customers get extended support lifetimes because our love language is supporting our customers making great installers.)

Up next

WiX v6 development continues apace. We triaged issues that are targeting WiX v6-rc.1---we moved a couple issues out of v6 and moved a couple of issues into v6. Everything looks good at the moment, but, with two versions of WiX retiring at the same time as our original scheduled date for WiX v6-rc.1, we decided to push that out a week. Its new date is 12-Feb-2025, so set your calendars to pick up that release and run all your WiX v5 code through it. And if you still have WiX v3 or v4 code, WiX v6-rc.1 is a great time to update. Remember that finding bugs happens before release; after WiX v6.0 ships, bugs you find will queue up for WiX v7 next year---except for FireGiant customers; see above paragraph re: love language.

You don’t have to go home, but you can’t stay here

Everybody loves to complain about documentation. (I started writing back in the olden days when software came with printed manuals---and people complained then too.) WiX v4 changed the schema of the WiX language, so a lot of documentation for WiX v3 appears to be obsolete. (Hint: It’s not, for the most part; there are some highly-visible changes in the WiX language around, for example, Product and Package, but huge swaths of the language are almost completely unchanged.)

With limited resources, Rob and I both have chosen to focus our volunteer time on WiX in areas where having 20 to 25 years of experience in WiX and MSI has the most effect: In WiX itself. Rob wrote about this very topic a long time ago. Thanks to WiX’s open-source license, we’re not in a privileged position when it comes to writing documentation; we’re just more familiar with the material.

One might hope for lots of open-source documentation contributions, but, alas, significant improvements or additions have been rare. So it falls to us and, because some people are blaming FireGiant for the lack of doc, FireGiant is taking on some of that doc challenge. Soon, the WiX documentation will move to a new FireGiant documentation site, which makes it easier for us to combine things like the WiX tutorials with other WiX doc. We’ll take great pains to add redirects so everything keeps flowing.

Moving meetings

Rob proposed moving this meeting forward 25 hours: Instead of the third Tuesday at 0930 Pacific Time, the WiX Online Meeting will now be held on the third Wednesday of every month at 1030 Pacific Time. (Pacific Time right now is UTC-8, but becomes UTC-7 for March’s meeting.) Our February meeting is 19-February at 1030 PST.

Triage

• A PendingFileRenameOperations entry is present after Burn exit., from @DS-AndOrz, came back to face the triage gauntlet because a volunteer contributed a pull request to fix the issue. Love to see it!

• A dummy short file name generated in RemoveFile that might cause a wrong file to be deleted, from @nirbar, came back after Rob reviewed the issue. In the end, we decided that following MSI’s rules about file names---where 8.3 file names are still required, even in the 21st century---was more important than the very small chance of matching a hash-generated short file name. Remember, the needs of the many outweigh the needs of the few.

• Using ParallelCache in Bundle creates errors in log file, from @petm2022, came back because I reviewed the Burn engine code and concluded that the engine has no mechanism for the thread executing the plan to wait for the thread caching payloads to cache a particular payload. I dismissed my initial idea of having an event for every payload that the execution thread could wait on as a horrible one, so back to triage it went. Rob came up with an idea more efficient by a couple orders of magnitude, so I’ll take that and run with it in WiX v7.

• Defer removal of upgrade related bundles until the next session, from @joeloff, came back after Rob did a first pass of investigation, with some notes and questions still to be written.

• WixLocalization Culture Invariant Breaks Build, from @chrpai, points out how imprecise documentation can lead to confusion. The doc says that “language neutral localization files are always included” but there’s a subtlety when it’s the only external .wxl file in a project using embedded .wxl files, such as from WixToolset.UI.wixext. Supporting that mix-and-match model would be useful, so we’re leaving this issue open and up for grabs.

• Investigate Fix default feature to respect sections. alternative fixes, from @barnson, is an issue I opened because of comments Rob left on a pull request. I’d like to get this issue resolved, so I volunteered to hound Rob for a discussion of the underlying problem.

• ErrorDlg not showing runtime exception, from @Rajagurunathan-M007, shows what happens when custom error messages aren’t included in an MSI package. They should be included, so I volunteered to fix this issue.

• Auto-generated component GUID for registry is incompatible with WiX3, from @nirbar, is an issue we’ve run into elsewhere that Rob is fixing for WiX v6 by reintroducing the -bcgg (backward-compatible GUID generation) command-line switch, which was introduced during development of WiX v3.0 for users of early prereleases of WiX v3.0 that had already shipped installers built with it. So, yeah, the first release of WiX v3.0 already had a switch for backward compatibility with earlier iterations of itself.

• Custom action ID is not updated in some attributes when converting from WiX 3, from @philipp-naused, suggests other spots where the wix convert tool could update the ids of the custom actions in WiX’s own extensions.

• msmq:MessageQueuePermission are not applied, from @MBroholmA, is a bug that someone introduced in WiX v4 and got noticed---along with multiple volunteers to provide a fix.

• Consider (re-)re-targeting DTF, from @barnson and Consider targeting .NET 8, both from yours truly, came about as I did a fresh OS install this weekend. DTF targets .NET 2.0, which requires .NET Framework 3.5 to be installed on developer machines, which hasn’t been installed by default in ages. WiX v6 targets .NET 6, which is no longer installed by Visual Studio 2022. If you’ve been working on the same machine(s) for a while, you probably already have them, so it’s only noticeable if you’re setting up a new machine. We took these as the first things to do in WiX v7.

• Functionality to harvest a directory for a payload from MSBuild, from @brantburnett, requests new functionality in Heat. As described in Emit deprecation warning for Heat, Heat is deprecated and will show warnings in WiX v6 and will be removed in WiX v7. So, no. I humbly suggest that the functionality behind the lovely Files element would make a great addition to the WiX language for payloads.

• Emit deprecation warning for Heat, from @barnson, is me saying “hey, we’ve been saying Heat is deprecated so we should tell everybody that so nobody can say ‘but you never told us’.” And, apparently, some people don’t seek out my mellifluous voice and writings, so let’s put it up front in a warning.

• Harden Burn’s BootstrapperApplication and elevated engine extraction, from @robmen, suggests further defense in depth that Burn can take to significantly reduce the window when bootstrapper application payloads could be tampered with by malware. As we spent so much time in 2024 reacting to security issues, being proactive to avoid them entirely is a refreshing change for 2025.