I have done my share of packages, ranging from the complex to the simple. One thing is certain, sophisticated software packages using leading-edge technology is requiring a tremendous amount of application prerequisites to be installed.
For example, for an 1 MB Excel “Plug-in” that I created the install package, the following software packages were required to be installed before the application package (ignore the obvious Microsoft Office with Excel):
- Microsoft .NET 2.0
- Microsoft Visual Studio 2005 Tools for Office
- Microsoft Office 2003 Primary Interop Assemblies – for when Office 2003 is installed
- Microsoft Office 2007 Primary Interop Assemblies – for when Office 2007 is installed
All of these prerequisites packages must be installed before the application can be installed – in fact if they are not installed you will encounter errors during the configuration.
Just getting them deployed within the application install package has been frustrating because:
– Technique – correctly getting the technique in installing them is very tricky to do when you have to have MS Office 2003 PIA look for its registry key (don’t attempt to run it if its already been install) and then look for the presence of Office 2003 registry key (it will error off if its prerequisite has not been installed)
– Package size – start with a 1 MB Excel ‘plug-in’, and then add up the disk space consumed in incorporating these application prerequisites within your deliverable. Over 50MB in this install package – for a 1MB Plug-in! Web staging of these prerequisite packages becomes a mandatory requirement.
In the past I would silently install some software packages (.NET 1.1 and Adobe) in the short period before the dialogs appeared (traditionally the Windows Installer engine is locked into your MSI and won’t let any other MSI packages execute). Yes it violates the golden rule about not altering your client’s desktop until they gave permission by pressing INSTALL on the “Ready for Install” dialog – but many times you don’t have much choice.
This growing requirement for application prerequisites force us to utilize the InstallShield “Setup Prerequisites” capability – which is steadily increased in usability until it now looks like its works in IS 2009! Granted you can’t run silently/unattended since it will always pop up the Setup Prerequisites panel!
Lately I have been installing some high-end application packages and am finding a new trend – that of having a sophisticated “bootstrap” application to manage the installation, that is a C# type application that runs with panels to guide you through the installation process. Consider the SQL Server 2005-8 or Visual Studio 2008 application dialog panel that steps you thru the various installation and configuration steps. Look at Verint Systems with their Master Installer package – which handles prerequisites by neatly isolating them from the application installation package. The MSI’s are launched separately which allows for the MSI Packages to be focused on just delivering the application files – not being concerned with prerequisites!
These are vastly different approaches than that embodied within the “Chained MSI’s” approach that Windows Installer v4.5 is touting as the newest strategy – which is demonstrated within the .NET Framework 3.5 SP1. This package actually is comprised of various MSI’s under the covers for the different .NET Framework versions (2.0, 2.0 SP1, 3.0, 3.5, 3.5 SP1) that are daisy chained together similar to early patches were cobbled together.
Personally I think very highly of Microsoft’s “Chained MSI’s” technique – but let’s be realistic – how many technology firms can dedicate resources to accomplish this and test it!
The longer I stay in this business, the simpler I want to make my application packages. Because when I develop them, I may not be maintaining them – the customer may have a individual with limited skill set trying to accomplish a simple maintenance task. My stint with EDS (back when 3 piece suits and lace-up florsheim’s were the norm!) taught me that for each dollar in development, an organization spends $100 in maintenance costs – so keep it simple!
From my viewpoint – the technology to create the installation package is surpassing the expertise found in most development shops. I think the approach that allows a InstallShield developer to create the most dependable “Bullet-proof” installation needs to be seriously considered!
The heretic has emerged!