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.
WcaInitialize should log informational version, from @barnson, suggests that logging version
126.96.36.199for 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.
RegistrySearchelement 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 grabswith a
wip requiredto 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 convertcode didn't handle converting
Conditionelements 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
UIRefstill works...well, mostly. It doesn't pull in the new architecture-specific custom actions, which causes build errors. With this change, using
UIRefwill fail early and we can document the new requirement.