Summary
In which I complain about Installshield and extol one or two of the virtues of Ant by contrast.
Advertisement
Since moving to this new company I have been snowed under. In the last couple of weeks though we have made version one and even better than that have a six month plan. All of which means that I can start paying attention to the less than critical things in life like this weblog.
One of the key parts of my role here has been to help shift the development from being primarily project oriented to being ring-fenced away from the project work and running to its own timetable. As part of this a lot more process has been put in place as you might expect. We are in the process of automating a lot of this and I wanted to talk about my contrasting experiences with two related components. Let me quickly outline what was needed:
Installer: as with most products the need to deliver the application to a target machine is essential. For various reasons our product consists of a VisualBasic front end complete with various ActiveX controls, a configured JBoss Server and our J2EE application and config and some Database scripts. Installing it should just be a matter asking the user some questions, copying the files onto the machine and setting some values in the configuration files.
Release Mechanism: On any given machine we need to be able to build either a release of the latest code or any given earlier release. Building a release involves getting all of the 8 or 9 modules from CVS, building them including running their unit tests and manipulating their build scripts so that they deliver all of the components ready for making the installer, getting the version file out of CVS and updating it, labeling all of the projects in CVS if we are building the latest version, modifying version information in the code and setup and finally building the installer and then deleting everything except the setup files.
One of these was very easy and one was ridiculously hard. If I told you that I built the installer using InstallShield and the release mechanism in Ant then you may be able to guess which was which.
InstallShield
There is a book in the office called The official InstallShield for Windows Installer Developers Guide. The first chapter is about the philosophy of installers. The second chapter is a field by field guide to the underlying database schema of Windows Installer in all its mind numbing context free detail. Now forgive me for being optimistic but as someone developing an installer what I would like is a gentle example based introduction. In fairness the documentation that comes with the product is better and was my main source of information during the development. This however follows what I have come to recognize as typical Microsoft style documentation:
How to build a house: Bricks may be attached to each other using mortar. Prepare a mix of mortar and apply to the surface on which you wish to attach the bricks. Smooth level with your trowel and place the brick as required. Repeat this process to build walls. By adding floors, windows, an electrical system, plumbing and a roof you will soon have a house.
Installshield would appear to be a very powerful product but I doubt that most people use even 10% of its features. The learning curve for anything but the most basic features is very steep. More often that not some vital step is undocumented for example its easy to make your own dialog boxes to ask the person installing for information. Windows installer automatically adds a title to these user defined dialogs. It took me three days to figure out how to change the title so it didnt say Your title here and I only found the information on a section on someones website for undocumented InstallShield functions.
Ant
Ant on the other hand is a joy to use. Prior to ant the main way for automating the numerous steps required in building a complex program was by use of a program called make. Make was written in the days when the more obscure something was the better it was deemed to be and its one of those programs that I had to relearn every time I tried to use it. Ant on the other hand is designed to be clear and easy to maintain and use. It uses XML which may or may not be a good thing but is always clear and even if you dont know ant well you can usually figure out what is going on. The plug-able architecture means that its easy to add new features and if that is not enough you can script it using any BSF language. The scripting is quite cool you have full access to the underlying API and can in fact generate the build script on the fly if you so wished. We simply use it to parse the version label and select different CVS actions depending on whether you are building the latest version or re-building an older one.
Conclusion
I am sure that there is a moral to this however my main purpose here is to get my annoyance at InstallShield and Windows installer off my chest. It strikes me that it would be a good open source project to build an alternative to Windows installer around Ant it would be easy to add a GUI using a wizard framework there is a good Java one (we used it at my last company) and I have seen web pages referring to a Python one as well although I am not sure if this is still active.
InstallShield is very typical of the Microsoft way of thinking adding features that they think people may need rather than the open source method of making something you want and then other people adding the features that they need. You still end up with obscure features but on the whole most of your product is geared towards things people actually want to do.
I couldn't agree more on the InstallShield side. I had a similar experience with InstallShield and that horrible monstrosity of a book. After getting over the shock of a book on an installer that was as thick as a book on J2EE, I remember laughing out loud upon seeing the several chapters on "architecture" and the "database schema" of the thing. Give me a break! I don't want to spend weeks or even days to understand some contorted and overly complex "installation architecture," I'd just like to copy some files and add some registry settings, please.
On top of that, when I tried to find a few useful tidbits (how to run silently, how to prevent automatic reboots, how to dynnamically configure a silent install to use the correct localized directory names, etc.), they were not in the book. Google was cheaper, quicker, more lightweight and useful in this regard.
This "technology" is probably one of the best examples of worthless bloat to be found. I'd rather make a WinZip self-extrator that runs a Python (or other) script, or even a little setup exe any day.
For some nutty reason, companies feel they must use it. Because it is Microsoft's and they don't trust the smaller simpler solutions from companies like Wise or Nullsoft? I don't know. On the project I'm working on, we have a full-time employee whose main responsibility is doing battle with the InstallSheild (MSI) installer. That is 1/4 the development team. This project is integrated with other projects from other parts of the company which are delivered as about 500 MB of MSIs. When we started the project, I said maybe we should not use InstallSheild, since our part needs to run silently and didn't need all the MSI bloat. That comment was greeted with incredulous looks and the reply that "everybody else is using it."
On some of the stickier issues, the guy doing the installer comes to me for help. The result of this is that the installer launches Python scripts to clean up various things. It is probably possible to do these things (moving links to/from the Start Menu or desktop, depending on different DMI configuration settings and stuff like that) somehow in InstallShield directly, but it takes a fraction of the time (for me, someone who is not and doesn't want to be, an expert in InstallShield) to do it this way.
Okay, I guess I've ranted enough already. I do like the idea of a clear and simple open source installer. I'll have to check on SourceForge and see what's already in the hopper (if anything)... just as long as it doesn't use XML for configuration files!
NSIS is a scriptable win32 installer/uninstaller system that doesn't suck and isn't huge. It adds an overhead of only 34 KB. NSIS 2 includes a new modern user interface, supports multiple languages and features an easy plug-ins system.
The key to successful un-installation is discipline while installing in the first place. It should be a simple matter of deleting your program directory, some Start Menu links and your registry settings (for each of the users (HKU), the program (HKLM), any COM registrations and any file associations (HKCR)). Things get messy when you start unnecessarily dumping lots of stuff into the system directory or Global Assembly Cache and other shared respositories.
InstallShield purports to handle un-installation automatically, but in reality does a terrible job of it. Try un-installing some apps and check how much cruft is left behind.
One thing in particular that has always annoyed me about un-installers (including but not limited to InstallShield) is their stupidity with regard to the Start Menu. They should take it for granted that people will move things out of the root of the "programs" sub-menu into categorized menus like "Applications." The installer should look through all menus for links to the application (not links with a specific name in a particular location) and clean those up. This is easy to do, but I've never seen an un-installer that does it. This also applies to the Desktop and Quick Launch and should be applied across each user, all users, default user, etc.
A while back, my team had to integrate some components we developed into a larger project that was installed with a whole bunch of MSIs (InstallShield packages) that were governed by an overarching setup. The thing did such a lousy job of un-installation and reinstallation (not to mention installation) that the other team suggested we simply save Ghost (http://www.google.com/search?q=norton+ghost) images of our hard drives before installing. Then "un-install" would be done by reverting back to the original images. Somewhat draconian, to say the least, and a clear vote of no confidence in the installer/un-installer "technology."
Another amusing note on the dangers of the automatic "smart" un-installation that InstallShield does: Microsoft sought to solve the "DLL hell" problem with assembly versioning and side-by-side execution of different versions of the same DLL (AKA "assembly"). However, an InstallShield package can easily shoot the .NET versioning and side-by-side execution scheme in the foot: when installing a new version of your product, you can often end up removing the old version of an assembly and installing the new version (whether you intended to, or were even aware of it or not). Of course, any remaining apps or components that were bound to the old version simply barf on startup (this is a problem we had and it took quite a lot of effort to track down the cause). Reference counting is theoretically supposed to solve this problem, but in the real world, it doesn't (while it would be nice if everyone adhered to the reference-counting convention, it often doesn't happen for one reason or another).
Make was written in the days when the more obscure something was the better it was deemed to be... Ant on the other hand is designed to be clear and easy to maintain and use.
Wow... What a slap in the face to Stuart Feldman and the other trail-blazers with whom he worked (various hangers-on with names like Ritchie, Kernighan, etc.).
To suggest that the obscurities of software originating in the late 1970's (like Make's infamous tab requirement) are due to some perverse desire to make things obscure for the sake of obscurity, rather than due to memory and CPU tradeoffs on the systems of that era, is incredibly disrespectful to a lot of pioneers.
What a relief to know that we're sooo much smarter now that we don't simply overlook designing things clearly, like our clueless predecessors did...
big of a plug but antinstaller.sf.net puts a UI on ant and makes the selection of input much more structured. The installer debate runs on and no suggestion that this is a replacement for NSIS and the like but open up java GUI installs to multiplatform environments. if you are installing win32 binaries it may not make sense but if you are interested in cross platform deployments or deployments to servers with no X env it is a serious consideration.
> big of a plug but antinstaller.sf.net puts a UI on ant and > makes the selection of input much more structured.
I've been playing with antinstaller and have posted a few bug reports on sourceforge. I've even fixed a couple of bugs... but I don't want to do too much until I've been in touch with the developer.
So: Paul Hinds aka teknopaul, if you're reading this, please check your sourceforge mail!
Being a newbie at installers and having to work with installshield developer 7 I tend to wish for any other way to do the work... Installshield seems to be a giant program, pretty hard to learn and I actually need just a small part of all the features. I'm kind of glad to hear I'm not alone with this discovery, especially because I just started to build setups ;-)
Previous Topic
