WiX vs InstallShield has long been a Red vs Blue debate. Some people believe that setup source is code and should be edited as such while others are in the camp that it’s just a document that should have visual designers to automate the workflow. Finally there are others who need to also be able to programatically update source files from time to time.
Each of these approaches have pros and cons so with IsWiX I decided to support them all. After all what’s garbage to one developer might be a treasure to another. Let’s look at these three great tastes:
Many of us live in the land of Windows and use tools like Visual Studio. We like to be able to point, click, drag and drop and cleanly visualize the results of our labor. Drag a tree of files from the Source view to the Destination view and let someone else do the work of writing the XML for us. As they say in Jamaica- No Problem Mon! You can create really nice UI’s with rich client side validation such a constraint for Module@Platform that provides a list list of types or maybe preventing a user from adding the same file twice. Properly designed UI’s and Domain Objects can generate code as clean as hand written code only you didn’t have to spend all day slaving over the computer to write it. Detractors will claim that it’s a crutch that prevents you from learning what is really happening behind the scenes but the same argument could be made of copy and paste and assuming all is well when it seemed to work. At the end of the day it’s up to the developer to turn on the curiosity gene and really understand the entire technology stack.
Some developers just hate reaching for the mouse. Give them a command line interface and VI and that’s all they need or want. Interestingly, many of these people work on Windows and DevDiv / Visual Studio @ Microsoft and that in itself is a life mystery that I will never quiet grok. Personally I think it’s some form of super-geek ‘I’m smarter then you.’ cult philosophy but that’s just a theory with no hard evidence. While I’m no stranger to the command line, ( My resume includes CPM, AmigaDOS, MS-DOS and various flavors of Unix ) I just don’t enjoy typing large amounts of XML. Still, it’s nice to be able to look behind the scenes and read what the visual designer actually did. It’s nice to get the XSD validation ( although not as protecting as client side validation ) and it’s nice to be able to make hand tweaks to generated code. After all, there’s always an edge case out there and graphical designers and code generators should never stand in your way of getting the job done. At the end of the day, you are smarter then the computer.
Finally, there are times ( for whatever reason ) when you just need to be able to inject a little magic into the process. You shouldn’t have to use raw XML DOM’s to manipulate the source nor should can you possibly use a graphical designer. Therefore, anything a graphical designer can do must also be possible programtically through an automation interface. Additionally, a well thought out automation interface can help create an ecosystem of tools that are currently unimagined.
Summary and Invitation
So that basically sums up the three great tastes of IsWiX. In thinking this over, it’s now clear to me that a best in breed solution should borrow ideas from both WiX ( XSD is wonderful ) and InstallShield ( Designers and Automation Interfaces Rock ). InstallShield is a wonderful product but I have several major concerns:
1) InstallShield’s use of DTD in it’s project format is dead to me. It’s barely readable/editable and is a nightmare once you get into branching and merging situations.
2) InstallShield needs to be rewritten. I can only imagine the hell it must be maintaining 10+ year old C++ code. It’s time for a reboot. Just as InstallShield embraced Windows Installer over a decade ago, it’s time for them to embrace the .NET framework and some form of XSD based document format. I vote for WiX.
3) In the area of Agile Software Development, InstallShield’s build automation story is really good but it falls really short in the area of Distributed Development. The Collaboration piece simply isn’t powerful enough and the pricing model and learning curve of the main IDE just doesn’t make it a good tool choice.
3) InstallShield’s Automation Interface is lacking in terms of API coverage. You have to resort to raw manipulation of the underlying tables every time you hit a wall. Additionally using it from .NET is a horrible excercise in COM Interop with no factory pattern or interfaces to allow you to easily switch your code from one version of the API to another. This beast was made for VBScript ( see #2 ).
4) I was reading about Paternerships vs Dependencies the other day and it made me realize: When pay up to $9500 per seat for InstallShield with maintenance and then do the activation dance, you are dealing with the latter. You are at their mercy to even use the software with no promises that they will actually fix their bugs or release features that are important to you. That’s probably fine for a lot of shops but I’ve been increasingly concerned by it. That’s saying a lot since I used to think of this as a parnoia argument.
WiX on the other hand has some clear technology advantages but continues to suffer from severe underfunding and narrow user stories. I’m convinced they are some very smart people and that most of choices that they have made that I’ve disagreed with in the past are really just a result of the realities of the available resources.
It’s with this in mind that I’ve decided to set out on creating IsWiX.
I’m throwing the gauntlet down:
Who will help me?
PS- IsWiX is intentionally released under the MS-PL license to enable anyone to take the ball and run with it. I’m under no illusions of grandeur or wealth – I just hope that my little contribution can somehow spark thought and improve this little domain we call deployment engineering / setup authoring. Regardless of what happens, it’s been a wonderful opportunity to develop my .NET skills while working in a domain that made sense to me. No doubt this will help prepare me for the inevitable day that I retire from writing installs.