Partilhar via


Core WiX toolset v2 shipped in a Microsoft product...

I had many goals for the WiX toolset since its inception six years ago. Obviously, being released as a true Open Source project was one of those goals that was met about a year and half ago. Another goal was to have the core WiX toolset (candle, light, wix) shipped as part of a Microsoft product. I don't mean having teams use the WiX toolset to build their product's setup package (although this was obviously one of the primary goals as well). I mean the goal where a team at Microsoft makes the WiX toolset a part of their product and ships the WiX binaries on their CD or in their web download.

Well, that latter goal has just been attained*. The November 2005 DSL Tools CTP has a couple new features. One of them is the "deployment". This feature was quickly described to me like this, the "Deployment feature allows you to build an installer for your DSL solution (by simply adding a DSL setup project from the New Project dialog) to distribute it to your customers".

How does it work? I don't know all of the intimate details but at a high level, the DSL Tools (which integrate into Visual Studio) contains a copy of the WiX toolset v2 that is installed into a private location. Grayson Myers, a developer on the DSL Tools team created the "DSL Setup Project". That project type introspects over all of the DSL projects in your Visual Studio Solution and generates a .wxs file. Finally, when you build your solution the WiX MSBuild Tasks are used to compile and link that generated .wxs file into a MSI file. The whole system is very slick and, from what I saw, required very little code to complete.

There is only one little problem that Grayson pointed out to me. The DSL Setup Project in this CTP currently generates the .wxs files with the extension ".wsx". This is a harmless bug that was found too late to fix for this CTP. Grayson assures me the correct extension will be used in the next CTP.

Couple last things I want to mention. First, the DSL Tools team devised and developed their setup project independently. They made no changes to the WiX toolset. Grayson told he just picks up drops regularly to ensure that his scenarios continue to work. Since the WiX toolset has always "just worked" for him, he quietly went about their business. The only reason I found out about the DSL Tools team was because they started asking questions around Microsoft if there were any concerns shipping the Open Source WiX toolset. There weren't but Derek and I quickly tracked down Grayson to discuss what they were doing and more importantly which version of the WiX toolset he planned to ship.

Second, I absolutely love what the DSL Tools team has done here. They had a set of very specific setup requirements for their developer scenarios. See their tool is a plug-in to Visual Studio that enables developers to build other plug-ins for Visual Studio (imagine the possible recursion! <grin/>). As we've learned with Votive, there is some boilerplate setup code that has to be written for each plug-in to Visual Studio.

Rather than force the DSL Tools team's customers (developers) to read a bunch of documentation how go about creating a setup package, they just do it via the "DSL Setup Project". However, because the DSL Tools team used the WiX toolset if a particular developer has additional setup needs then she can take the generated .wxs file and customize/extend it.

The DSL Setup Project is a specialized setup package builder. The WiX toolset provides the necessary foundation to make it easy (well, easier) to create specialized setup packages. ClickThrough is another example of a specialized tool to build setup packages. I think there is a lot of room for these types of targeted setup package builders. We're going to continue to make it easy to use the core WiX toolset to fit into these types of solutions.

In the meantime, keep coding, you know I am.

* To be truthful, the WiX v1 toolset actually shipped as a hidden part of some Media Player theme packaging tool (or something like that) back in 2002 or so. However, the WiX toolset was not available as Open Source or otherwise back then so there wasn't much for me to talk about. Plus, I didn't have a blog... <smile/>

Comments

  • Anonymous
    December 06, 2005
    I was just about to call you on the MediaPlayer deployment!

    Basically it was an Administrators tool that guided the user through a dos console session asking a series of text questions and possibly including some configuration settings from the PC into a config file. Basically it used WiX to build an MSI that called a custom action to do a silent install of the WM Setup routine. It was a complete kludge to deploy a non-msi product through AD GPO and didn't really use MSI technology.

    It's kind of like some of the MSM's I've seen out there were it just merges a custom action and a record in the binary table.... very hackish.
  • Anonymous
    December 06, 2005
    Heh, I never really understood how the Media Player thing worked. They sprung the whole project on me very late in their project cycle (literally a month before they were going to ship) saying, "You don't mind if we do this, right?" So, I guess it doesn't really surprise me that in the end the whole thing was rather 'hackish'.
  • Anonymous
    December 07, 2005
    Well I did feel the use of WiX was clever considering the scenario and congratulations on making into the DSLTools. I would have just hoped that the Windows Media team would have made an actual MSI and used WiX to transform it instead. But I guess its hard to make those kinds of calls when the product is becoming more and more part of the Base OS and being installed by sysocmgr in the future.