Today was another almost-two-hour dive, mostly into WiX v4 design discussions, first during triage, then during dedicated design-discussion time, and then at the end when Rob snuck one more question in. In the meantime, other software engineers, with help from their hardware buddies and the occasional rocket scientist, were waiting to see if their code successfully landed a robot on another planet. (It did!)
Issue triage
Alt key in wixstdba messes up the foreground/background of controls, from @wixbot, was an old issue that was resolved in WiX v4 and submitted for re-triage to see if the team would accept it into WiX v3.14. After a bit of discussion, the verdict was yes.
RegistryValues to the same registries cause LGHT0001, from @ElectricErger, is an issue I sent back for triage after some research to discover the underlying issue, which is that it's way too easy to author a multi-string registry value in a way that causes an error. We want the WiX language to guide you toward happiness and correctness whenever possible, so I proposed language changes that might accomplish that for multi-string registry values. I didn't include examples, however, so I think my prose explanations weren't illuminating enough. So I'm off to write a WIP to better describe my proposed language change.
When getting a files in use message on .NET chainer the response is wrongly returned to .NET installer, from @nirbar, suggests that the interaction between Burn and the .NET Framework redistributable installer is all wrong...at least for files-in-use messages. The documentation agrees so we took the issue into WiX v4.0.
BA requests get dropped when UI is shown on engine thread, from @rseanhall, brings the sadness that Burn's use of a thread message queue is problematic when a bootstrapper applications shows UI in one of its callbacks from Burn. Naturally, Raymond Chen, master of Windows arcana, knows the problem and solution: Use a hidden window for messaging instead. That's a bit of surgery in Burn innards but we took the issue in WiX v4.0.
Burn does not repair an MSI when slipstreamed with a minor update patch, from @rseanhall, speaking of arcana, combines patching, slipstreamed patches, and how Windows Installer installs and, if it does, repairs patches. As I have a fair bit of experience with patches and patching, I volunteered to enter once more unto the breach—do some more research, in this case.
Burn should support alternate hash algorithms and Burn update detection should supply hashes if present in update feed, both from me, came about from some recent excursions into self-updating bundles. We agreed that when Allow different hash algorithm to Burn is implemented, there's little reason to support other, lesser hash algorithms. I took issue 6353 to implement in WiX v4.0.
Should RegistrySearch and util:RegistrySearch follow the Compiler platform?, from @robmen, is a design discussion masquerading as an issue. We spent a fair bit of time discussing the uses of registry searches in both MSI packages and bundles and how they should or shouldn't change by default based on the bitness of those packages and bundles. Rob is taking that discussion to come back with a proposal.
Support for elevating Burn bundle extensions, from @bryand-recastsoftware, requests the ability for a bundle extension to be elevated, for when pesky dependencies block read-only searches to the registry or file system. It requires careful design but could be additive in WiX v4.x.
Patch seems to include more changes than was authored, from @rseanhall, is another "interesting" patching issue. Because being stuck inside poring over verbose MSI logs to figure out what a patch is doing is just what I need after a year stuck in quarantine, I volunteered to do some research on this patching issue too.
WiX v4 design discussion
Rob brought up an issue he's run into during recent WiX v4 work: WixUtilExtension, WixDependencyExtension, and WixTagExtension all add functionality to MSI packages but for Burn bundles, the runtime functionality is present in the Burn engine rather than the extension. Likewise, the core toolset needs to be able to build Burn bundles, so it needs special knowledge of the symbols generated when compiling authoring that uses those extensions.
One solution to that problem is to lift the concepts from those extensions into the core WiX language. On the opposite end of the spectrum is to move the Burn implementation into new bundle extensions (using the bundle extension support Sean added in Burn v4). Rob will continue investigating this as he works on his current work in extensibility in the MSI and Burn backends.
f