Today's supersized meeting was spent triaging issues, almost all of which are about WiX v4. Next meeting, we'll get back to triaging open WiX v4.0 issues to prioritize them for Preview Zero (coming soon!) and later.
Issue triage
util:CloseApplication is looking for process in all sessions, not only in current session, from @HamletHakobyan, requests the ability to restrict
CloseApplication
to the current user session. That's useful for both per-user packages and per-machine packages that don't care about applications running in other sessions. As it's an additive feature, we assigned it to WiX v4.x.Change how Burn sets the working directory for ExePackage, from @rseanhall, is a feature to clean up how Burn handles the current working directory for
ExePackage
s. We discussed the implementation a bit and took it as a WiX v4.0 change.Create log for ExePackage, from @rseanhall, is a feature to enhance logging for
ExePackage
s in Burn. There's a follow-up thread on wix-devs to discuss the details but we assigned the feature to WiX v4.0. Sean also wrote a WIP for this issue.Conditionally require DetectCondition for ExePackage, from @rseanhall, requests a change to require
DetectCondition
forExePackage
s in Burn. Without aDetectCondition
, Burn will always install the package and never uninstall or repair it. That's probably unexpected, so enforcingDetectCondition
(even if empty) will help users avoid the confusion. We assigned the feature to WiX v4.0.Add support for high DPI to the Burn engine, Take 2, from @rseanhall, is part of the work required to support HiDPI monitors in Burn bootstrapper applications. Sean wrote a WIP and started a thread on wix-devs to discuss options but we assigned the feature to WiX v4.0.
Accessibility: Name property is not being set for license terms, from @DaveTryon, is a report of an accessibility issue for screen readers and the WixUI dialog library. We're leaving the issue open until the next meeting in the hopes of getting expert accessibility guidance.
wixstdba Options page is broken in v4, from @rseanhall, is an old-fashioned bug, likely caused by me, for which I humbly accept responsibility. I'll get it fixed for WiX v4.0.
WiX should include
dotnet new
templates, from @barnson, suggests that, as WiX v4 is built on top of .NET Core, it should play along with .NET Core command-line tools. We assigned the feature to WiX v4.0.Add BalExtension BootstrapperApplications for x64 and ARM64, from @rseanhall, outlines the work required to add support for native x64 and ARM64 bootstrapper applications, once Burn itself supports x64 and ARM64. We assigned the issue to WiX v4.0 with details being hashed out in Sean's WIP and in a thread on wix-devs.
Burn engine should handle non-QWORD versions, from @rseanhall, prompted an extensive discussion about what exactly would be supported in "non-standard" versions. (Windows Installer, like Windows before it, really prefers numeric 1.2.3.4 versions.) Sean proposed in a WIP to support NuGet-style versioning, which is a bit of mashup of Windows numeric versioning and Semantic Versioning. As this is a breaking change, we assigned this issue to WiX v4.0.
Implement WiX v4 command-line output and Complete MOVE_TO_BACKEND #defines in linker, both from @robmen, is Rob opening issues in case he loses his scratchpad of things to be done as part of WiX v4.0 Preview Zero. So naturally we assigned the issue to WiX v4.0.
WiX v4 should have documentation, from @barnson, is me opening reminder issues because both Sean and Rob were doing it and I didn't want to feel left out.