RobMensching.com /Blog
when setup isn't just xcopy

Let's talk about Burn.

A long while ago, Bob wrote a short blog entry about the WiX toolset's upcoming bootstrapper adoringly named Burn. We made some early progress back then but refocused our energy on finishing WiX v3.0 which recently released. Now I'm back to Burn which will release with WiX v3.5.

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/>

 

Tips on how to upgrade from WiX v2 to WiX v3.

Now that the WiX v3 toolset is released, I thought I'd share a couple tips for those users upgrading from WiX v2. WiX v3 is obviously a major upgrade from WiX v2 and there are a few breaking changes as a result. Fortunately, WiX v3 ships with a tool to help with the code migration (WixCop.exe) and then you only need to understand one new concept (extensions).

Code Migration via WixCop.exe

There are a number of changes to the WiX language (the wix.xsd) in v3. Our goal was to reduce duplication in the language and generally make it easier to work with. Of course, we know that language changes make the migration process very difficult for you. So we created a tool called WixCop that will fix your .wxs files.

WixCop.exe is very easy to use. Just give it the file you want updated. If you want WixCop to fix the file for you then add the "-f" switch. If you want WixCop to fix all of your files in the directory then use a wildcard like "*.wxs". If you want WixCop to fix all of your files in all of your directories add the "-s" switch.

For example, to fix an entire tree of .wxs source code then check out the files and run the following command:

C:\src>WixCop.exe -s -f *.wxs

It is very likely that if you try to compile now things will fail with errors like "The Component element contains an unhandled extension element 'util:XmlFile'.  Please ensure that the extension for elements in the 'http://schemas.microsoft.com/wix/UtilExtension' namespace has been provided." That brings us to the second second new WiX v3 concept.

Extension to the Windows Installer

The WiX toolset provides a library of custom actions that extend the Windows Installer to support things like IIS Web Sites, SQL Server databases, file shares and many other things. In WiX v2 those elements are part of the wix.xsd. That made it very difficult to tell what functionality was natively supported by the Windows Installer and what functionality came from custom actions.

In WiX v3 we separated all of the non-native functionality into separate XML namespaces so there would be no confusion. Then we created "extensions" that plug into the compiler and linker to parse the elements in the other namespaces and incorporate the required custom actions. In WiX v2 you were used to providing .wixlibs to the linker for the custom actions, extensions take care of all of that for you.

Using the same example from above, the error mentions that we need the extension that supports the "wix/UtilExtension". We call that the "WiX Util Extension" and you refer to it on both your compile and link lines like so:

C:\src>candle.exe my.wxs -ext WixUtilExtension
C:\src>light.exe my.wixobj -ext WixUtilExtension

The "-ext" switch looks for the WixUtilExtension.dll in the same directory as the compiler and loads it. The extension takes care of the rest of the work.

Extensions as the new UI

One last thing. The WiX v2 UI .wixlibs and .wxl files are now all part of the WiXUIExtension. That means you just need to reference the new UI extension. Below compares the how to use WiX v2 to link in WiX UI the how to do the same with WiX v3:

C:\src>C:\path\to\wixv2\light.exe my.wixobj %WIXUI_PATH%\wixui.wixlib
-loc %WIXUI_PATH%\WixUI_en-us.wxl

C:\src>C:\path\to\wixv3\light.exe my.wixobj -ext WixUIExtension

 

If you have any other questions about the examples above, please read through the WiX v3 Manual. If you find other things that aren't migrating well, drop me a note and I'll figure out the necessary changes. Good luck with WiX v3!

 

WiX v3.0 released.

It is my pleasure to announce that WiX toolset v3.0 is now officially declared Production/Stable. The final build number is 3.0.5419.0. You can download it from here or here.

The journey to release WiX v3.0 started about four and a half years ago. While WiX v2.0 was locking down and getting ready for it's release, we had a lot of ideas how to improve the language and better build integration with Visual Studio. Obviously, those ideas would destabilize WiX v2 so we decided to spin up an independent WiX v3 effort.

Early in the project it was clear that WiX v3 was a major improvement over WiX v2. Developers flocked to it for the file and directory short name generation feature alone. MSBuild integration in Votive was also a huge hit. Additionally features like @Id and Component/@Guid generation, smart cabbing, heat, and the best Windows Installer patch generation tools on the planet make WiX v3.0 a very important release.

When Visual Studio team members joined the WiX v3 effort it became clear that WiX v3 was also going to be the most stable release of the WiX toolset ever. There were over 900 bugs resolved during the course of the project. But a more important number to me is that we've postponed fewer than 10 bugs and each of them have a workaround. Comparatively, WiX v2 released with over 100 known issues all of which were fixed in WiX v3. All of this makes WiX v3.0 the most reliable set of tools you can use today to create Windows Installer databases.

We have also faced our fair share challenges while working to release WiX v3.0. We had to make a painful cut and remove Burn from the WiX v3.0 roadmap. That also prevented ClickThrough from reaching its true potential. Many of you probably also remember the in-the-box then out-of-the-box decisions by Visual Studio. That morale boost and breaker led to the decision that WiX v3.0 was ready now and could be released on America's Independence Day. Finally, a less visible but possibly the most difficult challenge that I faced was the complete turn over in the core developers. In fact, one of the things that excites me most about this release, is that everyone is coming back for the ship party.

Which brings me to my closing remarks. We're going to have a party. Tonight all over the United States there will be firework displays of varying scales and grandeur. While watching those pyro.exe.technic events light.exe up the dark.exe night sky with gigantic roman candle.exes celebrate with the team that brings you the WiX toolset.

We have a great time working on the WiX toolset and we hope you enjoy the efforts. WiX v3.0 isn't the end for us. It's just the most useable and stable release until we bring you the next one.

And until then keep coding. You know I am.