MSI Features

What is a Feature?

A feature is a part of the application’s total functionality that a user recognizes and may decide to install independently. For example, a feature could be a spell-checker, a thesaurus, or a set of clip art. Hierarchical relationships of parent and child features commonly exist such that if a child feature is installed, the parent feature is automatically installed as well. Generally, when a user uninstalls feature ‘X’, the Windows Installer automatically uninstalls all features that have feature ‘X’ as a feature parent. However, such child features might not be entirely uninstalled if they include components that are also used by other features. This helps prevent uninstallation from accidentally breaking other applications.

How are Features different from Components?

After you have a basic understanding of Components, Features are quite easy to understand. Features are buckets (container objects) for Components. Features have very few attributes assigned directly to them, they are actually the sum total of the Components contained within them. Although Features are simply buckets for Components, many of the configuration capabilities of Windows Installer operate on Features. For instance, you can advertise a Feature, but not Components. Features have some unique attributes. These include:

• Windows Installer configuration commands operate on Features (installing, advertising, uninstalling, and so on)
• Self-healing, install-on-demand and user profile fix-up operate at the Feature level
• Features can contain other Features
• Features can be arranged in hierarchical relationships (by being contained by other Features)
• Features contain Components
• Multiple Features can contain the same Component
• Features are NOT identified by GUIDs but rather by a FeatureIdentifier, which is a text string

Windows Installer enables features to be set to one of the four states:

• Installed on Local Hard Disk– The files are copied to the hard disk of the local computer.
• Installed to run from source– The application accesses the files from the source, typically a CD or a network share.
• Advertised– The files are left on the source, but can be automatically copied to the client computer the first time the user selects the feature.
• Not Installed– No files are copied

Some common issues related to Features

How to request a Feature?

There are several functions an application must call to request features. Before requesting a feature, the application must ensure that the feature is installed. If the application calls MsiUseFeature before the application accesses a feature, the application can use the information returned to maintain usage metrics. To request a feature

1. Call the MsiEnumFeatures or the MsiQueryFeatureState function if you want to determine the availability of a feature without incrementing the usage count.
2. Indicate your application’s intent to use a feature by calling the MsiUseFeature function.
3. Determine file locations by calling the MsiGetComponentPath function.
4. Configure the feature by calling the MsiConfigureFeature function.
5. Obtain usage metrics that your application can use by calling the MsiGetFeatureUsage function.

The following diagram illustrates the feature request model.

How to Reinstall a Feature or Application?

Windows Installer can repair, replace, and verify files contained in an application. A partial or complete application reinstallation might be required if any files or registry entries associated with any feature are missing or corrupt. When a feature or application is reinstalled, all the services, environment variables, and custom actions belonging to the feature or application are reinstalled as well. This means that any changes made to environment variables between the original installation and the reinstallation are lost. The following list contains methods of reinstalling a feature or product. The first two methods have been automated by the installer:

• Repair, replace, or verify files by calling the MsiReinstallFeature function.
• Reinstall the entire product by calling the MsiReinstallProduct function.
• Reinstall, replace, or verify files with an installer UI control button through the Reinstall ControlEvent.
• Reinstall, replace, or verify files from a command line by setting the REINSTALL property and the REINSTALLMODE property.

To reinstall a product using the installer, call MsiReinstallProduct.

To reinstall a feature using the installer, call MsiReinstallFeature.

How to reinstall a product or feature with an installer user interface?

To reinstall a product or feature with an installer user interface

1. Add a button to the specified dialog box by adding an entry to the Control table.
2. Add a ReinstallMode ControlEvent to the ControlEvent table, with the Dialog_ and Control_ fields referencing the button control created in step 1. In the Argument field, enter a string containing the letters corresponding to the reinstall modes you want (the acceptable values for this field are identical to those accepted for the REINSTALLMODE property). The value in the Ordering column for this event should be 1.
3. Add a Reinstall ControlEvent event to the ControlEvent table, again referencing the same button control. The Argument field for this event will normally be ALL, to force reinstallation of all features, but you can place the name of a specific feature here. The value in the Ordering column for this event should be 2.
4. Add one more event tied to the same button control, to actually initiate the reinstallation. This can be an EndDialog event (with an argument of Return). More typically, however, a NewDialog event would be used here to jump to an Are you sure you want to reinstall? Confirmation dialog box. The value in the Ordering column for this event should be 3.

If desired, several REINSTALL buttons can be created for a single dialog box, allowing the user to select the type of reinstallation performed. In this case, each button is authored as outlined in the preceding procedure, with a different ReinstallMode ControlEvent parameter for each button. Once a particular product has been installed (with some or all of the product’s features), a reinstallation can be performed at the command line.

How to reinstall a product or feature from command line?

To reinstall a product or feature from a command line

1. From the command prompt, specify the REINSTALL property.
2. From the command prompt, specify the REINSTALLMODE property.

Specifying these properties allows the user to reinstall any or all of the product’s features. The type of reinstallation can also be specified. For example, you can specify that only those files that are completely missing should be reinstalled, or that only corrupt files (for example, any executable file whose checksum does not match the actual file contents) be replaced.

How to reference features in Merge Modules?

Merge modules only operate with components and not with features. However, some tables in merge modules, such as the PublishComponent table, contain fields that refer to features. A null GUID: {00000000-0000-0000-0000-000000000000} must be authored into any field of a merge module database that references a feature. When the merge module is merged into an installation package, the merge tool replaces the null GUID with the feature specified in the installation package, except for tables that require special handling, such as the ModuleSignature table and the ModuleSequence tables. Note that if a null GUID is used as a primary key, it is not guaranteed that the value substituted by the merge tool is unique. Authors of merge modules are responsible for ensuring that no existing primary key in the user’s interface is duplicated when the merge tool replaces null GUIDs with features.

Checking the Installation of Features, Components, Files

If after running an installation, you need to verify that a particular feature, component, or file has been installed, turn on the verbose logging option during the installation.  The verbose log includes an entry for each feature and component the installation package may install. The log tells what the state of that feature or component was prior to the installation, what state was requested by the installation, and in what state the installer left the feature or component. Feature and component entries in the log appear as the following examples.

MSI (s) (40:A4): Feature: QuickTest; Installed: Absent;   Request: Local;   Action: Local

MSI (s) (40:A4): Component: QuickTest; Installed: Absent;   Request: Local;   Action: Local

This verbose log indicates that:

• The installation state of the QuickTest feature and component was absent before running the package
• The package requested a local installation of these
• The feature and component were both left in the locally installed state after running the package.

The label “Installed” in the log refers to the current install state of the feature or component, “Request” refers to the requested install state of the feature or component. “Action” refers to the actual action state of the feature or component. The following table lists the possible component or feature states that can appear in the log.

Possible Feature states in the Log File: –

The verbose log has an entry for each file that may be installed by the package. The log tells what was done to the file and provides some explanation. File entries in the log appear as in the following example.

MSI (s) (40:A4): File: C:\Test\TESTDB.EXE; Won’t Overwrite; Existing file is of an equal version

This log indicates that the installer will not overwrite the existing Testdb.exe file because the existing file is the same as the version being installed.

Searching for a Broken Feature or Component

The installer can increase application resiliency by automatically reinstalling damaged components. Specifically, the installer reinstalls a component or feature if it finds that the file or registry key specified in the Key Path column of the Component table is missing. If the Key Path of a feature’s component is damaged in the source, or if there is an error in how the Key Path is authored in the database, the installer may attempt to open an installation package and reinstall the feature each time the feature’s shortcut is activated. To determine the cause of repeated attempts to reinstall a feature or application, check the Event Log for two entries such as the following.

Detection of product 'MyProduct', feature 'MyFeature' failed during request for component 'MyComponent'

Detection of product 'MyProduct', feature 'MyFeature', component 'MyComponent' failed

The first message states which component in the product’s package was being installed. This is the component referenced in the Component_ column of the Shortcut table. The second message states which component is failing detection. This is the component with the missing or damaged Key Path that’s triggering the reinstall.

Publishing Products, Features, and Components

To publish a product, component, or feature, use one of the publishing actions. The PublishProduct action registers the product information with the system. After executing the PublishProduct action, publish the components with the PublishComponents action, which in turn uses the PublishComponent table to determine the components that are set as advertised. To publish on a per-feature basis, invoke the PublishFeatures action. This action uses the FeatureComponents table as data to resolve which features are advertised.

Working with Features and Components

There are several functions that change the installation of product components and features. The following describes how to change the installation of features and components.

To change the installation of features and components

1. Set the installation level for a component or feature by calling the MsiSetInstallLevel function. Each feature in a package is assigned an installation level in the Feature table. If the installation level of a feature is lower than the level set by MsiSetInstallLevel, the feature is selected for installation. After MsiSetInstallLevel is called, you can explicitly change whether a feature is installed.
2. Determine which states are available for a specified feature by calling the MsiGetFeatureValidStates function.
3. Obtain the disk space requirements for a specified feature and its child features by calling the MsiGetFeatureCost function.
4. Obtain the current state of a feature or component by calling the MsiGetFeatureState function or the MsiGetComponentState function.
5. Change the state of the feature or component with the MsiSetFeatureState function or the MsiSetComponentState function.

Controlling Feature Selection States

What is the use of Feature Selection state?

Using Feature Selection State one can control which feature installation options are available for users and applications to select by authoring the Feature table and Component table.

Why & How to control feature selection state?

• To prevent selection of the advertise state for a feature; include msidbFeatureAttributesDisallowAdvertise in the feature’s Attributes field in the Feature table.
• To prevent selection of the run-from-source or run-from-network states for a feature, include msidbComponentAttributesLocalOnly in the Attributes fields in the Component table for every component belonging to the feature. If a feature has no components, the feature always has the run-from-source and run-from-my-computer options available.
• To prevent selection of the run-from-my-computer state for a feature, include msidbComponentAttributesSourceOnly in the Attributes fields in the Component table for every component belonging to the feature. If a feature has no components, the feature always has the run-from-source and run-from-my-computer options available.
• Starting with Windows Installer version 2.0, minor upgrades are no longer required to install new child features by using the ADDLOCAL property. Instead new child features can be authored by including msidbFeatureAttributesFollowParent and msidbFeatureAttributesUIDisallowAbsent in the Attributes field of the Feature table.

To install new features with minor upgrades, using a version of the Windows Installer earlier than version 2.0, one must list the new features on the command line as values of the ADDLOCAL property. One must explicitly set the REINSTALL property to the list of features to be reinstalled and not simply set REINSTALL to “ALL”.