Feature Selection

[Scott_Duckworth]

Is there a way to have a feature automatically be set to "Not Available" if another Feature is selected to not be installed. These are not Parent/Child Features.

Example:
|--API1
|--API2
|--Test Tools
|--Test API1
|--Test API2

If API2 is selected to not be installed, how can "Test API2" automatically be unselected and displayed with an X has not going to be installed.

Basic MSI project
Custom Setup Dialog

Thanks for any help.

[RobertDickau]

I believe there's nothing built in to handle this kind of feature dependency, besides making "Test API2" a subfeature of "API2".

It wouldn't look the same, but for that behavior you could perhaps add a conditional Remove control event that deselects "Test API2" if "API2" isn't selected.

[Christopher_Pai]

I work on massive installers that derive from a product line of 15,000+ files forming 200+ features from 20+ service families. Frankly Windows Installer's tree format of relating variation points and dependencies doesn't always cut it. A 'feature' ( overloaded term ) at our company often has complex dependencies and cross multiple service families.

Robert is right, you could make the testapi features children of the apis themselves but then you don't see them grouped together. You could include the components for the api feaures in the testapi features so that they go together but then it gives you the impression that the apis aren't being installed when in fact they are. You could also write your testapi components to fail gracefully if the api isn't present. ( runtime message, sorry api not detected ).

You might want to just not show the custom setup dialog and instead have your own custom dialog that gets the input from the user and then translates it into feature states.

Maybe Robert has thought about this deeper then I have and has some suggestions that would help me rethink my understanding of this area.

[Scott_Duckworth]

Thanks for the replies. I'll report back the the development team (Was their idea) and recommend I make the test tool a child of the API. I don't believe the extra work is worth while in this case.

[RobertDickau]

Christopher Painter wrote:
Maybe Robert has thought about this deeper then I have and has some suggestions that would help me rethink my understanding of this area.

No deep thinking at this end. From the what-gets-installed standpoint, having strictly enforced "feature" dependencies makes perfect sense, though no package management system seems immune to dependency woes. From a UI standpoint, though, the danger is making it feel like a game of Lights Out, where turning on one light turns some others on and some others off according to a hidden rule...