May 30, 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:
May 27, 2010
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.
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.
May 01, 2010
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.
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.
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.
Subscribe to:
Posts (Atom)