This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Found a solution??
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 30, 2010
02:52 PM
Multiple product support in a single project ?
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.
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.
(5) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎May 04, 2010
06:01 PM
Anybody has any idea.. ?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Sep 29, 2010
09:17 AM
Hi pd0123,
Did you ever find a solution for the dialog bitmap issue for the different OEMs?
Thanks
Kai
Did you ever find a solution for the dialog bitmap issue for the different OEMs?
Thanks
Kai
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 15, 2010
06:35 AM
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.
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 19, 2010
12:12 PM
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.
I can then use the automation interface to build each configuration by name.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 23, 2010
01:21 PM
The approach I have taken is very close to DLee65 's suggestion. It has been working very well. Thanks for your help.
![](/skins/images/8C9D13A71C7F7695F3262372C0172D68/responsive_peak/images/icon_anonymous_message.png)