The Artima Developer Community
Sponsored Link

Rules are not a Substitute for Thinking
InstallShield – why?
by Mark Williamson
October 13, 2003
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 didn’t say “Your title here” and I only found the information on a section on someone’s 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 don’t 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.

Talk Back!

Have an opinion? Readers have already posted 9 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Mark Williamson adds a new entry to his weblog, subscribe to his RSS feed.

About the Blogger

Mark Williamson has been a software developer since the late 80's. He is currently working as Development Manager for Vamosa managing the team building their product Vamosa Content Migrator which is a powerful application for migrating unstructured content into CMS's. He has worked on a wide variety of projects over the years including AI based education tools for the Electric Brain Company and real time telemetery for the Williams Formula 1 team.

This weblog entry is Copyright © 2003 Mark Williamson. All rights reserved.

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us