2021 continues to be The Year of Long Meetings, as we had a good number of issues to triage and discuss and a big Burn pull request from Sean that Rob reviewed in real time for your viewing pleasure.

Issue triage

  • Dependency v4 - Binder isn't implemented, from @rseanhall, came up for triage at Sean's request. Rob agreed to resolve this as part of WiX v4.0 Preview Zero.

  • New minimum OS for v4, from @rseanhall, is looking for a declaration of the lowest version of Windows WiX v4 will support. The OS matrix for WiX is split across build tools (e.g., wix.exe and MSBuild tasks) and runtime code (like Burn and the WiX custom actions). Given the (paid) availability of extended security updates for Windows 7 and Windows Server 2008, OSes that would normally be out of support are being kept alive and supported until 2023. So that's our bar: If the OS is supported, the runtime parts of WiX should continue to work as they did in WiX v3. The build tools might require more modern OSes, given that developers often already have the latest and the greatest anyway. However, even though WiX v4 itself is built with .NET Core, some parts, like the MSBuild tasks, are available for .NET Framework. That should help keep WiX v4 running on older OSes.

  • Enhance ability to enable debug level logging in Burn, from @rseanhall, is a follow-up to one of Sean's issues from last week: Include PlanDump in release builds of Burn, which he already implemented. Because the plan dump happens at debug logging level only and today only admins can trigger it via MSI policy, we said last week there should be a way for a user to trigger debug logging level. I volunteered to take this bug, because implementing the /xlog switch sounds cool.

  • Remove CacheId attribute from bundle package elements, from @rseanhall, suggests that the CacheId attribute is dangerous, difficult to use, and probably shouldn't be exposed. But sometimes the dangerous and difficult to use features are the ones that save the day when they're needed. Rob and I have both seen CacheId used correctly, so we're loathe to remove it entirely. We postponed deciding how to deal with this issue to see if there's a way to make users sign a waiver that they know what they're getting into.

  • WiX burn engine fails to download over HTTP when HEAD request results in 404, from @guban, suggests that when downloading files, Burn should ignore the failure of a HEAD verb, because sometimes somebody else's computers (aka The Cloud) are configured to not support HEAD. Rob volunteered to investigate the feasibility of not using HEAD or maybe optionally using it when necessary.

  • Document all public types and members, from @barnson, provides the gentle suggestion that the public types in WiX assemblies should be documented. Documentation, well known as the favorite part of any development project, is usually lacking for these "internal" parts of WiX. This will be an ongoing effort that will probably never be "done."

  • Backends shouldn't need to reference WixToolset.Core, from @rseanhall, prompted a philosophical discussion about how interfaces and the concrete types backing them should be exposed. A big change from WiX v3 to v4 was reducing the big-ball-o'-classes that was wix.dll with more types exposed via interfaces across multiple, logically-split assemblies. It's likely we could do more along those lines, so Rob volunteered to take a look.

Pull request review

Sean opened a pull request that, among other things, fixes the long-standing request that installing a bundle that requires .NET Framework as a prerequisite shouldn't leave the bundle registered until the "real" product is installed. Naturally, such a minor tweak resulted in hundreds of lines of code changes. Sean broke the change into multiple commits and walked Rob through each of them. I occasionally nodded sagely and eventually realized there's no video. Take a listen.