Installation Architecture

[adboll]

I am a fairly new user to InstallShield products. I have built several basic MSI and MSP projects and am slowly learning this software. I currently have an application that needs 3 different installation options in regards to architecture, not necessarily features. For instance, I would like a dialog that allows the end user to select if they wish to install "Server", "Client", or "Training" for the same application. Each of these three platforms, if you will, contain products that are identical (no config differences), similar (same files but config is different), and unique (whole item exists in one platform but not the others). The problem I am having is what is the best project type to use to tackle this project??? Ideas I am tossing around are: Advanced UI/Suite (calling different MSI packages in features) with a custom dialog, Basic MSI (with several features and/or chained MSI packages) with a custom dialog, InstallScript (really don't know this that well). Or was InstallShield designed to keep this high level architecture separate all together (a disk for each platform)?

[MichaelU]

You've enumerated your options fairly well. The primary questions I would use to answer this are as follows:

• How much is shared between the three different options?
  
• Are the release cycle of all three tied together?
  
• Is there a lot of complexity in any part or in aggregate?
  

If there is a lot of complexity, or if the release cycles may be separate, I would err towards separating it into smaller basic MSI projects. If it's more than one package per selection ("server" and "client" might both rely on a "dependencies" package), I would make a Suite project to install these MSI packages. If it's not particularly complex, and the release cycle is shared, I would err towards making this features and components in a single basic MSI project, and optionally deliver it with a Suite project.

In either case you can create a wizard experience that allows a user to select only a single option (powered under the hood with features), or one that allows selecting any combination by using the normal feature selection UI.

[adboll]

MichaelU wrote:
You've enumerated your options fairly well. The primary questions I would use to answer this are as follows:

• How much is shared between the three different options?
  
• Are the release cycle of all three tied together?
  
• Is there a lot of complexity in any part or in aggregate?
  

If there is a lot of complexity, or if the release cycles may be separate, I would err towards separating it into smaller basic MSI projects. If it's more than one package per selection ("server" and "client" might both rely on a "dependencies" package), I would make a Suite project to install these MSI packages. If it's not particularly complex, and the release cycle is shared, I would err towards making this features and components in a single basic MSI project, and optionally deliver it with a Suite project.

In either case you can create a wizard experience that allows a user to select only a single option (powered under the hood with features), or one that allows selecting any combination by using the normal feature selection UI.

What is the best way to do this "mutually exclusive"?

MichaelU wrote:
In either case you can create a wizard experience that allows a user to select only a single option (powered under the hood with features),