WiX v3.5 release candidate has been released

Posted on by

The WiX Extended Leadership Team and the WiX v3.5 Executive Release Drivers are pleased to announce that WiX v3.5.2229.0 has been declared the WiX v3.5 Release Candidate build. Release candidates are the builds that come after betas and before the final release: All the features–primarily Visual Studio 2010 and IIS 7.0 support–are implemented and the riskiest bugs have been fixed.

Now’s the time to download it, install it, and let us know if WiX v3.5 is ready to ship.

See Rob’s announcement: http://robmensching.com/blog/posts/2010/10/29/Trick-or-treat-WiX-v3.5-Release-Candidate

Get it here: http://wix.sourceforge.net/releases/3.5.2229.0/

Experimental results part II

Posted on by

It’s been four-plus months since Experimental results part I. All reports point to The Experiment being a success so it’s time to make it permanent. Today I checked in a change that defaults to opting-out of the troublesome disk-costing dialog box. It’s still present but by default will not be shown. If you’re using a stock dialog set, there are no changes you need to make. If you’ve built a customized dialog set, remove the WixUICostingPopupOptOut WiX variable definition from your dialog set fragment or you’re likely to get an error message at link time:

The Windows Installer XML variable ‘WixUICostingPopupOptOut’ is declared in more than one location.  Please remove one of the declarations.

You can opt back in to the disk-costing dialog box by providing a value of 0:

<WixVariable Id=”WixUICostingPopupOptOut” Value=”0″ />

Look for this change in next Friday’s builds of WiX v3.5 and v3.6. (Any build more recent than yesterday’s v3.5.2208.0 and v3.6.1008.0 will have it.)

WiX source code using Mercurial and TortoiseHg, Part 1

Posted on by

Now that Rob moved the WiX source repository and releases to Codeplex, how you interact with the WiX source code changes. Before the move to Codeplex, we published a .zip file that contains most—but not all—of the files needed to rebuild WiX. (Some large binary files were omitted because of space limitations at SourceForge.) For example, http://wix.sourceforge.net/releases/3.5.1811.0/wix35-sources.zip contains the source code as of the 11-June-2010 release of WiX v3.5. For now, we’re continuing to publish those files but the move to Codeplex makes them pretty much obsolete.

I’m writing a couple of posts that talk about how to use the WiX source repository to view, modify, and patch the WiX source code.

Getting WiX source code

Getting WiX source code out of Mercurial is straightforward using TortoiseHg:

  1. Install TortoiseHg.
  2. Use Explorer to create a directory where you want to store the source code. I used “wix” in the root of my X: drive.
  3. Right-click the directory you created in step 2 and choose TortoiseHg|Clone.
  4. In Source path, enter https://hg01.codeplex.com/wix. That’s the Mercurial clone URL, provided by Codeplex. You can see it for your self by going to https://wix.codeplex.com/ then clicking the Source Code tab and clicking Mercurial in the Source Control Setup box in the right bar.

    TortoiseHg Clone

  5. Click Clone. TortoiseHg will fetch many “chunks” from Codeplex. It’ll take a while, depending on your Internet connection speed.

Your patience is rewarded with a directory that contains one subdirectory and two files (at least as of today). Huh? All you’ve done so far is cloned the WiX Mercurial repository. Next up is updating your working directory with a particular revision of that repository. (The default branch in the WiX repository contains no interesting files; all past and active development is happening on the named branches wix20, wix30, and wix35, shown below in green.)

  1. Right-click the directory you created in step 2 and choose Hg Repository Explorer. You’ll get a window that contains the changes that have been committed to the Mercurial repository.

    wix - Repository Explorer

  2. Right-click the line representing the version you’re interested in and choose Update. To get the latest version, look toward the top for the version with the yellow “tip” box.
  3. Click Update to get the version you selected.

    Update - wix

The directory now contains a WiX source enlistment. Up next: creating patches against a clone of the official repository.

Experimental results part I

Posted on by

So far the results of The Experiment have been minimal—I’ve received one public report and one private report—but 100 percent successful. So we need more data but so far it’s looking good.

One issue has come up, however: Build failures with customized dialog sets. Fragments that define dialog sets need to include all the UI elements, properties, and WiX bind-time variables used by the dialogs in that set. By referring to the WixUICostingPopupOptOut WiX variable from the individual dialogs, custom dialog sets must also provide a value. You can provide a value for WixUICostingPopupOptOut anywhere in your project but the easiest is to do so in the same fragment with your dialog set. Just add this line:

<WixVariable Id="WixUICostingPopupOptOut" Value="1" Overridable="yes" />

It’s time to experiment

Posted on by

Last month, I posted a plea for help to try to figure out why sometimes (or rarely) (or frequently), Windows Installer fails to set an internal property that causes a never-ending “please wait” dialog. I got lots of feedback—thanks!—but unfortunately, nothing that helped me pinpoint a cause or a solution.

So it’s time to make an guess. Let’s call it an educated guess but as I can’t reproduce the problem, I’m not sure it’s entirely educated.

Coming in the next weekly release of WiX is a mechanism to opt out of the costing popup dialog. And although it’s an opt-out mechanism, for now it’s opted-in by default. The idea is to see quickly if the change fixes the problem. If it does, we’ll keep the opt-in default for WiX v3.5. If not, we can either back out the change or just change the default to opt-out.

So what’s the change? Before, all the dialogs that initiated an install transaction used a SpawnWaitDialog control event with a condition of CostingComplete=1. The dialog would pop up until the condition was met. Now, the condition includes the bind-time WiX variable WixUICostingPopupOptOut. WixUICostingPopupOptOut defaults to 1, so the condition is always true and the popup never appears.

You can override WixUICostingPopupOptOut in your project with a value of 0 to return to the previous behavior:

<WixVariable Id="WixUICostingPopupOptOut" Value="0" />

So, please grab the next release of WiX and try out your previously problematic installers. We want to fix this problem before we start locking down WiX v3.5 for RTM.

Update: You can get the weekly release here.