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:
- Install TortoiseHg.
- Use Explorer to create a directory where you want to store the source code. I used “wix” in the root of my X: drive.
- Right-click the directory you created in step 2 and choose TortoiseHg|Clone.
- 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.
- 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.)
- 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.
- 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.
- Click Update to get the version you selected.
The directory now contains a WiX source enlistment. Up next: creating patches against a clone of the official repository.
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" />
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.
Don’t complicate your setups by doing more than you have to. Here are a few things I’ve run into lately of people doing more than they have to and opening themselves up to potential bugs or increased risk of getting something wrong.
- Some attributes are optional, really. Rob and I have blogged before about the language enhancements sneaking into WiX v3.5. Those enhancements focus on simplifying authoring, by collapsing elements (MajorUpgrade) or providing smart attributes (Component). I suspect many people rely on IntelliSense in Visual Studio when authoring their WiX source files. IntelliSense is pretty close to sliced bread on the greatness scale of inventions, but it has a significant downside in the current implementation in Votive: It lists all possible elements and attributes in the WiX schema, with no “intelligence” behind which are most important. So you get the positive IntelliSense feedback of providing values for every attribute. It’s addicting but you can fight it. (To be fair to IntelliSense, it’s just using the default XSD schema support in the XML language service; if someone were to add a WiX language service to Votive, IntelliSense could be much better.)
- Manually marking package and component bitness. MSI doesn’t support platform-neutral packages or components: They’re either 32-bit (x86) or 64-bit (x64 or IA64). In your authoring, you can specify a package’s platform using the Package/@Platform attribute. Components are 32-bit by default; you can specify that they’re 64-bit by specifying “yes” as the Component/@Win64 attribute value. In a package full of 64-bit components, you have to specify @Win64=”yes” for every component. It’s typical to want to produce both 32-bit and 64-bit packages from the same WiX source, so a common approach is to make the @Win64 attribute value a preprocessor variable. Or, just let WiX handle it for you: Specify the –arch switch at the candle.exe command line or the <InstallerPlatform> property in a .wixproj MSBuild project. When you specify x64 or intel64, Candle automatically sets the package and components in the file being compiled as 64-bit. It’s still useful to be able to say “Win64=’no’” for those components that are 32-bit even in 64-bit packages. Of course, that’s also legal in 32-bit packages, so it’s safe to hard-code.
- Unnecessarily nuking registry keys. The RegistryKey/@Action attribute lets you specify some of the “special” Registry table functionality that MSI supports. Specifying create lets you create an empty registry key; createAndRemoveOnUninstall tells MSI to delete the key and all values during uninstall. That’s useful functionality if your application creates additional values at runtime—but for per-machine registry keys (under HKEY_LOCAL_MACHINE) most apps don’t create additional values because it would require elevation. (The not-quite invisible hand of UAC gently guides developers toward good app behavior.) If you omit the @Action attribute or specify none, MSI will still delete the registry key if it deletes all the values in it (and so on, recursively down the registry key hierarchy). That’s the default; you don’t have to ask MSI to remove the registry entries it writes. So if you need to nuke your keys, go ahead, but otherwise, don’t bother.
By the way, all of these things work in WiX v3.0 rtm.
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.
- 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.
- OS version. Which version of the OS? Which edition? x86 or x64? Which service pack?
- Virtuality. Does the bug occur in virtual machines or on “real” machines? Which virtual machine technology (e.g., Virtual PC, Hyper-V, VMware, VirtualBox)?
- 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.)
- Frequency. How often does the bug occur?
- .msi package data. How big? How many files? How many components?
- WiX and WixUI data. Which version of WiX are you using? Which WixUI dialog set? How have you customized it?
- 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.
