Today is 8/8 so no matter which date format you use, it's the eighth day of the eighth month...unless you don't like base 10. Read on to hear about the status of WiX v4.0.2 and parts of WiX v5, in addition to our tried and true triage.

WiX v4.0.2

Originally scheduled for release today, WiX v4.0.2 will instead ship slightly before, during, and/or slightly after our next meeting in two weeks. Another bug came in that triggered the WiX Maintainer Embarrassment-Avoidance Protocol™ (MEAP) -- or, as Rob less whimsically suggested, were just bad enough to us to justify including in v4.0.2. A slight delay increases the likelihood we will be able to avoid shipping a WiX v4.0.3 because then I'd feel the need to joke about not being able to find WiX v4.0.4.

Issue triage

  • Migrated WiX v3 to v4, now getting error doing action Wix4ConfigureSmbUninstall_X64 when installing, from @barnson, is reporting a bug when using the WixToolset.Util.wixext extension's FileShare element. It is indeed a bug so I fixed it and we agreed to take it into WiX v4.0.2.

  • Document util:RemoveRegistryKey[Ex], from @barnson, suggests that there is some functionality new to WiX v4 that isn't documented. The name alone is intriguing -- what does it do compared to the already extant RemoveRegistryKey element? The answer to that question, and likely others, will come from careful study of the code, which, at the end of the day, is the source of all documentation. Rob volunteered, with no prompting whatsoever, to study the code that he wrote and translate that knowledge to documentation.

  • Invalid Language Id for zh-HANT file, from @solidstore, reports a build failure during ICE validation when using a file tagged with a language code that is new -- well, relatively speaking. The ICEs have not been well maintained over the years, so, sadly, it's not terribly surprising that they haven't kept up with the latest in the localization world. Unfortunately, there is no workaround other than suppressing that ICE. Even more unfortunately, that ICE does a bunch of different checks, so suppressing it means losing out on all the other checks too. Long-term, we'd like to throw out the ICEs and reimplement all their checks as part of the WiX build process, because we're confident we can make them faster (and maybe even also harder, better, and stronger). We would also temporarily settle for fixing ICE bugs like this if Microsoft were to release them as open source...

  • Package/@Scope XSD doesn't allow for preprocessor variables, from @barnson, is a nit-picky bug report about the WiX language schema that drives IntelliSense inside Visual Studio. IntelliSense doesn't know about the WiX preprocessor so it complains if you use a preprocessor variable somewhere that has some kind of enforcement in the schema. This has been true just about forever, so there's a pattern in the WiX schemas that we need to adapt for Package/@Scope. I volunteered to do that adaptation.

  • Page Not Found: /documentation/error217/, from @calbarkman, reports that WiX v3 still points to a supplemental bit of documentation that no longer exists. It no longer exists because it was out of date but we should probably revive it so we can say it's out of date. I volunteered to do that.

WIP review

WIP: WiX v5: Default root directory and WIP: WiX v5: Default major upgrade behavior and localized error message are the WIPs that your humble correspondent wanted to bring back up for discussion with Rob and all our regular visitors, who get extra-special input into the development of WiX because they showed up. (It's like voting. If you don't vote, you don't get to complain.)

WIP: WiX v5: Default root directory was the least controversial: I suggested that it should be possible to treat INSTALLFOLDER as one of the values accepted by StandardDirectory. The implementation would be very different than the other standard directories, but to the outside observer, everything would work as expected. I knew this would be the answer but needed the extra push of external validation to go redo the work I'd already done.

WIP: WiX v5: Default major upgrade behavior and localized error message was more substantial and led to a fair amount of excitement. We decided that it should be possible to opt out of the default major upgrade behavior. (That wasn't the exciting bit.) But that behavior requires localized strings, which led me to contemplate the need for more than good ol' US English strings and the need to supply multiple .wxl files -- which we do today in WiX extensions by embedding a WiX library in the extensions. So what if the lone .wxl file I'd originally anticipated were instead a .wixlib that could handle n .wxl files? Well then you have a .wixlib that could also store WiX authoring. And then, and then, what if we extended the concept of Overridable beyond its current use in loc strings and scheduling standard and custom actions? Then we have a generalized mechanism to provide WiX authoring for built-in behaviors. A feature like default INSTALLFOLDER could be entirely implemented in that .wixlib, with no C# code required. Other features would be simpler with the authoring provided as actual authoring, rather than in C# by creating new symbols at runtime. (This is the exciting bit -- so exciting, in fact, that we decided to postpone further discussion so we can savor the moment, calm ourselves, and think about exciting new possibilities.)