WiX Online Meeting 290 Highlights

It's not news to all the many faithful readers of these Highlights, but Rob wrote it down for those who aren't as enlightened: There's a predictable lifecycle for our annual WiX releases with security updates to keep both FireGiant customers and consumers safe. Read all about it!

Issue triage

Using ParallelCache in Bundle creates errors in log file, from @petm2022, suggests there’s a race condition in Burn’s caching layer. Race conditions being notoriously fun and easy to debug, I volunteered to investigate.
void IBootstrapperEngine.Log(LogLevel level, string wzMessage) throws System.Runtime.InteropServices.COMException and BootstrapperApplicationRun method throws System.Runtime.InteropServices.COMException, both from @EvgenPervenenko, report exceptions being thrown from deep in the bowels of .NET for a managed bootstrapper application. While it’s possible there are bugs lurking in the WiX helper code for managed BAs, interop exceptions like these really need a debugger to figure out what’s going on so there’s not much we can do here without more information, or, better yet, a live repro.
Migrating a wixproj from v3 to v4 causes invalid MSI file when using harvesting., from @NiceLuc, isn’t a WiX issue, per se, but possibly an incomplete conversion of Heat-based project harvesting by HeatWave, from those smart and charming folks over at FireGiant.
Performance of generating installer between Wix5 and Wix3, from @fforjan, comes from comparing build times between a WiX v3-built installer and one converted to WiX v5. As the default compression level changed in WiX v4, I’m betting that’s the difference and will continue to believe that until or unless the reporter comes back and says I was wrong (theoretically possible).
Files added to Module fail with ICEM05 error, from @momchilstefanov, is an error introduced with the naked File and Files elements in WiX v5. To be fair, the problem happens with merge modules, with which I have an unfortunate, sad, and often frustrating history. If I’d known 20 years ago that Rob was the original author of the merge module specification, I might have reconsidered attending that first WiX meeting…Anyway, I think I know what’s missing, so I volunteered to add it and fix the issue for WiX v6.
Defer removal of upgrade related bundles until the next session, from @joeloff, is a WIP with a design for a new mode of Burn, to better handle files in use and the (potential) resulting state of having a mishmash of files from different versions of the bundle’s packages. This is addressed with a reboot, which I’m sure everyone reading these words takes immediately, regardless of how disruptive they are. (I got a video driver update two days after last week’s Patch Tuesday and swore vengeance for two reboots in a month. My, how times have changed.) Rob volunteered to read and contemplate the design, but we’re both agreed this is a problem, especially for platforms like .NET, that Burn can and probably should address.
error WIX0200: unhandled extension element ‘WixStandardBootstrapperApplication’ when building with VS2022 17.13.0 Preview 2.0, from @vbaderks, reports a problem introduced in a preview of Visual Studio. Sometimes these changes are rolled back or conditionalized and sometimes Visual Studio extenders end up needing to accommodate. We’ll see which flavor this change is and whether those FireGiant geniuses need to handle it.
Wix3 heat version 3.11 and heat version 3.14 produces different output because of different config file, from @bbuerger, reports one of the differences between WiX v3.11 and v3.14, one of which was dropping the requirement of the oh-so-very-old .NET Framework v3.5.1. That changes behavior in harvest at least some assemblies. WiX v3 goes out of consumer support for security fixes in less than two months---and this issue isn’t a security problem anyway. So we’ll close this issue, allowing its words and links to be absorbed by search engines and hallucinated by “AI” engines for posterity.
Improve upgrade documentation, from @CodeAndWeb, requests documentation on how a per-user elevated package built in WiX v3 can’t be upgraded by a per-machine package in WiX v5. That’s a two-headed problem: It was too easy to create per-user elevated packages in WiX v3 (which we fixed in WiX v4) and MSI doesn’t support “cross-scope” upgrades between per-user and per-machine. It’s worth a warning sticker, at least.