Let's talk about Burn.

What is Burn?

Burn is a bootstrapper/chainer. Because Burn is both, I tend to use the term “bootstrapper” and “chainer” interchangeably. I know some people like to have some distinction between the terms. However, I’ve found nobody agrees on the distinctions. I tend to lean towards the use of the word “bootstrapper” because it starts with the letter “b” and Burn was a cool name for the next WiX tool.

What is the purpose of Burn?

As you might expect from the name, a bootstrapper is responsible for getting the setup process started. You might expect that this should be unnecessary. Double clicking an MSI file should be sufficient to get the installation process going. Unfortunately, due to several design decisions in the Windows Installer there are a plethora of work items for a bootstrapper.

Burn also chains multiple setup packages to create a single installation experience. The original design of the Windows Installer expected that a product and all of its prerequisites would be installed via a single MSI file. That is why Merge Modules were developed. Unfortunately, Merge Modules do not meet the needs of all types of prerequisites and have some pretty serious deficiencies, particularly in relation to patching.

Thus the purpose of Burn is to provide a unified experience for initiating and applying one or more setup packages to the machine.

What are the features of Burn?

Let me just list the features planned for the first version of Burn. The complete list of features to implement in a bootstrapper is very long. Our first release is a balance of features vs. time to completion. As always, I welcome feedback. Particularly, if you think something important is missing.

• Size - you might not think of the size of the bootstrapper as a feature but it is very important to Burn. The goal is to keep the Burn overhead under 256 KB. Why? Well, we’ve found that with a broadband connections 256 KB equates to an almost instantaneous download and launch experience via Internet Explorer.

• Elevation - every bootstrapper I’ve seen gets elevation (aka: UAC) wrong or not-quite-right. The really bad bootstrappers prompt for elevation multiple times while others prompt before showing some branded UI. The real unfortunate part is that these bootstrappers cannot correctly handle per-user setup packages. There is a lot to elevation and I’ll talk more about how Burn handles it in the future.

• UI - let’s face it the Windows Installer user interface was designed in 1997 and it still looks like it. Burn on the other hand does not restrict the user interface at all. Setup developers provide a UX.DLL that has full control over the user interface and interaction (that’s why we call it user experience, or UX). In the WiX toolset we will ship a couple standard Burn UX.DLLs (just like we provide standard UI for MSI files). A stretch goal for WiX v3.5 is to allow the UX.DLLs to be written in managed code (think WPF).

• Progress - progress is one of the most visible aspects of setup and one of the hardest to get right. Burn does a lot of work to create a seamless progress system so it is easy for developers to create a unified user experience across multiple setup packages. For those of you familiar with the Windows Installer, this means the progress bar no longer resets twice during the install. I can’t tell you how pretty that is. <smile/>

• Download - redistributables (think .NET Framework and SQL Express) that are larger than the applications which use them are unfortunately really common right now. If you are distributing your application over the Internet (and how many people today aren’t?) shipping those redistributes in your setup is expensive. Burn has the ability to only download what the user needs and/or chooses to install. That means if the .NET Framework is already installed, no need to download it again. Also, when your product is broken up into multiple MSI files it becomes possible to optimize the distribution further. Oh, and did I mention Burn will support resume if the download server supports HTTP 1.1?

Those are the big features. I’m sure I’ve left out a lot of little things. Again, remember this is the first version. We’ll be back for more.

When is Burn available?

Burn is one of two key features in WiX v3.5. Votive support for Visual Studio 2010 is the other. We are planning to be done around a month after Visual Studio 2010 releases. Of course, the code to Burn is available right now but it is under a lot development and not at all stable. So, I would not recommend trying to use Burn too much until I get the WiX v3.5 install using it. Once WiX v3.5 is installing with Burn then you’ll know the core functionality is in place. That plus there will be a working example of how to create your own UX.DLL.

I hope we’ll be at that point by the end of July. A lot of that depends on how busy real life gets. Go, Sounders! <smile/>