Windows Installer InstallAware for Windows Installer Header Image Windows Installer without Rocket Science

  InstallAware Blog

   

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.

4 Responses to “So who needs the automation interface?”

  1. Dan Says:

    Sorry to burst your bubble but we created over 4500 MSI packages in the last project and with the macro automation interface in Wise Package Studio the project saved millions in cash and many man-years. Not only could we do close to 100 checks on the company MSI packaging guidelines, best-practices and known bugs but also on previously made mistakes. That way we reduced the helpdesk calls and general issues that previously would have required troubleshooting. Learn from your mistakes – DONE.

    And that was just the QA script.

    Then there was another script that fixed all those things that can be automaticly fixed and also implemented the FULL company MSI guidelines. After the snapshot (capture) a typical MSI package would take less than 30 seconds to create and adapt to the company guidelines (over 30 pages long).

    After that the script would copy the packagefolder to the SCCM share from where it would be automatically implemented in SCCM. At the same time the workflow tool and CMDB have been updated which all amounted to hours of manual work previously.

    Just because you get along with a hammer doesn’t mean that there aren’t environments and customers out there that need a nail gun!

    Best regards
    Dan

    I’m sorry to say but after Wise Package Studio has been discontinued and it’s 64 bit capturing is undeniably lacking there just is no worthy alternative.

  2. Sinan Says:

    I don’t know if you are aware, but InstallAware also comes with an automation interface, now available in both ANSI and Unicode editions thanks to the new InstallAware 16.

    InstallAware 16 also has not only 64 bit setup capture, but also the industry’s fastest setup capture, period. You will find that for these and many other reasons, we are your ideal upgrade from Wise:

    http://www.installaware.com/landing/wise-comparison.htm – InstallAware landing page for Wise upgraders.

    http://www.installaware.com/wise-comparison.htm – InstallAware vs. Wise comparison chart.

    http://www.installaware.com/installaware_installworld.pdf – InstallAware third party review comparing with Wise.

    http://blog.dragonsoft.us/2008/01/18/wise-versus-installaware – another third party review comparing Wise with InstallAware.

    InstallAware can even import WiseScript files, faithful to their original logic, or producing ready to build setups.

    Please have fun!

  3. Crina Says:

    Hi Peter!
    Can you tell me how did you succeed to create\modify Dialogs through automation interface ?
    I can find there connections, custom actions, properties exposed but I cannot find dialogs…

    Crina

  4. mp3juice Says:

    What’s up mates, its impressive paragraph on the topic
    of cultureand fully explained, keep it up all the time.

Leave a Reply