Today's meeting happens on the 237th Constitution Day in the United States. (Technically, I'd argue that 17-September 1787 ought to count as the first Constitution Day.) Not to make this blog post overly political but it's important for me to acknowledge my unwavering support for the Third—and least controversial—Amendment: Soldiers are welcome; just ask.
Issue triage
Investigate the use of human-readable strings to generate upgrade code, from @barnson, is a holdover from last meeting, wherein Rob said he wanted to investigate it. Investigate he did, and he volunteered to take this issue and fit it in with his concept of a "package id." We look forward to the resulting cohesive concept.
Regression: Localization variables no longer support a . (dot) in the Id, from @philipp-naused, reports the sadness that localization string ids are no longer resolved if they contain an embedded
.. Happily, @bevanweiss has already provided a pull request to fix this issue—coinciding with Rob and I being extra busy and woefully slow in reviewing pull requests. We'll get there, swear.Remote Launch Fails on Server 2022 and Windows 11 Systems that have been STIGed., from @cornerbowlsoftware, reports a Burn failure running a bundle on a machine that's been subjected to _EXTREME!_™ lockdown. The issue is hosting discussion about the root causes and possible workarounds. The challenge is to handle the extreme scenarios without affecting the mainstream ones. I assure you, we're up to the challenge.
Add ability to opt out of path validation custom actions in WixUI at build time, from @barnson, came from my work to replace the EULA printing custom action with the native
MsiPrintcontrol event. If you can get rid of one custom action, maybe you can get rid of two—which in this case, is all of them. Now that a compiler extension is required to include a WixUI dialog set in a package, we have extra power to compose the WixUI authoring. I decided it's worth investigating to see how much effort I'd have to expend to successfully kill off another custom action.WIX0103 Cannot Find File Error in wixlib project, from @weberms, reports a failure when trying to reference files in a binary .wixlib from another binary .wixlib. A single "hop," from a binary .wixlib to a package that consumes its files, works well. (If it didn't, you couldn't use most WiX extensions, so we'd notice pretty quickly.) That gives us confidence the root cause is one of those annoying-but-simple bugs with a one-line fix that requires way more effort in writing appropriate tests. The issue is
up for grabsfor an interested party.WiX 5 Bootstrapper - Upgrading installer leaves two entries in Add/Remove Programs Dialog when Log element specified, from @IanSwatton, reports that a disabled log prevents a complete uninstall during a major bundle upgrade. I needed to sit down and really come to terms with the idea that, in this particular case, logs would actually not help diagnose the problem. As it obviously freaks me out, I didn't volunteer for this issue and it is now
up for grabsfor a soul braver than mine.Files element ignors first letter of root folder names when pointed to subst folder, from @chrpai, suggests that trying to harvest an entire drive worth of files doesn't work. Sounds like an off-by-one error snuck in. Sounds like an off-by-one error snuck in. I volunteered to fix it.
What's the Package/Scope default? (perMachine, perUser, perUserOrMachine), from @forderud, is an issue that questions why the WiX upgrade in HeatWave removes an attribute and then questions why the attribute's default value isn't documented. The answers to both questions are closely related: The upgrade process removes attributes when their value is the default—because the world would be too verbose and boring if you had to be explicit about everything. (For the record, the default value of the
Package/@Scopeattribute is, indeed,perMachine. The documentation now reflects that.)Wix 5 Standard BA - bal:Condition not localizable anymore, from @gvkries, says that you can no longer localize the "launch condition failed" message in a WixStdBA-based bundle at runtime. It looks like that feature was lost in WiX v4.0. The issue is
up for grabsfor an interested party to restore.