Experimental results part II

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.)

Experimental results part I

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

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.

Bug hunting

There’s a bug that the WixUI “Please wait while the installer finishes determining your disk space requirements” dialog is intermittently shown forever, never finishing the costing process to continue installation. I’ve seen that bug before have never been able to reproduce it reliably. The disk costing process is something Windows Installer does in the background while the wizard UI is running; .msi packages have no real control over the process, other than which features are enabled at the start of the UI sequence.

Here’s the problem: I don’t think it’s a bug in WiX or WixUI. MSI owns the costing process and as costing works almost all the time, there isn’t a simple answer like “oh yeah, a rich-edit control on the first dialog breaks costing.” I suspect that there’s a bug in MSI but before I go to the MSI team, bug in hand, I need more data. Here’s where you come in: Help us gather more data to narrow down the bug.

  1. Logs. It’s a reflexive request that verbose MSI logs are a vital part of figuring out any setup bug. In this case, they might not be that helpful, as the logs I’ve seen, including those attached to the bug, just show a lot of time passing between log entries.
  2. OS version. Which version of the OS? Which edition? x86 or x64? Which service pack?
  3. Virtuality. Does the bug occur in virtual machines or on “real” machines? Which virtual machine technology (e.g., Virtual PC, Hyper-V, VMware, VirtualBox)?
  4. MSI version. If it is a bug in MSI, narrowing down which versions are afflicted the worst would be key. (For example, I’ve never seen the bug occur on MSI 5.0 in Windows 7.)
  5. Frequency. How often does the bug occur?
  6. .msi package data. How big? How many files? How many components?
  7. WiX and WixUI data. Which version of WiX are you using? Which WixUI dialog set? How have you customized it?
  8. Packages. If you can provide packages that demonstrate the problem, please do so. Obviously, you might not be able to share your actual package content but does the bug still reproduce if you replace your actual files with zero-byte replacements?

If you’ve seen this problem, please help: Add your comments to the bug on SourceForge and attach your logs and packages.

Help us WiX community, you’re our only hope.

Update, 5 April 2010: Added Virtuality – I got a report that the bug occurs most often on Virtual PC virtual machines and it seems to be a common issue on various blogs.

Serial monogamy with your development tools

When WiX v3.0 was in early, active development, the guidance we gave folks who wanted to start using its features was: “Sure, start using WiX v3.0! But pick up new builds at least once a month or so.” There were three Reasons for Taking Frequent WiX Drops (RTFWD, for short):

  1. The v3.0 schema was changing routinely. Going months between picking up new builds would expose bigger, possibly backward-incompatible changes. New builds once a month limited a team’s exposure to whatever we could do in four weeks.
  2. When you need a bug fix, you want as small a fix as possible. Bug fixes came frequently throughout the toolset so the longer between builds, the more churn a team would pick up. That complicates validating the packages produced by a new WiX build.
  3. Output changes could complicate (or break) patching. Changes in the things WiX writes to MSI tables affect your ability to create patches. The rules governing patches are a superset of the dread component rules, adding rules about changes that make patches not uninstallable.

In effect, you increase stability by taking smaller changes at any one time.

For WiX v3.5, reason #1 doesn’t apply: We aren’t making any backward-incompatible schema changes though we’re making additive changes to simplify authoring. Reasons #2 and #3 still apply—and keep applying.

Long-term relationships

Eventually there comes a time in every project’s life to settle down in a committed relationship. For WiX users, that time is when you’re nearing a release that you intend to service. It might be a public beta, it might be RTM, it might be a weekly release of your Web app. If you intend to service it, especially with patches, you want the stability of a known build of WiX—Reason #3 applies in earnest when you start servicing.

New product releases can pick up new versions of WiX, but on the source-control branch you’re using to service old releases, stick with one version of WiX. We encourage teams to ship products using the released, RTM builds of WiX. So far, we haven’t released a service pack for WiX, but it’s safe to assume we wouldn’t include any changes in one that broke patching.

Youthful indiscretions

I was reminded of reason #3 today: Bug 2965405 demonstrated a hole in the logic that generates default component ids. The fix is simple: give a better default id used in constructing the stable short filename. Unfortunately, it changes every short filename that’s generated when you omit the Component/@Id attribute and the filename doesn’t fit within the 8.3 short filename syntax. Fixing the bug would complicate patching from prior builds of WiX v3.5.

As WiX v3.5 hasn’t even gone to beta yet, I believe we should fix the bug even with the patching problem it introduces. Other folks on the WiX Virtual Team will get to weigh in, as can you by commenting below.