So who needs the automation interface?

Hello everyone, this is my first official blog item, anywhere, and thanks to Candice Jones at IA for given me the official invitation. When I say it’s my first ever blog item, I mean it. As much as I know how to use the internet I know very little about how to do the internet so this blog malarkey is new ground. New ground? That sort of leads me on to what I want to write about. I come from an InstallShield background and about three weeks ago I discovered IA and it’s been a chaotic time ever since. Not chaotic in the sense of how do I do something but more like, how do I undo what I was used to doing? Don’t get me wrong, I am not here to knock InstallShield. But since I’ve been using IA I’ve come to appreciate how much nicer it is to achieve similar functionality, but much, much easier.

What I’m really referring to here is the automation interface. InstallShield offers a rich subset of COM classes. Yes, COM! I had raised a ticket requesting a fully .Net-managed version be made available. We use the automation interface to create new projects from a template project and use an XML file to describe the features, components, and filenames to be installed. The first reason I designed it like that is because in theory, anyone could add or remove files from a build by editing safe-ground XML data. The second reason, and the most pressing to solve, is that the alternative is that I would have to teach people how to copy a template project and then add new files and do this and do that and what have you. That’s the crux of the problem, being forced to employ the automation interface to solve a problem that could not easily be solved without it. Now, in my period of time evaluating IA I never got round to demonstrating the automation interface in the Admin Studio edition. So how could I really sit here and write giving the impression I was comparing eggs to eggs?

This is the best bit: I did not have to. The ease of use afforded by IA meant I could take a project template containing most of my InstallShield template. Instead of using my automation interface program, I was able to prove that given access to the IDE machine, we could copy a project for a new installation, load it in the IDE and within a very short time change the project to use the new files or other facilities we wanted to include in it. One of the most complex issues I had to solve in InstallShield was needing to fix the occasional buggy record in the MSI tables and getting mega-confused deciding does something go in this sequence at such a position or elsewhere in another. True, that was not often required but how do you pass that kind of shoot-from-the-hip knowledge to someone else who, arguably, just wants a new installation with the minimum of fuss?

That’s what IA has achieved. Minimum fuss. Maximum do. I’m sure there is a place for the IA automation interface. I’ve trawled through the user forums looking for posts and I’ve seen precious few, if any reasons to use it. This proves my case – my opinion alone – and that is the automation interface is not called upon widely because there is not really a need to do so. IA has solved many installation problems by burying the complexity under-the-hood. So is the automation interface really required then? Well, you can bypass it by using compiler variables and use those in the MSIcode. This is an area where IA scores very highly. With one script you do everything that an install or uninstall requires and using compiler variables lets you wrap your runtime specific requirements in one easy to get at location. The compiler variables let you steer your project build along different roads. Compiler variables do not banish the automation interface and the interface does not banish the variables. Think of them as different toys brought to the party and that’s the power of IA. It joined the best of many breeds and took the concept of building installations right back to first principles and built a new castle on the hill.

My wife likes jewellery shops and what they sell, mostly gold for some reason (sigh!). She has no interest in digging through tonnes of ore looking for it. I look upon IA for the same reason. The ease of use means I and others can pick something off the shelf. Does that mean we can throw the shovels away? No, but we can put them back in the shed and work on doing things differently. If I’ve had to unlearn topics I was used to it’s because there is another paradigm. What IA does it does very well. Now that I can put the automation interface problem away for now and using compiler variables means I can now focus on doing what I do well, and that is…buying my wife more jewellery.

Kind regards. Peter Hamilton-Scott.