Here we are, not quite a month after shipping WiX v4 and April code showers have yielded May bug fixes. Read on to learn all about WiX v4.0.1, WiX v5, and all the issues we'll lovingly triage.
A quick organizational note: After more than nine years of contributions to both WiX v3 and WiX v4, Sean has decided to step down from his role as a committer to WiX. He has our thanks for all the hard work!
To allow for more serious bugs to be reported and triaged, we've decided to push WiX v4.0.1 to 5-June-2023. We think that gives us the best shot at capturing and fixing the important bugs in v4.0.0 and not need to do a v4.0.2 later on that would distract us from our work on WiX v5.
Speaking of WiX v5, WiX v5 development has already begun. We've had a few changes for v5 go in already, plus all the fixes we're taking for v4.0.1 go into v5 first. (Rob will cherry-pick the fixes for approved v4.0.1 bugs into a v4.0.1 branch closer to its release.) For v5, we're going to hit our stated goal of annual releases, by releasing v5.0.0 exactly one year after v4.0.0. Here's the schedule:
- v5.0.0-preview.1 on 5-Jan-2024
- v5.0.0-rc.1 on 5-Feb-2024
- v5.0.0-rc.2 on 5-Mar-2024
- v5.0.0 on 5-Apr-2024
(Conveniently, the fifth day of each of those months is a weekday.)
Duplicate Components in Fragment compiles without errors, from @chrpai, reports that it's possible to build a library that has components with duplicate ids in the same fragment. That should be fail-fast error, because it will be a fail-slow error when the fragment is linked into a final output. (It's legal to have the same component id in different fragments, however, as long there's no overlap when linked into a final output.) Rob agrees so we took the issue into WiX v5.
Error dialog for SqlDatabase error not showing, from @davidkarlsson and Error messages aren't correctly sent (logged) (displayed) (processed), from @barnson, are an instance of a bug and the root cause of the bug, respectively. The message-processing logic that lets custom actions show error messages when the user is running an interactive install had a couple of bugs that caused the custom actions to fail without prompting. Actually, the custom actions are crashing, which MSI politely covers up as a failure. (Or, annoyingly covers up, if you're trying to debug the problem.) That's no good, so we agreed to take the fix in WiX v4.0.1.
MSBuild HarvestDirectory ItemGroup doesn't allow customized AdditionalOptions per item, from @nirbar, requests an enhancement to the target-based Heat harvesting support. As it included a pull request, we're happy to take this feature in WiX v5.
Build fails when a bundle contains two or more RemoteBundle elements, from @nirbar, reports a build error when using more than one of the cool new
RemoteBundleelements in (an also cool and new)
BundlePackageelement in your bundle. @nirbar also included a pull request to fix this issue. We agreed it was a serious-enough bug to include in WiX v4.0.1.
Errors when using WixUI_Mondo in wix 4.0.0, from @jobmarley, suggests I did something wrong when updating WixUI for WiX v4. Clearly that's wrong...except for one tiny minor thing that was exposed by Windows Installer validation. Unfortunately, validation has proven unreliable in the WiX build, so we turn it off and therefore missed this bug. A fix for this bug goes into WiX v4.0.1.
Specifying Source Files 404, from @chrpai, reports a missing page that some of the reference topics point to. Rob suggested that we could reuse the WiX v3 version of the topic with only minor changes. Of course, you might be surprised to learn that sometimes someone not doing the writing overestimates the ease of writing. Nonetheless, I volunteered to fix this (one way or another).
ComponentGroups @Source seems to be ignored, from @chrpai, led to a fascinating (for setup-nerd levels of fascinating) discussion about WiX's design for locating payload files. One rule is that
Sourceattributes in child elements overwrite
Sourceattributes in parent elements. They are not additive. One almost-exception to that rule is that
FileSourceattributes that are additive and can build up a directory tree. But
FileSourcevalues are only evaluated at compile time. For consistency's sake, take a look at using named bind paths, especially now that the WiX MSBuild targets generate them for projects your .wixproj references. (See previous bullet regarding how writing on a "simple" topic is sometimes harder than it looks. Hug a writer, folks; they need it.)
RelatedBundle element causes Access Violation crash, from @lukeskrz, turns out to be a bug that limited each bundle to have at most one type of related bundle entry: upgrade, addon, patch, and detect. But each bundle is automatically given a related bundle of type upgrade for its own upgrade code, so adding one causes the crash. The crash turns out to be caused by bad pointer manipulation, something, unfortunately, not unheard of in C/C++ native code. Those wild pointers have been tamed for WiX v4.0.1.
Adding MessageQueuePermission with a Group results in ICE03 validation error, from @djohnst10, is the second bug this meeting exposed by Windows Installer validation. In this case, a table was renamed but the new name wasn't updated in all the right places. An update in all the right places is scheduled for WiX v4.0.1.
WiX 4.0 projects do not support removing Compile items from the build., from @djohnst10, suggests that you should be able to remove .wxs files that are automatically included in .wixproj projects using the WiX MSBuild SDK. Rob was confident the behavior of the "auto glob" behavior was fixed unless you did extra work to explicitly import the WiX SDK's targets. Apparently, however, C# projects work without that extra work using some yet-to-be-determined MSBuild voodoo that Rob wants to replicate in WiX v5.
Documentation for "WiX tools and concepts > Heat harvesting" does not mention Include attribute, from @chrullrich, suggests a way of improving Heat documentation. Sounds good and we opened this issue
up for grabs.
Autogenerated Directory Id keys are not unique, from @chrpai, reports a bug where using the
Subdirectoryattribute to create ad-hoc subdirectories didn't give them unique identifiers. Rob found that a bit surprising so he's investigating for a potential WiX v4.0.1 fix.