Doctor Deploys Blog

This post is a follow-up to Rob Mensching’s "Visual Studio ships the WiX toolset" blog entry.

One of the key tenets WiX development is operating under is to make all changes available to both community WiX as well as "Rosario" WiX. (They actually get fixed for the community first :))

Each time we make a major "Rosario" WiX release, I plan to list the major differences between community WiX and "Rosario" WiX.

Differences:

Signing - The WiX binaries shipped with Visual Studio will be signed with a Microsoft signature rather than the community WiX signature.
Contents of the installer - In order to limit our test surface and ship the mainline tools in the highest possible quality, there are a few tools that will not be shipping in the VS package. Another option we are exploring is to supply some sort of SDK for the tools we don’t plan to provide mainline support for.
Supported VS versions - The "Rosario" WiX toolset will only install on VS 2008 while the community version will continue to install on both VS 2005 and VS 2008.
Nant - No support for Nant will ship in the "Rosario" box.

Original post by Petermarcu

Today Visual Studio released the Microsoft Visual Studio Team System code name “Rosario” November 2007 CTP. “Rosario” builds on Visual Studio Team System 2008 to enhance the collaboration between developers and needs of the business, plus increasing application quality and testing support. Now that you’ve heard the standard marketing pitch, I’m sure you are wondering why I am pointing to a random preview of functionality from the Visual Studio team.

Well, four months ago the Visual Studio setup team approached me to ask if I could help them with that first part of the “Rosario” mission: “enhance collaboration between developers.” They had already adopted the WiX toolset as the platform to build the Visual Studio installation package and were now seriously considering shipping the WiX toolset as part of the Visual Studio product. The VS team saw that the WiX toolset enabled developers to collaborate on installation package development and wondered what it would take get the WiX toolset in a state they could release and support for developers around the world.

When Valentina, the Development Manager for the Visual Studio setup team, first approached me about this possibility I immediately had a flashback to when releasing the WiX toolset externally was first discussed. That was 4 years ago when Stephen Walli and Jason Matusow and others were first discussing what open source license we should use to release the WiX toolset under (CPL) and where we should post the code (SourceForge)

At that time, Stephen and Jason asked me if there was any chance that Visual Studio would want to take the WiX toolset and “productize” it. I told them there was very little chance that they would ever do that. Visual Studio already had a solution for building Windows Installer databases (that was and still is very limited) and showed no interest in the WiX toolset. Besides, I argued, “Wouldn’t it be an absolute home run if the WiX toolset was released as Open Source then later incorporated into a shipping product?” At the time, I don’t think any of us believed it would actually happen.

So when Valentina asked me if I could help out a little bit by providing some guidance on how to work with the community and provide input on what needed to be fixed first, I jumped at the opportunity. Over the last few months, Visual Studio has staffed up a small team that focuses on improving the core WiX toolset, Votive and the Custom Action Library. For example, Peter Marcu, who is best known for his work on the new patching system in WiX v3, is primarily responsible for fixing bugs in the core toolset, integrating new drops of the WiX toolset into Visual Studio and occasionally shows up on the wix-users mailing list to answer questions. There are several others who work on other aspects of the project behind the scenes.

Rather than continue the story of how it came to be that Visual Studio chose to ship the WiX toolset, let me try to answer some questions that I can guess many of you might have.

Q: What version of the WiX toolset will Visual Studio ship?

A: Visual Studio is built on the WiX v3 toolset internally so it is natural that they chose to adopt the WiX v3 toolset going forward. Also, Votive in WiX v3 is better integrated into Visual Studio than the Votive in WiX v2.  For example, Votive v2 uses a custom build project while votive v3 uses an MSBuild compatible project. Since integration of WiX into Visual Studio is (obviously) so important, Votive is where much of the Visual Studio development activity is focused.

Q: Are the code changes made by Visual Studio team being checked back into WiX?

A: Absolutely. One of the key tenets I encouraged the Visual Studio team to adopt was that all changes to the WiX toolset were immediately made available to the rest of the community. They were completely open to that suggestion so you can see bug fixes coming in every week or so (depending solely on how quickly Peter and I get the changes integrated). The team has just been very quiet about their work thus far since “Rosario” was still undisclosed.

Q: Will Visual Studio ship everything that is in the WiX toolset today?

A: Okay, this might not be a question on the tip of your tongue but I did want to point out that “Rosario” will include a subset of the WiX toolset of their choosing. For example, Votive is definitely in but the WiX Nant tasks are very likely not. At this point, the scoping decisions are completely based on how much the test team feels they can verify before “Rosario” ships. One of the hardest remaining “cut” questions is whether pyro and the new patch support will make it for “Rosario”. I’d love to see it in but we’ll see if there is time to get it stable.

Q: When does “Rosario” ship?

A: I don’t know the final ship date (I don’t know if anyone knows) but I’m assured it won’t be earlier than end of 2008. This was important because I always had in my mind that WiX v3 wouldn’t really be feature stable until the end of 2008 and that we’d go into 2009 with bug fixing. With Visual Studio putting a number of developers on the project full time to address the bugs, I am now confident WiX v3 will be good to go by the end of 2008.

Q: Will WiX replace the current Visual Studio Setup Projects in “Rosario”?

A: No. “Rosario” is a very short release so the WiX toolset is being added on top of everything else. The current Visual Studio Setup Projects have a number of visual designers to ease the development of installation packages but does not enable collaboration across developers. The WiX toolset has a steep learning curve but has a number of features that enable different developers to collaborate on one to many installation packages.

Q: Will “Rosario” include any visual designers for the WiX toolset?

A: At this point in time I don’t expect there will be any visual designers for the WiX toolset built in the “Rosario” timeframe. Again, this is a very short release and there is a lot of existing code that the test team needs to verify. I expect that the primary output from “Rosario” will be a very stable WiX v3 toolset integrated extremely well into the Visual Studio project system.

Q: Bummer, dude.

A: That isn’t a question but the sentiment is shared by a great number of developers on the project. I try to remind everyone that the work in “Rosario” provides a great foundation to do some very interesting work in the next few releases of Visual Studio. So, let’s hurry up and get “Rosario” done and move on to those other interesting features.

Q: So what does “Rosario” provide?

A: There are two key features that I believe “Rosario” provides. First, there will finally be a clean “out of the box” experience to build Windows Installer databases (.msi/.msm files from .wxs source code) on your Visual Studio Team Server build servers. There have been a lot of requests for this functionality both to the Visual Studio team as well as those of us that work in the WiX community. Second, Microsoft will provide support for the WiX toolset that is part of “Rosario”. Again, I’ve heard many reports of customers asking for Microsoft to provide support services for the WiX toolset and with “Rosario” their support requests will finally be answered.

Q: Will I still be able to use the community built WiX toolset with Visual Studio?

A: Yes. This was the second tenet I encouraged the Visual Studio team to adopt and they are doing their best to make switching out the “Rosario” WiX toolset with the community WiX toolset a reasonable experience. There are some technical challenges (inside Visual Studio itself) that look like it will not be possible to have both versions installed at the same time. So, the goal is to make it easy to uninstall the “Rosario” WiX toolset and install the community WiX toolset. Since the November 2007 CTP of “Rosario” is shipping as a virtual PC image we haven’t tackled all of these issues yet.

Q: How will the WiX toolset in “Rosario” be different than the community WiX toolset from SourceForge?

A: As I noted above, “Rosario” will ship a subset of the WiX toolset so there will be tools and functionality available on SourceForge that is not going to ship in the box. Also, Visual Studio might modify some cosmetic things (like the icons and assembly signatures) so developers can differentiate “Rosario” WiX toolset from the community WiX toolset. Finally, the community WiX toolset will continue to be developed after “Rosario” ships so there are an untold number of improvements we might choose make that won’t be in “Rosario”. I’ll encourage Peter to list any differences between “Rosario” and what is available in the community.

Q: Should I wait for “Rosario” instead of getting VS2008 now?

A: You could but I wouldn’t do so for the WiX toolset changes. We’ve already made the changes (thanks to Aaron) to support WiX on Visual Studio 2008 (that just released, yippee!). That means you can see (and benefit from) the developments made for “Rosario” every week or so on SourceForge. When “Rosario” finally ships then you will have an integrated installation experience and have Microsoft support backing up the product.

Q: So does this change anything in the WiX community?

A: I don’t think so. The same set of people still lead the project (myself, Bob, Justin, Peter) and we still hold the same vision: “Create a set of tools that integrate into the development process so all developers can build high quality setup packages.”  Now there are a few more developers working full time towards that vision. I couldn’t think of a better thing for the community.

 

Original post by Rob Mensching

I’ve had a number of people ask me lately if there were any editors for the WiX toolset. This question surprised me because I thought the common WiX editors were easily found in one search query. Turns out neither query really covered the list of WiX editors that I often heard bandied about so I thought I’d write them down here.

I would like to note that this list isn’t really meant to be the authoritative list of all editors for the WiX toolset. These are just the list that I’ve heard people talk about most. Of course, since there are differences between WiX v2 and WiX v3, I’ve split the list of editors in by version.

WiX v2 editors

• SharpDevelop 2.1 (open source) - is something of an Open Source Visual Studio clone. However, rather than build a clone of the limited Visual Studio Setup Projects SharpDevelop chose to integrate WiX v2.
• Votive (open source) - is released as part of the WiX toolset to provide project integration into Visual Studio. Votive that shipped in WiX v2 is not very feature rich and has stability issues.
• WixAware (commercial) - was the first commercial editor built on the WiX toolset. WixAware tightly integrated their visual designers and text editor so edits in one display in the other.
• WixEdit (open source) - was the first open source editor built on WiX v2 to have a visual designer. WixEdit is unique in that it adapted to the monthly releases of the WiX toolset.

WiX v3 editors

• Setup Factory for Windows Installer (commercial) - was the first commercial editor built on the WiX v3 toolset. The lead developer for Setup Factory participated in the WiX community (by answer other’s questions) months before announcing their product demonstrating (IMHO) some appreciation for the community.
• Votive (open source) - is a much improved version of the Visual Studio package provided with the WiX toolset. Votive is far more stable and integrates deeper with Visual Studio, Team System and MSBuild.
• WixEdit (open source) - continues to adapt to the changes in the WiX toolset. The latest version of WixEdit supports the latest versions of both WiX v2 and WiX v3.

I’m sure there are plenty of WiX editors out there that I’ve missed so feel free to leave a comment down below with links to other quality tools. Finally, in case you’re wondering what tool I use to edit my .wxs files, I typically use Votive for large projects or demos and Notepad2 for my day to day tweaks and bug fixes. The same goes for my .cs file editing (Visual Studio for large projects and Notepad2 for tweaks).

 

Original post by Rob Mensching

A couple weeks ago I sent out a proposal to move the WiX v3 toolset to the .NET Framework 2.0. There wasn’t much of a response but those that did were positive towards the proposal. I think most people just assumed that the WiX toolset required the .NET Framework 2.0 already. I also think that most developers have already adopted the 2.0 CLR so the dependency is no big deal. Finally, I also expect those developers still building on the .NET Framework 1.1 are probably using the WiX v2 toolset.

Anyway, tonight Bob and I started the process of going through all the tools that still build for the 1.1 CLR (candle, light, dark, heat, pyro, melt, wix.dll, almost all of the extensions, basically everything <smile/>) and converting their NAnt .build files into MSBuild .csproj files. Technically speaking we could just continue to NAnt but I get continued requests to use MSBuild (everyone has their reasons, the most common being that VS natively understands MSBuild projects) so I figured now would be a good time to do the switch.

Of course, there are some tricky things we do in the WiX toolset (like removing the insignificant white space and comments from XML files before embedding them into an assembly) that are turning out to be interesting exercises to execute in MSBuild. A long while ago, Justin created a bunch of MSBuild tasks for many of the things we needed to do. Unfortunately, tonight we learned a couple of them didn’t work. Figures that Justin wouldn’t show up tonight as well. <smile/>

So progress is underway. I expect it’ll be a couple a another week or three to get done with the holidays coming up. We basically have to do the whole move at one time once we start with wix.dll, since everything is dependent on that assembly. I’ll send out more updates when we have them.

 

Original post by Rob Mensching

Last night, everything came together and the changes to add binary delta patch support to WiX 3.0 went in. The feature is minimally documented but the schema and docs have descriptions of the new elements and attributes. I hope to get time to provide more details soon but I wanted to tell everyone that its in there so you can start playing with it if you’d like.

Original post by Petermarcu

The preprocessor in WiX allows extensibilty at a few levels. In this article I will describe how to add a PreprocessorExtention to your WixExtension and have it handle variables and functions you define in your own namespace.

[This sample assumes you have already gone through Part 1]

1. Add a new class to your project called SamplePreprocessorExtension.
2. If you added a new file for this class, make sure you add: using Microsoft.Tools.WindowsInstallerXml to you file.
3. Make your SamplePreprocessorExtension class implement PreprocessorExtension.

public class SamplePreprocessorExtension : PreprocessorExtension

4. Add your SamplePreprocessorExtension to your SampleWixExtension class and override the PreprocessorExtension property from the base class. This will make it so when WiX asks your extension for your preprocessor extension, you extension will know what to do.

private SamplePreprocessorExtension preprocessorExtension;

public override PreprocessorExtension PreprocessorExtension
{
    get 
    {
        if (this.preprocessorExtension == null)
        {
            this.preprocessorExtension = new SamplePreprocessorExtension(); 
        }
        return this.preprocessorExtension;

    }
}

5. Now, back in your SamplePreprocessorExtension class, you need to specify what prefixes (or namespaces) your extension will handle. For example, if you want to be able to define a variable $(sample.ReplaceMe) then you need to specify that your extension will handle the “sample” prefix.

private static string[] prefixes = { “sample” };
public override string[] Prefixes { get { return prefixes; } }

6. Now that you have specified your prefixes, you now need to handle variables and functions that are passed to you from WiX. You do this by overriding the GetVariable and EvaluateFunction methods from the PreprocessorExtension base class.

public override string GetVariableValue(string prefix, string name)
{
     string result = null;
    // Based on the namespace and name, define the resulting string.
    switch (prefix)
    {
        case “sample”:
            switch (name)
            {
                case “ReplaceMe”:
                   // This could be looked up from any where you can access from your code.
                   result = “replaced”;
                   break;
            }
            break;
    } 
    return result;
} 
  
public override string EvaluateFunction(string prefix, string function, string[] args)
{
    string result = null;
    switch (prefix)
    {
        case “sample”:
            switch (function) 
            {
                case “ToUpper”:
                    if (0 < args.Length) 
                    {
                        result = args[0].ToUpper();
                    }
                    else
                    {
                        result = String.Empty; 
                    }
                    break; 
            } 
            break; 
    } 
    return result;
}

7. Build
8. With this you can now pass your extension on the command line to candle and expect variables and functions in your namespace to be passed to your extension and be evaluated. To prove this, try adding the following properties your WiX source.

    <Property Id=”VARIABLETEST” Value=”$(sample.ReplaceMe)” />
    <Property Id=”FUNCTIONTEST” Value=”$(sample.ToUpper(lowercase))” />

You resulting msi should have entries in the Property table with the values “replaced” and “LOWERCASE” in the property table.

Original post by Petermarcu

Wix extensions are used to extend and customize what WiX builds and how it builds it. I plan on talking about the 3 most common types of extensions in this article series; ProprocessorExtension, CompilerExtension, and BinderExtension.

The first step in creating any set of extensions is to create a class that implements WixExtension. This class will be the container for all the extensions you plan on implementing.

Creating a bare-bones WixExtension

1. Create a new C# library (.dll) project named SampleWixExtension
2. Add a reference to wix.dll to your project
3. Add a using statement: using Microsoft.Tools.WindowsInstallerXml;
4. Make your SampleWixExtension class inherit from WixExtension.

 public class SampleWixExtension : WixExtension {}

5. Add the AssemblyDefaultWixExtensionAttribute to your AssemblyInfo.cs.

 [assembly: AssemblyDefaultWixExtension(typeof(SampleWixExtension.SampleWixExtension))]

6. Build

7. Although it wont do anything yet, you can now pass the your SampleWixExtension.dll on the command line to the candle and light with the -ext flag like this:  candle Product.wxs -ext SampleWixExtension.dll

The next article in this series will explain how to add a Preprocessor extension to your WixExtension.

Original post by Petermarcu