Today is my eighth work-iversary at FireGiant. In accordance with ancient customs, I put out eight pounds of candy in my office for my coworkers to enjoy. However, my nearest coworker is over 2000 miles away, so I have almost five pounds of candy left. Well, there's always tomorrow...

WiX v4 release plan

Today we're announcing a change in the WiX v4 schedule—but it's a good kind of change: RC4 was planned for 24-March, but based on the low number and severity of bugs we've received since releasing RC3, we decided to pull the schedule in a week. So now RC4 is planned for 17-March.

Another schedule change is even more serious—and also good: Before today, we've used the "we think we're close, but please test the RCs and let us know" approach to guessing when we would ship WiX v4. No more. We're staking our claim, drawing a line in the sand, and taking a stand: WiX v4 ships on 5-April, the 19th(!) anniversary of the first release of WiX v2 as an open-source project back in 2004.

If you've been lurking at the edges, waiting for a sign WiX v4 is getting ready to ship, well, here's your sign.

Issue triage

  • WcaInitialize should log informational version, from @barnson, suggests that logging version 4.0.0.0 for the entirety of the WiX v4 development cycle wasn't terribly useful. Instead, we should be logging the "informational" version, including the Git commit id. As we're almost done with WiX v4, there's not much reason to make the change now, so I took the issue to fix early in the WiX v5 cycle.

  • RegistrySearch element in the Util extension doesn't allow searching for the value (or existence) of a Name in a Key, from @BMurri, turned from a bug report into a feature request, specifically, that RegistrySearch (in both the WiX and WixUtilExtension namespaces) use different attribute names to identify a registry value to look for. The two RegistrySearches work differently because one is for MSI packages and one is for Burn, but we agree that similar behavior should be expressed similarly. This issue is up for grabs with a wip required to address backward compatibility.

  • LaunchConditions not converted under Include elements, from @robmen, came in last night and was accompanied shortly thereafter by a pull request to implement it. The wix convert code didn't handle converting Condition elements in .wxi include files. Now it does.

  • Prevent direct references to platform neutral WixUI_, from @robmen, also came in and was fixed last night. With the architecture-specific custom actions we added in WiX v4, customizing a WixUI dialog set is a bit more complex, requiring the use of a custom element in the WixToolset.UI.wixext extension. However, the "old school" (WiX v3) mechanism of UIRef still works...well, mostly. It doesn't pull in the new architecture-specific custom actions, which causes build errors. With this change, using UIRef will fail early and we can document the new requirement.