Working hard or hardly working?

Posted on by

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.

Bug hunting

Posted on by

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.

Lux unit testing, now with extra mutations

Posted on by

I’m currently spending a lot of time working with custom actions, removing them where I can and improving them where they’re still necessary. The biggest change I’m making is to make the custom actions data driven using the immediate/deferred/rollback custom action triad. One of the advantages in doing so is that I can use Lux to help test my work. One of the advantages of that is that real-world experience is the best way to improve tools.

One of the challenges of developing data-driven custom actions is testing all the combinations of state that affect the custom action data immediate custom actions pass to deferred and rollback custom actions. Because Lux test packages don’t modify the machine, testing the full set of possible states is difficult. Providing known state is a strength of traditional unit-testing techniques, however; if your custom action code is well factored, it should be a simple task to provide a test double that arranges hard-coded state information that you can then test against.

Naturally, I wanted to figure out how I could provide the best of both worlds in Lux. Here’s what I came up with: test mutations. From the doc:

Test mutations let you author unit tests with different expected results. The mutation id is passed as the value of the WIXLUX_RUNNING_MUTATION property. Your custom action, typically in an ‘#ifdef DEBUG’ block, retrieves the WIXLUX_RUNNING_MUTATION property and mock different behavior based on the mutation. To author test mutations, use the Mutation element with UnitTest elements as children. For example:

<lux:Mutation Id="SimulateDiskFull">
  <lux:UnitTest … />
</lux:Mutation>

Nit runs the test package once for each mutation, setting the WIXLUX_RUNNING_MUTATION property to one mutation id at a time. Tests that aren’t children of a mutation are run every time.

Test mutations are a fairly simple change but one I hope simplifies combining traditional unit-testing techniques with declarative assertions.

Lux’s test mutations will ship in the next weekly release of WiX.

WiX, MSBuild v2.0, and x64 systems

Posted on by

WiX v3.0 and v3.5 executables are available in .zip form and x86 and x64 .msi packages. The x64 .msi package was originally created because we need to install the WiX targets and tasks for 64-bit MSBuild into a 64-bit directory, something that’s not supported for x86 packages. Late in the WiX v3.0 development cycle, Jason made a change that lets 64-bit MSBuild use the targets and tasks in the 32-bit directory tree. Unfortunately, the special property used to allow that is present only in MSBuild v3.5, not MSBuild v2.0, so we still create the x64 .msi package.

Creating the x64 .msi package isn’t a huge burden on us but it’s led to some confusion, so we’d like to get rid of it. If you use 64-bit MSBuild 2.0 and the x64 WiX .msi package, please respond in the comments. If you use MSBuild 3.5 or the .zip WiX package or by checking WiX in to your source-control system, you’re not affected and can use the x86 WiX .msi package.

Posted in WiX

Serial monogamy with your development tools

Posted on by

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.