Some guidance in building our first multiple app installer...

[kweatherhead]

Greetings,

Quick backgound... I have built several single module installers with SF7 and until recently haven't been bit. The installers have all consisted of a database runtime, our application, documentation along with a few additional support files thrown in for good measure.

We recently got burned on an install where we somehow didn't get the runtime fully updated, or maybe an old piece didn't get removed in the process, whatever the issue was as when we uninstalled the previous runtime and then reinstalled the current version, the problem went away and we have not been able to re-duplicate the issue (yeah for intermittent issues), something that is not suppose to have to be done according to the vendor.

I have now started looking into the "Dependency Module" as maybe the proper method to attempt to handle this and we are waiting on the vendor to give us the proper files for making the version specific determination.

What I am trying to determine, along with the Dependency comment above is whether what I want to do (outlined below) would better be multiple (and possibly emebdded) installers or by packages...

The RunTime (RT) support is about 35MB
The specific module code is about 1-2MB/each
The Common files/tables are another 1-2MB/in total

What we want to be able to do is this...

1. Determine version of RunTime and update if the installer contains newer (Dependency Module seems to allow us to accomplish this properly...)

Note: if RunTime is updated the uninstaller has to updated, but only one version of the RT and RT_Uninstaller should be on the system unless the version major has changed in which case the new RT major would be installed in a folder parallel to the highest patched version of the previous major (i.e. version 6 -vs- version 7)

2. Prevent the RT from being removed unless ALL application modules have been removed and the Common Files component has been removed.

3. Be able to control the Add/Update/Remove of any/all of the modules.

4. Be able to control the Add/Update/Remove of the Common Files, but again only allow these to be removed after all of the App Mods, but before the RT.

Additional Requirements...
There are currently two modules completed, the third is well underway and there are about 8-10 modules in the total plan.

Is this a Packages -or- a multiple installers type of installation?

I would appreciate any guidance and recommendations as this is now getting to be a much more complicated environment than we first started out with. I believe we selected the right tool for the job, we simply need a little direction from some more experienced builders as to how to best utilize our investment.

Thanx,
Keith

[Adam]

It would probably be better to create separate installs for each release. The problem with a package installer is that it is difficult to remove single packages. You can have multiple installers install into a 'master' directory to give the feel of a single app even though the pieces are installed separately.

Adam Kapilik

[kweatherhead]

It would probably be better to create separate installs for each release. The problem with a package installer is that it is difficult to remove single packages. You can have multiple installers install into a 'master' directory to give the feel of a single app even though the pieces are installed separately.

Adam Kapilik

I originally asked about this in March 2006 and there have been a few pataches to 7.0 since. My question is does this recommendation still hold true today or have the issues been addressed to make multiple module installers (via packages) install/removed better than they did 18 months ago?

Regards,
Keith

[Adam]

There have not been any changes with regard to packages.

Packages are not really meant to hold separate pieces of software. They were designed to hold different features/files that could be installed for the same product.

I would suggest using separate installs and running them from a master install.

Adam Kapilik

[jlsf2]

Just a comment.

I was faced with a similar problem of trying to install multiple programs inside of a single installer.

The packages idea seemed great and *almost* worked, but it didn't - too many shortcomings.

My solution was to create an installer for each app and then call these installers in silent mode from a wrapper installer.

I just used a scrolling text page to show the status of each of the individual installs.

The nice thing was that I could add new app installers at any time and they would get installed by the wrapper installer without any code changes to the wrapper installer code.

[kweatherhead]

Just a comment.

I was faced with a similar problem of trying to install multiple programs inside of a single installer.

The packages idea seemed great and *almost* worked, but it didn't - too many shortcomings.

My solution was to create an installer for each app and then call these installers in silent mode from a wrapper installer.

I just used a scrolling text page to show the status of each of the individual installs.

The nice thing was that I could add new app installers at any time and they would get installed by the wrapper installer without any code changes to the wrapper installer code.

Yep, the more I look at it, the more resigned I am to doing it this exact way and for all of the same exact reasons, too. I had hoped that Packages would be the answer as I had it almost all built but could not get a few things to function as I desired with rock solid results.

Thanx for the confirmation.

Regards,
Keith