4 replies to this topic

[vips]

Dear all,

I have the following situation:

We develope a Windows application which consists of a constant part and a number of additional features - its a pretty classic The problem is - each feature must be bought separately by the customer. So the following problems arise:

1. I need to put these features into the separate distribute files (cab or msi) so anyone can easily prepare the distribution package for the end user in any combination of features. These files being placed together in the same directory must allow user to install the app with selected (of available) features.

2. If the customer buys the new feature, he or she must be able to install this new feature.

How can I do this with MSI ?

Currently I'm using InstallShield Express Limited Ed.

Thank you,
Valery

Edited by vips, 17 November 2003 - 06:43.

[Glytzhkof]

It sounds like what you need is to use release flags. Release flags can be assigned to features (not components) and allow you to "conditionally include them" at compile time. In other words using the same Installshield project you can compile a number of different setups for your application.

Sample:
1: Create 5 features
2: For each feature write a different value into the "Release Flags" property (it doesn't really matter what you write, but it should be something you can remember easily)
3: Go to the release view and create a new release configuration
4: Click the release configuration and set the "Product Configuration flag" to match the value you entered for feature number 1
5: Create a release and try to install it
6: When running the setup you will see that only feature number 1 is included in the release.

[vips]

Thank you, Glytzhkof, it helps me a little.

The only solution that comes into my mind in this case is to produce the main installation and a number of upgrades - one for each future.

[Glytzhkof]

If your product code will remain the same for the upgrade setups you want to create, then the "upgrade setups" you create will go into maintenance mode... In other words you will probably have to deliver these "features" as "separate products" from your main installation (using a different product code). Using transforms could also work, but I have never tried this, and I suspect that could make patching difficult.

Note: you could package each feature into a merge module. If you do this you will be able to included / excluded the module from different setup while still maintaining the same component GUID's. If you don't do this you will have to use the same setup script to generate all setups to ensure the component GUID's remain the same.

In most cases the feature flexibility you describe is not necessary. Rather an application tends to be broken down into a few editions (pro, standard, enterprise, etc...) each edition with a different mix of features. Then one setup is created per edition and each edition will receive a different product code. This would be a simpler solution than to deliver a number of "feature setups" as you describe.

It is late here, hope this made sense .

[vips]

May be you're right about different ProdCode...

I cannot made pro, standart and enterprise eds, because all features has one level of functionality:

SDK + number of supported DSP processors. Each feature - one DSP.