Today's meeting was relatively quick -- because we had only a handful of issues to triage -- and quiet, because the to-be-triaged issues were relatively noncontroversial. (We did surprise and delight the audience by announcing WiX v4.0.2, coming very soon.) I appreciate peaceful and short meetings as much as the next person, but if you're looking for more action in your favorite open-source triage meetings, go find a bug in WiX that has the potential for virtual fisticuffs.

WiX v4.0.2

As we mentioned back when we were discussing WiX v4.0.0 and v4.0.1, we wanted to avoid needing to release a v4.0.2. Well, in software especially, plans are aspirational at most. I uncovered a couple of bugs in WiX v4.0.1 while helping a FireGiant customer migrate to WiX v4 and there are a small number of bugs that trigger the WiX Maintainer Embarrassment-Avoidance Protocol™: Fix bugs we feel embarrassed about not catching sooner. So 8-August, right about two months after v4.0.1 (which was itself two months after v4.0.0), we plan to ship WiX v4.0.2 with a handful of fixes.

Issue triage

  • WIX0001: System.NotSupportedException: No data is available for encoding 1252, from @pfusik, is an example of one of the many joys of code pages. Sure, Unicode is great, but who wants to miss out on the joy of encoding errors, right? Just me? OK. WiX should never crash with an unhandled exception so Rob volunteered to add code around this code page to handle encoding errors, like code in other places to handle encoding errors.

  • Building via MSBuild task requires building twice (references are not restored correctly), from @jmairboeck, reports one of the more annoying aspects of using NuGet packages: They have to explicitly "restored" -- downloaded and wired up into their consuming projects and, at least in .NET Framework MSBuild, that restore step cannot be done in the same invocation of MSBuild as the invocation that runs the actual build step. (The .NET folks have the dotnet build command-line operation do the restore step implicitly; .NET Framework MSBuild has an explicit -Restore switch instead.)

  • Add support for non-SNI SSL certificate in WixToolset.Http, from @solidstore, requests support in the WixToolset.Http.wixext WiX extension for non-SNI SSL certificates, which, obviously, everyone knows about and definitely doesn't need to search Wikipedia to understand. Obviously, if you know you need it, you know you need it. Thankfully, the request comes with a planned pull request so we happily accepted the issue for WiX v5.

  • Cannot build with WixToolset.DifxApp.wixext in a Library .wixproj, from @avivanoff, reports a failure to build a .wixlib when using the WixToolset.DifxApp.wixext WiX extension. There's a conflict in how WixToolset.DifxApp.wixext needs a separate .wixlib (as opposed to the one that normally comes built into a WiX extension) due to the...ahem...oddities in how the Windows team built the DifxApp custom actions. WixToolset.DifxApp.wixext works as expected when building a package and Rob identified a workaround to support building .wixlibs. Given that DifxApp itself is deprecated, we deprecated WixToolset.DifxApp.wixext in WiX v4 and will remove it in WiX v5, so there's really nothing else to do with this issue.

  • Outdated Warning Message for UpgradeCode, from @SeanYoungIL55, points out that the warning message you get when you omit a package's upgrade code mentions the old-school WiX v3 Product element instead of the sleek and modern WiX v4 Package element. Rob made a quick pass to hunt down any lurking stale references.

  • Package/@Name="dir\" fails in WiX v4, from @barnson, remembers that in WiX v3, you could lay out the packages in your bundle by specifying a directory in the package's Name attribute with a trailing backslash. You didn't have to specify the file name of the package, which lets you avoid duplicating the file name.