View Full Version : Suite and Operation

Johannes John
10-28-2011, 04:21 AM
Hello Michael,

I would like to have an overview of which operation is started or is intended to be started.

My understanding:

First installation and ??? upgrade
MODE: first installation or MODIFY
Feature button: SET
Detection: FALSE
Eligibility: TRUE

Feature button: ??? / NOT SET
Detection: ??? / TRUE
Eligibility: ??? / ???

Repair mode
Feature button: ?
Detection: TRUE
Eligibility: TRUE

Changes in product
Feature button: SET
Detection: TRUE
Eligibility: TRUE

Is that correct or expected by the suite in this way?


10-28-2011, 05:15 PM
Not quite; these operations reflect the changes necessary at a per-package level. For example, you may be running some sort of maintenance on a suite and turn on one feature and turn off another. This would likely result in at least one package running its install operation, and another running its remove operation.

The package modify operation currently only runs in a project where you dove into the XML file and associated package features to suite features. Otherwise the only suite change that affects the package would be a full install or removal.

So in summary:
All operations only run when a package is eligible and it has a definition for the relevant operation.

Install runs when a package is not detected, and feature selection indicates it should be present. Typically this is a first time install, an upgrade, or a modify in which a user selects an additional feature.

Remove runs when a package is detected and feature selection indicates it should no longer be present. Typically this is due to a request to remove a product or a feature.

Repair runs only as part of suite repair for packages that are detected.

Modify runs only for detected packages (typically MSIs) that need to change which of their features are installed; again this only can happen if you've added such definitions to the project xml directly, as it is not in the IDE yet.

Johannes John
10-31-2011, 09:36 AM
Thanks Michael,

1) Is it correct, that a Remove operation needs an eligible package?

2) Is it correct, that both first time install AND upgrade run the same command in the Install operation?

3) How do I modify a package, that isn't detected? ( -> Install runs ...)


10-31-2011, 05:14 PM
1) Yes; operations only run on packages which are eligible.
2) Yes (well mostly); the Install operation is what runs when a package needs to be installed and is not currently detected. However there is some special support for minor upgrades of MSI packages which tweaks things like REINSTALL.
3) You can't modify a package that is not present, so I don't think this is supported. Could you expand a bit on what you're trying to accomplish where you need this case to run the modify operation?

Johannes John
11-03-2011, 07:27 AM
Hello Michael,

To 1)
I don't understand the needance of an eligibity at Remove.
E.g. In the eligibility condition is set, that this product needs .NET.
The setup itself doesn't need .NET.
The remove doesn't needs .NET either.
Somebody has uninstalled .NET.
Therefore I need to install .NET, that I can uninstall this product.

To 2)
I have a problem with the point, that the first installation and an upgrade have to run with the same parameters.
I let my major upgrades run thru, without asking for pathes and features.

To 3)
You wrote:
Install runs when a package is not detected, ... . Typically this is ..., or a modify in which a user selects an additional feature.

How do I modify a package, that isn't detected?
( and the old problem, how do I select features in silent mode )

The 3 cases
- first installation
- upgrade
- and maintenance
aren't seperated as I would like have it.


11-03-2011, 02:26 PM
Johannes, this is good feedback.

I totally see your point about 1. You could work around it similar to the MSI "Or Installed" approach by logically "Or"-ing your eligibility condition (using an Any group) with a variant of the detection condition. Then it would be eligible whenever it was previously considered eligible, or when it's already present.

I'm not sure the best approach for case 2. While in theory you could detect the previous package and use that information to control whether you present questions to the user or just probe the existing settings, it's not trivial at all. I'll have to think about how I would best do this.

For case 3 I still don't really understand the question. If it's not detected, it should be because it's not there, and if it's not there there's nothing to modify. You can totally install a package as part of the modification of a suite, but I don't think that's what you're asking to do. If it is, it runs the package's Install operation in that scenario.

For 4, the item about selecting features from the suite's command line while running silently, specify a comma-delimited list for the ISFeatureInstall (and possibly ISFeatureRemove) suite properties.

11-03-2011, 03:35 PM
You mentioned ISFeatureInstall and ISFeatureRemove suite properties. My Suite Property Manager does not show these. Are they generated at runtime based on selections? It sounds like one could control behavior by setting these?

11-04-2011, 12:52 PM
ISFeatureInstall and ISFeatureRemove are intended for use only from the command line, where they are used to select the features for a silent installation. I don't believe they are updated by changes to the selection in the UI.

Johannes John
11-07-2011, 04:18 AM
Hello Michael,

back to when operation Install runs.
E.g. in case of upgrade because a second primary package.
The Detection Condition for this package is false, because this target version is higher as the installed version.
The Eligibility Condition may be true.

The feature selection shows not selected.
If the user wants this product upgraded, he has to select it again.
He has to know, which products he wanted to be installed.
At each upgrade, again the decision, which product to install?

Is this the intension of the suite?


11-07-2011, 03:51 PM
I think I'm starting to wrap my head around the case you describe. Say you release the suite with main packages A, B, and C each at v1 (and possibly some dependencies, which we'll ignore for now). Then you update A and B to v2, but C is still v1. When you run this Suite on a system with all v1 packages, you want to see A and B upgraded to v2. But you're concerned that you either make this look like maintenance (where the features for A and B may be represented as not selected), or you make this look like a first-time install, where the feature for C may not be obviously still present. In either case, getting from full install to full install is tricky enough; in a larger case where only some of the packages were installed, keeping that subset is much more complicated.

I suspect feature conditions might help with one of the alternatives, but let me make sure we're talking about the case that you're concerned about before I figure out how best to "solve" it. :)

Johannes John
11-08-2011, 08:11 AM
Hello Michael,

that's a good example.

In contrast to the MSI setup, here in the suite setup at update all features which are allready installed are NOT selected.
In contrast to the MSI setup, here we have different stati of the features.

It should be possible to decide independently of the status of a feature, if it will be updated or left as it is or uninstalled ( at the moment I don't know how to select this ).

My idea is to have an additional sign, if the feature is installed in an older version. How ever to detect this.
And by default, features which are allready installed are selected to be installed.

At the example: A and B are selected, because of the possible update.
And C is not selected, because it is allready installed in this version.
If the user does not want to update B, he unselects B.

It remains the question how to uninstall a feature. Perhaps a second selection button.


11-08-2011, 05:50 PM
Right; at this point we show two states: is or will be installed = checked; is not installed or will be removed = unchecked. I believe MSI represents a few more states, but still doesn't differentiate well between previous and future states. In Suites, this means package C of the previous example will remain checked because it was present (and is not being removed). It sounds like your ideal case is that packages A and B would display checked to indicate that their previous version was installed (and that the upgrade is being installed).

I'm going to be away for a couple weeks, but I'll think about this scenario and maybe someone else will chime in in the mean-time.