In a throwback to the mid-2000s, I spent a late Thursday night/Friday early morning collaborating with Rob on some gory WiX internals. Unlike the mid-2000s, it was virtual, I was 2000 miles away, I was responsible for my own refreshments, and it was recorded.

Issue triage

  • WIP: WiX v5: Default major upgrade behavior and localized error message, from @barnson, continues to be gently kicked to a future meeting, though Rob broadcast his research spike on "virtual symbols," which will form the basis of the "WiX standard library" that this WIP relies on to provide default error messages. When we eventually discuss this WIP, it will have months of research behind it!

  • DotNetCompatibilityCheck with Platform attribute "x64" aborts installation on x86 OS, from @apacker1, points out that if you use WixToolset.Netfx.wixext's DotNetCompatibilityCheck and specify a platform that's not supported by the machine the package is running on, the package fails. @apacker1 provided a pull request that instead turns it into an error code. I suggested that an error code of -1 was close to an existing return value and maybe we should use a value further away from the ones already used. I asked triage to suggest numbers for possible error codes. This was mostly to get professional technical input and only a little bit to get potential lottery picks.

  • When is child of : System.ArgumentNullException during build, from @dbengle, reports a scenario that worked in WiX v3 and doesn't in WiX v4. Luckily, it's a rare scenario with an easy workaround, but it needs fixing, so Rob volunteered to do so.

  • Condition that spans multiple lines does not convert correctly to WiX v4, from @dbengle, shows a suboptimal conversion made by the wix convert command. It's functional but could be prettier. Rob suggested that @cpuwzd, who previously did substantial work on the wix convert command, might want to take this issue, and as he was attending live, Ron agreed. I'm liking this whole get others to sign up for issues thing; we gotta do more of that!

  • WiX v4 not honoring NUGET_PACKAGES environment variable, from @dbengle, requests support for another one of the many ways you can configure the location of the NuGet global packages folder. One might assume that all that kind of configuration with be handled by the NuGet client API, but, alas, it turns out one's assumptions would be wrong. So WiX itself would have to support the NUGET_PACKAGES environment variable, which we opened as up for grabs for those interested in NuGet internals.

  • Need a plan to handle WiX v5 documentation, from @barnson, came from the WiX v5 work I'm doing: We should probably document them. Actually, we definitely should document them, and ideally, document them from the get-go, rather than months later when I've forgotten all the details. (It turns out that makes writing documentation even harder, so waiting is just overall a bad idea.) We could immediately break the v4 and v5 documentation into two different streams, but given that we're aiming to make the WiX v5 language backward compatible with WiX v4, it's probably overkill to version them. That said, some of the WiX managed APIs might undergo more substantial change, given Rob's plan to support out-of-proc bootstrapper applications. On the third hand, maybe Rob will be able to hide the details and the API won't change much. So for now, we'll tag schema and API changes to show when they were added in WiX v5; if that becomes unwieldy, we'll consider versioning them separately.

  • Incompatibility and Workflow Complications when Directly Referencing .NET Libraries in WiX Projects, from @nickhoeferpickpro, is a bit confusing but seems to be about making it easier to consume NuGet packages for custom actions. WiX amply demonstrates one way of doing so: As WiX extensions that combine, for example, WiX compiler extensions and WiX libraries, all in one NuGet package. Making it easier to write custom actions isn't a WiX priority: We want fewer bespoke custom actions and more shared, general purpose custom actions like those in WiX extensions.

Virtual symbols

Many of the WIPs I've written for WiX v5 features provide defaults (directories and features, for example) that work for simple authoring and can easily be overridden when needed. WiX has long had support for "overridable" things like localization strings and action scheduling. My latest WIP, WIP: WiX v5: Default major upgrade behavior and localized error message, brought up several ideas that coalesced into two ideas: Generalizing the idea of overriding symbols and including such symbols in a built-in "WiX standard library." Rob named the former "virtual symbols" and broadcast his research spike on them. The results were positive: Rob was able to implement virtual symbols that can be easily overridden. There's more to do, including support for a standard library (and the ability to not use the standard library). At that point, I can redo some of my WiX v5 pull requests to take advantage of the standard library.