Doctor Deploys Blog

Many times people want to take advantage of the Wix v3 patch building features but didnt build their original product using Wix. for example, they may have used Install Shield, WiX v2 or one of the other tools out there. I ran into this when I needed to create a patch for a product we shipped from Visual Studio before the Visual Studio build moved to WiX v3.

 WiX v3 has a feature I added a while back to support this scenario. It allows you to point at an admin image of your msi based install package. This will be very familiar to some of you who have used patchwiz and pcp’s in the past. The difference here is that your patch authoring can be done using the WiX v3 Patch element and it follows the same workflow as patching a WiX v3 based msi after the first stage of creating the diffs.

Something I found really easy, and I could see this being used by smaller products who dont have a lot of infrastructure, is the ability to hand edit your admin image to product the patch. For example, I wanted to update a single file in my product:

1. I created an admin image
2. I made a copy of the admin image
3. I updated the loose file in my copy of the admin image

After running it through the series of command lines, I got a patch that updated the file. Pretty simple…

The command lines you need to run are all the same as the ones in my sample: Building a Patch using the new Patch Building System - Part 3. The only difference is that you need to pass the -ax command with a path to extract embedded binaries to instead of the -xi switch. This tells torch that the input is admin image instead of xml. Also, specify the path to the msi in the admin images instead of the wixpdb as the target and upgrade. Everything after that should follow the same process.

Let me know how it works!

Bonus feature: One of the most useful things in the WiX v3 patching system is the ability to filter whats in your patch using patch families to only ship your customers the updates they need. This allows you to grab changes per Fragment from your wix source. When patching from admin images, there is no source so you would think that the filtering isn’t suppoted. Not so! This was one of the more fun parts of this implementation. We “auto-fragment” the msi into what we consider to be the optimal chunks to give you the ability to filter if you choose to do so.

Original post by Petermarcu

I should have made this post about 6 months ago as I was implementing the WixPdb feature in WiX but better late than never :).  The wixpdb was conceived as a solution for a limitation in the original patch building system. Originally, WiX v3 patching only supported creating transforms between two wixout files. This was flawed in that many things modify the output after the wixout is generated by light which weren’t being reflected in patches. I knew I needed the patch build system to be able to create transforms from something closer to the final output. Thats what the WixPdb is. It is all the data in the output right before creating the final msi. With that data, we can now create more accurate transforms to what people expect when diffing two products. I updated my blog with samples on how to build patches to show that I now recommend using the wixpdb instead of the wixout.

Down the road, I look forward to seeing what other features we can get out of the wixpdb. It provides a ton of information an allows you to potentially connect install time errors all the way back to the wix source and line number. Static analysis is another benefit. I updated smoke to be able to take the wixpdb so it will give you source and line number information for ICE errors. Statis analysis on the wixpdb itself may also be interesting because it contains more data than in the msi. It is the one place where the wix source data and the msi data connect. Let me know if you have any ideas of how to use the wixpdb in some cool ways…

Original post by Petermarcu

As of a few weeks ago, the BinderExtension class in the wix extensibility model has taken on a new meaning. If you currently have a BinderExtension, you will need to rename it to BinderFileManager. Over the past year or so, numerous requests came in to give WixExtensions access to data and bind time to pull disperate data together or get access to data only available at bind time.

For example, if I have a custom table where I need to know the exports of all my native dll’s and I want this table to be populated dynamically by wix, I would need to have access to populate my table after files are resolved. With the new BinderExtension class, this is now possible.

Key Changes:

What used to be called BinderExtension was renamed to BinderFileManager. The BinderFileManager handles things specific to a files, mainly file resolution and comparison. Only one instance of a BinderFileManager can be present in the WixExtensions passed to the wix tools and is commonly used in an extension specific to a build environment.

It is now possible to have a BinderExtension defined in each WixExtension passed to the command line tools. This allows you to:

1. Link disperate data associated with compile time language extensions. It essentially enables extensions to make additional decisions that the WiX linker cant do for you because it doesnt natively support your language extension. Once the linker has pulled all the data together, it may be neccessary for you to read that data and populate additional tables.

2. Populate tables with bind time data such as information from files which are resolved during bind.

 In my series abut writing WixExtensions, I plan to show an example of this functionality. I plan to pick that series back up soon.

Original post by Petermarcu

I’ve been meaning to post about this for a while but just never got around to it. A few months ago I extended the implementation in WiX to allow foreach loops using any variable over any given set of values. Previously it was limited to only those variables that were defined in your preprocessor extension.

While this example wont do much for you, it demonstrates what a foreach loop will do. <?foreach?> loops can simplify authoring in many ways, especially for complex products.

Example:

<?foreach number in 1;2;3 ?>
    <Property Id=”Property$(var.number)” Value=”value$(var.number) />
<?endforeach ?>

Will result in the following being passed to the compiler:

    <Property Id=”Property1″ Value=”value1 />
    <Property Id=”Property2″ Value=”value2 />
    <Property Id=”Property3″ Value=”value3 />

I want to note as a caveat, It can be very easy to break component rules by changing the contents of a component by simply changing the values you iterate over. I recommend not using foreach loops anywhere near components unless you have really thought it through.  Also, while using the preprocessor can be very handy for minimizing the amount of wix code you need to maintain, it can really confuse some of the tools that are out there that help you generate or maintain your wix source. In general, think about other options before you use the preprocessor as a solution but if you think its your best option, enjoy

Original post by Petermarcu

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