In today's meeting, we triaged new issues. That's it. There was no late-night livestream to report on. There was no pending release that needed its status reported. Er, well, that said, though we didn't talk about it in today's meeting, go update your HeatWave to get the latest bug fixes for WiX v4's Visual Studio integration, please and thank you.

Issue triage

  • WIP: WiX v5: Default major upgrade behavior and localized error message, from @barnson, was this close to getting resolved, after our many and long discussions about virtual symbols and the WiX standard library. However, that was a tiny part of what we needed to discuss about the feature, as there are several interesting considerations I called out in the WIP. We started discussing them, but in what I believe is now Rob's default behavior, Rob suggested postponing for another fortnight for a bit more contemplation. Always happy to play along, I agreed and we'll talk about this feature again on Halloween, which will certainly help resolve any issues.

  • WiX v4 - Directory Table Primary Key conflict, from @chrpai, reports an apparent bug when using WiX v4's tasty new Subdirectory feature that lets you define directories when and where you use them. What should work is creating duplicate subdirectories but apparently there are cases when it does not. Rob took the issue for a fix in WiX v5.

  • Bundles v3.x and v4.x do not see package dependencies from each other, from @petm2022, reports what turns out to be an unfortunate consequence of a bug fix to Burn in WiX v4. Specifically, the default provider key changed in WiX v4. Luckily, it's possible to specify a provider key for packages to match the default provider key in WiX v3 (using the handy bind-time syntax !(bind.property.ProductCode)). I took the issue to see if I can imagine a change that fixes the bug and maintains compatibility. I do not have high hopes but wouldn't feel right if I didn't at least pretend to try.

  • netfx:DotNetCompatibiltyCheck cannot be used to check for net8 release candidate, from @charristti, reports a problem using DotNetCompatibiltyCheck to look for the net-quite-yet-released .NET 8. However, as DotNetCompatibiltyCheck (and .NET itself, of course) uses Semantic Versioning, you have to remember the tricky bits of SemVer. One of the trickier bits (at least to your humble reporter) is that using labels turns your version into a prerelease version, such that 8.0.0-rc.2.23480.2, the current release candidate of .NET 8, is considered a lower version than 8.0.0.

  • Wix V4 Merge Module IDs are restricted by Windows restricted file names, from @MddMBorg, was a bug report that's amusing to anyone who used any version of DOS. Back in the before time, someone had the neat idea to be able to address devices as if they were files. And of course the devices themselves are ancient: serial communications ports (for your acoustic-coupler modem, naturally) and parallel-port dot-matrix printers. Ah, 80s nostalgia. Anyway, that devices-as-files support means that some file names, even in 2023, are reserved and can't be used for normal files. A change between WiX v3 and WiX v4 reused an id from a merge module for an intermediate file name which gives Windows an opportunity to remind you that you can have up to 10 printers connected, if you need them when your Walkman ate your favorite mix tape. Rob volunteered to fix this issue in WiX v5.

  • iis: Wix4InstallCertificates_X86 fails with x64 BUILDARCH, from @matbech, was a confusing report because there shouldn't be a mix of platform-specific custom actions in WiX v4. It turns out that you can end up in a mixed state by having a hard-coded reference to a custom action with its platform-specific suffix. This can happen when you need to reschedule a WiX custom action, for example. That's annoying but something that needs a bit more intelligence to fix. In the meantime, the $(sys.BUILDARCHSHORT) preprocessor variable was created to address platform-specific suffixes for you.

  • WiX v4 ignoring WarningLevel Property, from @chrpai, requests support for a WarningLevel property, as is supported for .csproj C# projects. WiX doesn't break its warnings into levels, however, so other than 0 to indicate that all warnings should be suppressed, levels aren't applicable to WiX projects. (Technically, the -pedantic switch could be considered a level of warnings, but -pedantic is too awesome a name to give up.)