Joy of Setup

Rick Brewster of the Paint.NET team blogged about the pain of getting Paint.NET installed on a system without the .NET Framework. It’s fair to say that for a system running Windows XP without optional updates, installing the latest and greatest Framework is an annoying exercise. Part of the problem (blame) falls on the shoulders of the Framework folks: The Framework installer should install MSI 3.1 for users; asking them to go spelunking on the Microsoft Download Center for the MSI 3.1 redistributable, then run it and reboot, is rude at best.

Rick’s proposed solution for the next release of Paint.NET is OK, though it has the downside of showing several very different UI experiences:

• A "confirmation" dialog that tells users that prerequisites will be installed.
• The OS-component update dialog (for MSI 3.1) that most users no longer see, because it’s hidden behind Windows Update.
• The .NET Framework Client Profile bootstrapper UI, which is slightly different than the OS-component update dialog.
• The Paint.NET installer configuration UI, which is slightly different than the others.
• The Paint.NET installer UI itself, which uses MSI basic UI.
• If needed, a "reboot needed" dialog, which uses slightly different UI.

A key scenario for Burn is to enable this scenario (with the Client Profile or "normal" .NET Framework installation). Part of being successful with that scenario is to have an integrated experience, which means having a consistent user interface and one progress bar.

We’re not there yet, but know that we’re working hard to solve this problem.

Burn is the name of the new WiX chainer. (Burn is brought to you by the letter B, which stands for bootstrapper.) Though we’re working to ship WiX v3 without Burn, work on Burn continues — it turns out that several members of the WiX virtual team need a chainer for their day jobs. As I’m one of them, I thought I’d blog about the work I’m doing. To start that, this post covers the layers in Burn and how they fit together:

• Core: The Burn core is where the actual chaining and installation code lives. This is, not surprisingly, the biggest chunk of code in Burn, with several thousand lines of code. The core supports installing .msi and .exe packages, with .msp patch package support planned. The core is a static library.
• UX: UX, which stands for User eXperience, handles user interface. Burn includes StdUx, which provides a basic UI. StdUx can be replaced by any DLL that adheres to the Burn UX interface.
• Stub: The Burn stub is an .exe that handles standard command-line processing and startup. It loads the manifest, UX DLL, and packages — any of which might be embedded in the .exe — and lets the UX take over.
• BurnExe: BurnExe is the manifest compiler and bundle builder. The package manifest is an XML file that specifies the list of packages to be installed; BurnExe resolves references to packages and extracts metadata like the product code and product version. BurnExe also optionally builds a bundle — a copy of a stub with embedded data. For example, right now, BurnExe supports embedding the resolved manifest so setup.exe can be signed to help ensure the manifest hasn’t been tampered with. The plan is to also support embedding the UX DLL and packages to provide a single setup.exe download.

Any layer of Burn can be replaced. For example, I expect someone on my team to create a custom UX for Train Simulator 2. The Burn design focuses customizability in the UX so the other layers can be used as-is.

There’s plenty more work to do, so that’s it for today. More to come as more of Burn matures!