IsWix Release Cake

I am writing this entry with a deep sense of contrition. I was supposed to have published it 6 weeks ago while Chris Painter was off in paradise. Instead, my wife gave birth to our first child and the last six weeks have been a blur. So without further ado:

In order to celebrate the launch of IsWiX, I was given the solemn responsibility of picking up the launch party’s cake. In order to ensure maximal embarrassment, I tricked Chris and his dev team into taking the thumbs up picture. They were told that the picture was going to go on the SharePoint site.

Long time readers of the blog have seen Chris wade into the murky depths of the Red vs. Blue installer argument. In order to highlight the sea change in his view of WiX, I had the cake decorated in red icing. The coup de gras being the “thumbs up” picture added to the cake with the text “WiX Rules #1”.

Of course this was a gentle poke in the ribs, but it also speaks volumes as to how we all should avoid getting too locked into a specific tool. We should always focus on the right tool for the right job. Chris came to this conclusion and with his efforts our organization is currently embracing a decentralized installation model.

Improving InstallShield Product Configurations

InstallShield has a concept called "Product Configurations" that allows you to define similar yet different installers that generally contain different sets of features and metadata ( such as ProductCode, UpgradeCode, ProductName, ProductVersion ). It's a pretty powerful feature that uses flags to join products to features.

Consider the following:

Feature1
Flag 1

Feature2
Flag 2

Feature3
Flag 3

Product Configuration 1
Flag 1,3

Product Configuration 2
Flag 2,3

PC1 will get features 1 and 3 while PC 2 will get features 2 and 3.

Let's look at it another way:

Feature1
Flag A

Feature2
Flag B

Feature3
Flag A,B

Product Configuration 1
Flag A

Product Configuration 2
Flag B

Again, PC 1 will get features 1 and 3 while PC 2 will get features 2 and 3.

Make sense so far? Now here's where it falls apart IMO.

The flags are limited to 255 characters and when you scale to hundreds of features and dozens of products it's really easy to

a) run out of flag space
b) back yourself into a corner trying to figure out which products get which features based on which flags.
c) You are updating the installer source code every single time make a change for any of your products.

Basically it turns into a maintenance nightmare.

So here is I turn to a blend of WiX and InstallShield Automation to help solve the problem. Instead of declaring the product configurations in the Basic ISM project we split them out into WiX fragments that look like this:

WiX Config Files

<?xml version="1.0" encoding="utf-8"?>
<Include>
<?define ProductConfiguration="1"?>
<!-- define other meta here -->
<FeatureRef Id="Feature1"/>
<FeatureRef Id="Feature3"/>
</Include>

<?xml version="1.0" encoding="utf-8"?>
<Include>
<?define ProductConfiguration="2"?>
<!-- define other meta here -->
<FeatureRef Id="Feature2"/>
<FeatureRef Id="Feature3"/>
</Include>

You can then take this farther by the use of FeatureGroups's.

<?xml version="1.0" encoding="utf-8"?>
<Include>
<FeatureGroup Id="Client">
<FeatureRef Id="Feature1"/>
<FeatureRef Id="Feature3"/>
</FeatureGroup>
<FeatureGroup Id="Server">
<FeatureRef Id="Feature2"/>
<FeatureRef Id="Feature3"/>
</FeatureGroup>
</Include>

<?xml version="1.0" encoding="utf-8"?>
<Include>
<?define ProductConfiguration="1"?>
<!-- define other meta here -->
<FeatureGroupRef Id="Client"/>
</Include>

<?xml version="1.0" encoding="utf-8"?>
<Include>
<?define ProductConfiguration="2"?>
<!-- define other meta here -->
<FeatureGroupRef Id="Server"/>
</Include>

Build Automation

Since InstallShield doesn't 'do' WiX out of the box, the trick is to write a custom build automation step that parses the WiX XML documents and translates them into InstallShield source code using the COM Automation Interface. You can do this in any language that supports XML DOM parsing and COM. Personally I like like to use C# / .NET 3.5 with LINQ-To-XML for my DOM and a generated interop for the COM. Basically you have to parse the XML and walk the InstallShield project and wire it all up as if you had authored it all by hand.

I'll cover this part of it another day.

Thirteen ( And Four ) Years and Loving It

I meant to write this blog entry three weeks ago but it just never happened. Better late then never, right?

Cheryl and I were married on May 10, 1997. On our anniversary in 2006 she was diagnosed with cancer. That makes 13 years of marriage and 4 years of surviving the big C.

With the help of two wonderful friends who volunteered to watch our girls for the week, we packed our bags and headed to an all-inclusive in Jamaica. It was great to just unplug from the world and spend time with the person that I love with all my heart.

Cheryl, thank you for all the memories, past, present and future. I love you!

And finally, no trip to the Caribbean would be complete without experiencing the power and the beauty of the great deep blue:

IsWiX 1.0.264.0 Available

When we first developed IsWiX, we had an internal business rule that said all non program executables would be authored as non-key files. This was for two main reasons:

1) We only supported Major Upgrades so we didn't care about servicability issues.
2) We had 15,000+ files in our install and 1:1 authoring had a major performance impact.

I understand that not everyone will have these assumptions. Therefore IsWiX 1.0.264.0 now supports the ability to override the default behavior of 1:many with 1:1. To do so, simply right click the source files list and use the context menu to change the behavior.

This is useful when:

1) You want to be able to support Small Updates, Minor Upgrades and Patching
2) You want increased resilency checking
3) You have relatively few files or you aren't concerned about the performance impact.
4) You have files that need to be keyfiles so that you can manually inject additional WiX metadata.

I'm open to any and all feedback so please take a look at it and let me know what you think with your comments.

Distributed Setup Development Revisited

Last summer I wrote an article talking about the advantages and disadvantages of InstallShield versus Windows Installer XML and a Setup Democratization journey I was about to embark on. Nine months later the battle has been won and I have a few high level observations to report.

Distributed Setup Development Can Work

Back in 2005 I was involved in a distributed setup development environment that was a complete disaster. The combination of vdproj/installutil and poor software architecture choices had resulted in me being very jaded against the notion of sharing responsibility of developing setup with the developers. Unfortunately, the model of centralized setup development can only scale so far before the quality of the installer declines not because the setup developers don't know how to write good setup but because they just can't keep up with the sheer size of the application domain. They simply don't know enough to be able to help make good decisions. Eventually this becomes just as fatal as the very model that first jaded me into not sharing any responsibility.

In 2009 I found myself at this breaking point and decided to once again try setup democratization. This time, I wanted to find just the right blend between centralized and decentralized. I believe with WiX, InstallShield and a little out of the box thinking we've succeeded in doing just this and that we will be able to scale for many more years to come.

Visualization

One of the biggest problems developers had was they couldn't easily see into the structure of an installer or compare the installer to previous builds or other installers. Sure, I could try to teach them to use orca, perform administrative installs or do other tricks but what they really needed was a powerful "Google Earth" style tool that really lets them drill down through and search across to get situational awareness. Once they had this capability they could make better choices.

Simplification

Application developers don't have 6 months of free time to learn the Windows Installer . They need to be provided a short training session with an important set of rules to not break. The component rules can be basically explained by quoting The Highlander Movies: 'There can only be one.' Tell them that MSI is a declarative not imperative language. Relate it to things they understand like WPF and XAML. Explain to them to not ask for things like xcopy, regsvr32, regasm, gacutil or installutil. Instead ask them to ask for things at a higher level such as register a (un)managed file, deploy a file to the GAC or install/start a service. Finally provide tools that allow them to self-serve the majority of the heavy lifting: Files and Folders. Provide a tool that is simple to use yet still creates XML documents that follow the component rules and allow for adding in additional metadata by the setup experts. Finally, invest in making strong relationship with the developers. The setup developers will find themselves with more free time to go around and consult with the developers to help bridge the gap between application domain knowledge and setup domain knowledge. Both sides will gradually learn more about the other.

Validation

Entropy applies to setup. The best way to preserve the order that you fight so hard to create is to perform extensive validation with each build. Don't allow one mistake to build upon another. Fail the builds and get your problems fixed ASAP. Make the mistake bubble up to the developer in a way he will understand and know to not repeat.

WiX and InstallShield can Complement Each Other

Usually one thinks about WiX *VS* InstallShield. I now no longer see it this way. I now see it as WiX *AND* InstallShield. Each tool has strengths and weaknesses but blended together result in a very powerful platform. However, I do believe that is time for a fully functional InstallShield style IDE to be built upon the WiX schema. I openly hope that InstallShield will take this challenge. Until then I will be building IsWiX and I hope others will either join me.

Introducing IsWiX

You may recall back in September I posted that I was working on a WiX editor. Today, after 7 long months, I humbly present.....

Industrial Strength Windows Installer XML ( IsWiX )


I wish I had the time available to do a proper launch but unfortunately my schedule for the following week doesn't allow it. My doppelgänger has offered to blog about what has been and what is to come.

There is of course a snag. My doppelgänger is now my newly minted manager so it's a little hard to force him to write. He does have an incentive though: He has in his possession a very embarrassing picture of me and my IsWiX development team clearly crossing over to the dark side of WiX.

So please, take a look at IsWiX and be gentle. The feature set is only deep in a couple of areas as the development was focused on what we needed at my work. Hopefully Chris will be able to explain our vision without giving out too much information about how we roll.

Meanwhile, I hope the my friend Chris goes gentle on me and does a good job of telling the story. After all, while I'm using the red flame more and more these days, I remind everyone that the blue flame burns hotter and faster.

Finally, I'd like to thank my employers for their generosity in supporting the reassignment of this software to me so that I could publish it as open source.

.NET 4.0 Install First Impression

I was installing Microsoft.NET Framework 4.0 tonight and I couldn't help wonder something. Is this the best UI Microsoft could come up with? Seriously, this text control only shows 1 of 44 lines in the EULA. Yet look at all that empty space down at the bottom of the dialog.

Is this for real?