Today is our last Online Meeting of 2023. Our normal fortnightly schedule would have us meeting on 26-December, but as the week between Christmas and New Year's Day shouldn't require changing out of pajamas or speaking to other people, we decided to start the new year out fresh and have our next meeting on 2-January-2024. See you then!
ArpEntry doesn't read UninstallString and doesn't support additional arguments, from @nirbar, came back after the triage from last meeting for some additional discussion after Nir and I had some discussion in the issue thread. Nir pointed out the risk of specifying the entire command line, given that it runs from the elevated Burn engine. Rob and I whittled it down to two features: The ability to specify additional arguments to the uninstall command line (for both quiet and "noisy" command lines) and the ability to specify whether to use the aforementioned quiet and "noisy" command lines from the
UninstallARP registry key.
WiXCop v4 Upgrade leaves DestinationLongName alone, from @chrpai, reports that an attribute that was deprecated in WiX v3.0 -- I say again, WiX v3.0 -- was not converted by the
wix convertcommand. We should catch up. @chrpai volunteered to take a swing.
[-][-iso31661 alpha2] for Locale Identification, from @hollowaykeanho, requests a particular way of identifying cultures in WiX authoring. WiX uses the .NET naming convention, which includes only language and region information. Any culture name that .NET accepts is available for your own localizations. As neither Rob nor I are language experts (other than good ol'
en-US), we don't plan to make any changes to existing localization files in WiX.
As today's meeting is the last of 2023 and we're less than a month away from our (self-imposed and flexible) date for WiX v5.0-preview.1, Rob decided to slip in all his WIPs for his WiX v5 features. Luckily, none is a surprise: We've been talking about them, sometimes spontaneously, since we discussed the implications of my default major upgrade feature WIP back in WiX Online Meeting #268, #269, and #270.
Virtual Symbols generalizes the concept of "overridable" things in WiX, like how custom actions in WiX extensions have default schedulings that you can override to reschedule them, earlier or later in
InstallExecuteSequence, for example. Virtual symbols are an important part of our plans for the WiX Standard Library. The standard library lets us avoid a bunch of special handling of built-in symbols we're doing today and gives us a home for some of the "magic" symbols I've been working on in my WiX v5 features.
The standalone BootstrapperApplication Processes WIP lays out what we've previously discussed: The current Burn model where Burn is the process that hosts the bootstrapper application DLL is problematic for several reasons but chief among them is that .NET (Core) doesn't prioritize the .NET hosting model that allows Burn to host managed BAs. Having Burn and the BA both be processes that talk and cooperate with each other solves the .NET problem and also opens up BAs to be written in many languages without explicit support in WiX.