Today is Patch Tuesday the 13th, which I'm sure will be just fine and is in no way something to be superstitiously nervous about. Read on to hear about our successful launch of WiX v4.0.1 and the first discussion of the features that we're building in WiX v5.

WiX v4.0.1

The WiX v4.0.1 status is that it was shipped as scheduled on 5-June. Read the release notes, update your MSBuild projects to use the latest versions of the WiX SDK and WiX extension NuGet packages, and upgrade the command-line .NET tool version of WiX.

WiX v5 feature overview, part I

As WiX v4 and v4.0.1 wound down, I started planning what I wanted to work on in WiX v5. As we're planning for annual releases of WiX going foward, I chose to work in a single "epic" or theme of several smaller features. The theme is "WiX language simplification" and these are the individual features I'm confident I'll be able to accomplish on the WiX v5 schedule:

  • Default feature
  • Default root directory
  • Default major upgrades
  • Files without components

There are other features I've thought about and sketched out -- if things go well there might be more than this list that I build in WiX v5. Of course, sometimes things don't go well, and the annual release plan means we'll cut whole features or reduce their complexity to meet our dates. The deadlines are self-imposed to provide gentle, encouraging pressure, not stressful pressure.

I'll be writing WIPs for these features and will likely be shouting here and elsewhere for feedback. Until then, you can listen to the meeting for a sneak peek.

Rob has hinted he might discuss the features he wants to work on during our next meeting (27-June).

Issue triage

  • Exception thrown one time when Heatwave upgrades existing wix 4 setup, but then everything works, from @hfickes and HeatWave for VS2022 - Project templates older SDK version, from @MichelMichels, are reports about FireGiant's HeatWave Visual Studio extension. HeatWave has its own repo for reporting bugs so we encourage everyone to report issues directly there. However, we have an in with the folks who own that repo, so we pinged them and they volunteered to copy the issues over.

  • WIP: add support for multilingual MSI packages, from @jmairboeck, is a WIP to support the it-works-but-is-not-officially-supported-feature in MSI to automatically choose an embedded transform to show localized UI to the installing user. @jmairboeck was in the chat during today's meeting, so Rob's going to do that thing where he provides knowledge and encouragement to get someone contributing code as well as issues. I can report it's an effective strategy, or at least was back in 2004 when I started contributing to WiX...

  • Update signing service, from @robmen, is a reminder from Present Rob to Near-Future Rob that the .NET Foundation signing service WiX uses today to sign binaries and packages is being deprecated and needs to be replaced. There is a new .NET Foundation signing service we could adopt and always have the option of using the signing service we use internally at FireGiant. The deadline is two weeks away, so Present Rob volunteered Very-Near-Future Rob to do the work.

  • IWindowsInstallerDecompilerHelper should not be a singleton, from @barnson, came from my work with a FireGiant customer that has some deep integration into WiX v4 and discovered that the IWindowsInstallerDecompilerHelper returned from the WiX service provider can't be used in multiple calls to IWindowsInstallerDecompiler. IWindowsInstallerDecompilerHelper is registered in the service provider as a singleton, so you always get the same object back but the implementation tracks a lot of state, so can't be reused. There are a couple of workarounds but the right answer is to not make stateful objects singletons. I volunteered to provide that right answer.