Installations often have prerequisites, such as “Microsoft .Net framework is required for this product”. The usual implementation in MSI installations is system search for a particular registry setting representing the required prerequisite, followed by a launch condition based on the result of the system search (passed in a property).
This works well for the whole product; but if the product has several features, it may be that different features have different requirements, so it would be an overkill to request, for example, .Net Framework for the whole product when in fact only one its feature needs it - especially if that feature is optional and is installed only for the users who specifically request it. How to implement this?
I came up with the following solution. We still use system search to detect if prerequisite is met; but now we don’t use launch condition. Instead, we use the events generated by Selection Tree control in the Select Feature dialog.
The events documented by Selection Tree control are documented in the Microsoft article¹ about it. For our purpose, we need two: MsiSelectionTreeSelectedFeature
, returning accordingly the current feature selected by the user in the control, and target installation state of it specified by the user.
Assuming that the feature that needs the prerequisite is named OptionalFeature
, we specify two following events as Published by Selection Tree control:
Condition: MsiSelectionTreeSelectedFeature="OptionalFeature" and MsiSelectionTreeSelectedAction<>2
In the above, 2 ( = INSTALLSTATE_ABSENT) is the value corresponding to the action “absent”. This event will set property OptionalFeatureRequested
to 1 when it’s the current feature in the tree selected by the user, and the user has specified to install it, either by demand, or from source, or locally.
We also create another event:
Condition: MsiSelectionTreeSelectedFeature="OptionalFeature" and MsiSelectionTreeSelectedAction=2
With these events, the control will dynamically update the property OptionalFeatureRequested
to either 0 or 1 as soon as the user changes the target installation state of OptionalFeature. Having that, we specify Conditions for the button “Next”, that will enable or disable it basing on the value of the OptionalFeatureRequested plus having or not the prerequisite in place; we also create text control with the error message informing the user about the reason why Next button is disabled, with the following two conditions:
Action: Show control
condition: Not PrerequisiteFound AND OptionalFeatureRequested=1
Action: Hide control
condition: PrerequisiteFound or OptionalFeatureRequested=0
is the property returned by the system search for the prerequisite wanted by the feature.
For the more complete solution, the condition would have to be also specified in the Execute sequence, to handle non-UI installation; however since non-UI installation is usually associated with deployment by competent administrator, he probably will have ensured that the target system meets the requirements without the aid from the package itself.
This solution came handy in the deployment of the package including, among other things, one managed dll. The dll was put in its own feature (optional, and not installed by default, since only a few users in one department need it), and the above technique was used to ensure that .Net Framework 2 is installed whenever the user has selected the feature for installation. Without that, we would either be requesting .Net Framework for all systems where the whole package is installed, or would have to create separate installation just for this single dll.
1. SelectionTree Control, MSDN, http://msdn.microsoft.com/en-us/library/aa371604%28v=vs.85%29.aspx