Our meeting last month was mostly a no-op due to Rob being out of commission with a case of imbalanced humours. So our meeting this month meant that we had two months of accumulated issues to triage. All the data suggests that one month between meetings is fine but two months is way too long. (All the data includes how long it's taken me to write up these highlights.) Our next meeting is scheduled for 17-September.

Issue triage

  • Investigate using MsiPrint over EULA-printing custom action in WixUI, from @barnson, popped into my head as a way of avoiding the complications of architecture-specific custom actions in customized WixUI dialog sets. Getting rid of custom actions is a good idea in general, and here it will also shrink MSIs that use WixUI, by some miniscule but measurable amount. I picked this up for a future release of WiX.

  • Investigate the use of human-readable strings to generate upgrade code, from @barnson, is the end result of our long-standing War on GUIDs.™ The upgrade code is the final required GUID in a typical WiX package; all the rest can be generated, so what if we do that for the upgrade code too? After all, any arbitrary string can be transmogrified into a GUID with a dash of hashing magic. Rob realized this idea meshed well with his background thinking about the concept of "package identity" and volunteered to think about how they could meld together. Stay tuned.

  • Unnamed bindpath not respected, from @Emdot, suggests that the documentation on the Files element doesn't reflect reality when it comes to its behavior around unnamed bind paths. While reality is overrated, the doc should be correct. I volunteered to take a look and see what's wrong. Coincidentally, I'm also going to look at the also-documented-but-working behavior when there isn't an unnamed bind path: I'm having second thoughts that defaulting wildcards to the directory of the WiX source file is a good—or useful—idea.

  • Package version incorrect, from @smaudet, wants package versions to be processed as literal strings. That's how it worked in WiX v3, but later versions normalized versions, which doesn't change the behavior but does eliminate insignificant zeros—v01.02 is the same as v1.2 in the world of versions. Rob decided to go back to the old behavior effective in WiX v6.

  • Temp env variable not respected in WIX 3.14.1, from @vkacharaya, requests that an administrator-specific temporary directory be used for a bundle's temporary files. That's useful to alleviate disk space concerns and Burn does use them in some cases—but security trumps all...or at least most. For example, a bundle running as the system account prefers the SystemTemp directory if it's available (on newer versions of Windows); another directory is less secure. When that's not the primary concern, a different order for preferred temporary directories is something we'd consider after thinking through the security implications.

  • Allow Merge Module inclusion with default feature, from @mgaffigan, asks that files from merge modules should be in the default feature (from the default feature-feature we introduced in WiX v5). I'll be honest—that never even occurred to me. Merge modules just feel so...early 2000s. Had it occurred to me, I would've gotten annoyed because it turns out that the merging of merge modules is tied pretty closely to features. So this issue is up for grabs for someone who wants to work out how to get these features to play well together.

  • Schema doc omits attributeGroup documentation, from @barnson, came about I went looking for some doc I knew existed but couldn't find it. Turns out there's a bug in the tool that turns our .xsd schema files into Markdown to be lovingly consumed by the wixtoolset.org site build. Rob volunteered to make a fix.

  • Files element requires the "Keep empty directories" attribute., from @toshiyukiohshima, requests that one of the more esoteric features available in Heat be available when harvesting using the Files element. We're declining this request and will be pretty hard-core about features that are part of the core WiX language. "Just add a switch" is how you get confusing, hard-to-use features.

  • TouchFile fails due to 64-bit initialization, Managed CustomActions leave behind SFXCA folders, Produce a wix-cli.msi, WixToolset.Firewall.wixext missing version information, and wix extension list does not display machine-wide extensions, all from @robmen, and Build Error [NuGet security analysis]: Package 'System.Text.Json' 4.6.0 has a known high severity vulnerability error when attempting to build from fresh git clone, from @bevanweiss, are all minor issues that Rob fixed in WiX v5.0.1. WiX v5.0.1 shipped last month, so all these issues are already fixed and released, and really didn't need to be triaged, per se, but we're already triaging so many issues, what's a few more?

  • .NET 4.8 Redist signatures have changed -- causing install failures, from @muj-beg, is a sad recurrence of a problem we keep running into with redistributable packages like .NET Framework: When files are updated without changing the URL, hash validation (Burn's default) is broken. So we switched for well-known redistributables like .NET Framework to using the signing certificate thumbprint—which worked until the thumbprint changed. This problem needs solving—after we figure out what the solution might be, that is.

  • Package with MSMQ custom action fails to install, from @djohnst10, reports a bug introduced in the WiX v4 Great Architecture-Specific Custom Action Rename that wasn't noticed until now. (Perhaps that is an indication of the popularity of MSMQ?) Thanks to @bevanweiss for the pull request that fixed it!

  • Util User: Not able to create Domain user in standard usage, from @bevanweiss, wants to be able to create domain users, which requires the network permissions of a domain administrator; the user-creation custom actions run non-impersonated, which is great for users local to the machine, but won't do for domain users. That needs a set of impersonated custom actions, which @bevanweiss has a pull request for review.

  • Schedule actions based on symbols and tables, from @barnson, is a behavior change between WiX v3 and WiX v4. Extensions can ask WiX to make sure that a given table is present in the output MSI, even if it's empty because there's nothing that adds rows to that table. In WiX v3, the presence of a table, even empty, would also schedule standard actions that MSI documents as required for that table. WiX v4 instead schedules standard actions based on symbols, which is great unless your package doesn't have rows for that table. So I volunteered to make that work.

  • Files element require registry key under HKCU and listed in the RemoveFile table, from @EvgenPervenenko, is a feature request masquerading as a bug, asking that when using the Files element to harvest files going into a per-user location, Files should do the work that the Windows Installer ICEs say you should do. (If you don't, the ICEs yell at you.) This is a nontrivial request but I find it interesting enough to start thinking about, doodling ideas in a fine notebook with one of my fancy pens.

  • ExtensionValidation: Early check on valid Table Name, from @bevanweiss, suggests that an extension should generate an error if it tries to create a table with an illegally-long name rather than finding out only at runtime. That's a fine idea and @bevanweiss also submitted a pull request.

  • .NET Core bootstrapper shows a popup to download .NET runtime despite having it included as a prerequisite, from @Scalibq, is a bug, but in the doc, not the code. Rob volunteered to write some corrective English.

  • Validate that generated GUIDs don't change (and stay compatible across WiX versions), from @barnson, is a bit of a hygiene issue—generated component GUIDs are stable because they have to be but we don't actually test that. Should the GUID-generation algorithm accidentally change, a failing test is a good backup. (And given an intentional algorithm change, a failing test is a good reminder to document the breaking change.) Rob volunteered to write the tests.

  • Adding "Id" attribute to BootstrapperApplication breaks the bundle, from @drolevar, reports the weirdness that specifying a particular Id in your WiX authoring results in a failing bundle. Rob volunteered to fix this particular weirdness.

  • Naked Files can result in WIX0095 errors in mysterious circumstances, from @barnson, came from some unusual error messages I ran into when using "naked" File elements. After digging and sweating, I discovered a weakness in the ids that naked Files generate. The fix is out in a pull request.

  • Increase build parallelization, from @barnson, is an "epic"-level issue to track efforts to make the WiX build faster. Back in the WiX v3 days, with parallelization and some tweaks, I was able to get a clean debug build in under 30 seconds (with WiX v3 days-era hardware). Then we had to go and ruin things by adding tests! No, wait, I love tests, but they are a significant contributor to the much lengthier build times in WiX v4/v5/v6. The other significant contributor to build times is the overall lack of parallelization in the build. It turns out those two things are related. Switching to newer test frameworks would make it easier to build WiX using MSBuild traversal projects running in parallel—including the tests themselves. I took the issue to start the whole effort.

  • Patch build tries to set non-nullable field to null when deleting row, from @barnson, is a problem in pure-WiX patching that I discovered while, unsurprisingly, creating some patches. Rob's our patchmaster so you might think he'd be the perfect volunteer to fix this issue. However, in an odd setup-related twist on "they who smelt it, dealt it," Rob suggested that as I discovered the bug, I'm the best one to fix it. Naturally, a great comeback occurred to me hours later but by then, it was too late.

  • Setting InstallLocation, InstallSource in the bundle ARP entry, from @dliakh, requests the ability to set the InstallLocation and InstallSource values that are stored in the registry. (They're visible as columns in the old-school Programs and Features Control Panel applet, formerly known as Add/Remove Programs, also known as ARP.) InstallSource might not be of much use these days and bundles already have their entries in the package cache. InstallLocation is more interesting; for MSI packages, you can set the ARPINSTALLLOCATION property to have MSI write InstallLocation for you. Something similar could be done for bundles too so this issue is up for grabs.