InstallShield Tips and Techniques

March 26, 2009

Windows Installer – are we seeing a new strategic direction?

Filed under: Reference Materials, Techniques — shieldmaster @ 11:06 pm

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! 

 

ShieldMaster

Advertisements

2 Comments »

  1. You’re totally right about the complexity. While those of us working on InstallShield like to fantasize and argue that every setup developer should understand the rules of Windows Installer and the tradeoffs they’re making for each choice, deep down we know that’s never been realistic, and is getting less so. So I agree completely: aiming for simplicity is a great tactic when you can pull it off. Chained installs are great in theory, but they’re still going to increase prerequisite complexity (is MSI 4.5 on your target system yet?) for a while.

    One other side comment; you mention the InstallShield prerequisite dialog prevents unattended installs. AFAIK that’s never been the case when run from setup.exe. So long as you run setup with the /s parameter (and /v”/qn” for feature prerequisites in IS2009), it will install the prerequisites as silently as the prq itself allows. So make sure to specify a silent command line, or the prq itself may show dialogs.

    Comment by Michael Urman (InstallShield) — March 27, 2009 @ 10:45 am

    • Thanks for the useful information! Appreciate it greatly.
      Charles

      Comment by shieldmaster — March 27, 2009 @ 12:17 pm


RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Blog at WordPress.com.

%d bloggers like this: