Monthly Archives: May 2010

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


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.


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.


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.