Multiple product support in a single project ?

[pd0123]

We have a software package that is re-branded for various customers.
Even though the (most)binaries are common across all products, each cusomter has specific installation needs that slightly vary - For example customer1 might want the EULA dialog displayed (while cust2 might not).

I am debating whether to a) Have seperate projects for each of the customers b) Have a single installshield project and use the support for multiple products in Releases->Product Configuration ( I might have to use some automation to modify the project as I don't see the Product Configuration tab supporting all the variations I need)

Some of things that are common across all Products:
Device driver installation, upgrade mode(major), the sequence of actions(mostly), required priv to launch setup etc

Some of the differences:
EULA(some might need it, some might not), INSTALLDIR (and the ability to chose a folder - some can and some cannot), The (custom)text and bitmaps in some of the dialog boxes will vary based on the product and Install conditions.
I leaving out the obvious ones such as Product Name,Code,Version etc that can be controlled by the Releases->Product Configuration tab.

As I see a lot of experience in the forums here it would be great to get your opinion on which approach to choose.

Thanks in advance...
Note: We have about 7 customer specific product variant - expected to grow to about 10 -12.

[pd0123]

Anybody has any idea.. ?

[KRZero]

Hi pd0123,

Did you ever find a solution for the dialog bitmap issue for the different OEMs?

Thanks

Kai

[maadal]

Maybee you can use command line arguments to define the different settings, and set conditions according to these arguments.
You may also select to install different features according to the arguments.
To avoid having the user to specify these arguments, you may create a selfextracting zip-file with needed arguments for each customer.

Or you may create an overall installation with one feature for each customer setup, where the customer selects feature, and you start the main installation with parameters according to the feature the customer has selected.
I have created several installations for our programs, and an overall installation that is used to start these other installations. The user selects which programs he want to install, and each product installation is started using
nResult = DoInstall (svExePath, svCmdLine, LAAW_OPTION_WAIT);
where svExePath is the path to the product installation (in a sub-directory of tha overall installation) and svCmdLine contains the command line arguments.

[DLee65]

I have used Basic MSI releases in this manner. The key is to organize your data and use release flags for what should be included and excluded from the setup. The items that are common have no release flags, the features that are not common have different release flags. I then create different release configurations based on the requirements using the release flags to filter which features will be included.

I can then use the automation interface to build each configuration by name.

[pd0123]

The approach I have taken is very close to DLee65 's suggestion. It has been working very well. Thanks for your help.