gert.allard1.5524924012585828E12 asked a question.
How to handle extra features
I've read a lot of posts on the installshield fora about nested MSI's (i've read the disadvantages) and i also know how to use patches.
I want to know what the best practise would be to implement the following:
We've got a main program with different features and a lot of extra components (i'll call them plugins).
- We have to make the extra plugins available for selection at the feature tree (or a selection view like that) so that the user can select them at first install.
- The user must be able to unselect them on maintenance.
- A lot of updates are build for those plugins and the main program so that has to work.
- We want to keep the main setup and the plugins as separate EXE and MSI's (plugins will be created later on demand of the customer)
Problems that i encounter are, with nested msi's, i can select them when linked to a feature, but they're only uninstallable when the main is uninstalled. When using nested msi's, problem could be that patching and updating goes wrong (not tested, i found that on MSDN website)and no cost calculating is done on install.
When using patches, i can add components to features but on first install the features would be empty or would not exist. The updating of those files works great off course and the feature is unslectable on maintenance
I wonder if it's possible to merge both, using a custom action to install a patch that is linked to a feature. So when selecting a feature, the patch is launched, and when it's installed, the feature that was added or changed is unselectable in the maintance view?
Is there another method to implement these kind of extra plugins. Ideas would be great.
It could save us a lot of time, if we knew if it works and what the disadvantages are.