Now I’m working on something interesting. It’s working title is the ‘General Installer’ script.
The script is basically a universal wrapper to install applications or anything else, but also give you the flexibility of pre-process scripting without the scripting, as well as logging and recording the exit of each install process.
Let me take an example: PDF Converter Pro version 5. This installation is msi based from the vendor, and to install you need to:
- Install .NET Framework 3.5 if required
- Install MS Virtual C Runtime if required
- Install PDF Converter Pro itself
… but ideally you need to do this:
- Check if PDF Converter Pro 5 or newer is already installed
- If above is true, log it and send log to central location. If not …
- Install .NET Framework 3.5
- Record exit code of above
- If .NET install failed, log it and send log to central location. If not …
- Install MS Virtual C Runtime
- Record exit code of above
- If above install fail, log it and alert somehow. If not …
- Install PDF Converter Pro 5
- Check exit code: was a restart required?
- Log result and send log to central repository.
Here’s another (fictional-but-based-on-fact) one: a Firefox plug-in that will only work if Firefox 3.1 or newer is installed, but will not work if Firefox 3.6 or newer is installed. In this case we need:
- Check if this plug-in is already installed – log etc.
- Check if Firefox is installed
- Perform a programmatic version check if Firefox is installed that is newer than 18.104.22.168 but older than 22.214.171.124 (not as easy as you think)
- Install plug-in
- Log result etc.
All of this checking and logging can be added on into an mst transform – but that means you have to launch the installer, and wait for it to go through the checks, and then get it to abort if needs be. Have you ever tried to get an msi installation to abort nicely and report back a friendly (custom?) exit code? It is not possible to get it to return that sort of information to a wrapper or, for example, an Altiris DS server. You can get nice custom messages into the event log of the computer, but as for custom meaningful exit codes, forget it. And what if you have a non-msi based application and you don’t want or need to repackage it as an msi?
So I wrote nice wrappers.
Over the last two-and-a-half years I’ve been here, I’ve written a wrapper VBScript for every installation I’ve performed: these install the pre-requisites, do the pre- or post-scripting checks and tasks, logging, alerting, aborting and returning custom exit codes back to Altiris DS or NS. Ok, most of the scripts are merely tweaked versions of previous scripts, which was fine, because I was the only packager, they were my scripts and I could amend one and knock out a new one really quickly.
But now the work has increased and we have another packager. Over the last many months he has got used to my way of doing things with tweaking and amending VBScripts for every installation.
But now there is a short term project and a couple of contractors will be packaging to our standards. Therefore to train these guys to our way of doing this is a waste of their time and our money.
So I need a way to perform these pre- and post-tasks without amending and re-saving an actual script. Ideally no VBScripting skills should be required at all. That’s when I came up with the idea of the General Installer.
The General Installer is a VBScript, but a static one, that can cope with any (?) situation you need it to cope with. And all the criteria, and logging options, and multiple pre-requisite commandlines etc. can be entered into an ini file that is read by the installer.
The ini file is very simple to understand to do simple installer tasks, like: check if already installed, install and log. But is necessarily quite complex if the more complex tasks are required.
For example: An application has .NET Framework as a pre-requisite, but a hotfix to install after the main install. So I need to ensure that each part is successful but ideally I want the main app install exit code to be reported back to Altiris, not the hotfix one – the main install might return 3010 (restart required) but the hotfix then returns 0. I want to see the 3010.
Therefore I made it possible for within the General Installer ini file to choose which install commandline out of many to use as the ‘Master Process Return’ code.
This is still a work in progress and I hope to elucidate further as I go on.