Product & Its Components & Features

Components

A component is the minimal part of a product-each component is treated by Windows Installer as a unit: the install developer cannot, for example, use a condition to specify to install just part of a component. Components can contain files, groups of files, directories, COM components, registry keys, shortcuts, and other data. The end user does not directly interact with components.

Components are identified globally by GUIDs, thus the same component can be shared among several features of the same package or multiple packages, ideally through the use of merge modules (although, for this to work correctly, different components should not share any sub-components).

Key paths

A key path is a specific file, registry key, or ODBC data source that the package author specifies as critical for a given component. Because a file is the most common type of key path, the term key file is commonly used. A component can contain at most one key path; if a component has no explicit key path, the component's destination directory is taken to be the key path. When an MSI-based application is launched, Windows Installer checks the existence of these critical files or registry keys (that is, the key paths). If there is a mismatch between the current system state and the value specified in the MSI package (e.g., a key file is missing), then the related feature is re-installed. This process is also known as self-healing or self-repair. No two components should use the same key path.

Features

A feature is a hierarchical group of components-a feature can contain any number of components and other features ("sub feature"). Most installation programs display a "custom setup" dialog box at run time, from which the end user can select which features to install or remove.

The package author defines the product features. A word-processing program, for example, might provide features for the main program executable, the program's help files, and optional spelling checker and stationery modules.



A component can consists of a single file, multiple files, registry keys, desktop shortcuts, or some combination thereof. The resources within a component must be unique so that no two components can contain the same resource. A component is never installed explicitly; it is only installed as part of a feature.

Let’s put all files into one component. The KeyPath should be then one of the files of your component to check if it was installed or not. When your installation becomes corrupt

Because a file was deleted you cannot repair it with the Repair button under Add/Remove Programs because MSI checks the component integrity via the Resource referenced by its KeyPath. As long as you did not delete the KeyPath file MSI thinks all resources with your component are installed and never executes any repair action.

The only way out and therefore

best practice is to assign for every resource you want to install an extra component. This ensures painless updatability and repairs and you have much less effort to remove specific files during an upgrade.

In effect you get this best practice relation

Feature	1  –> n Components
Component	1  –>  1 Resources

Advertised Feature: means that MSI treats all components of this feature as not installed. As a consequence during uninstall nothing will be removed since it is not installed! This is not only bad because uninstall does no longer work but this feature will also not get the required patches. All other features which have followed component versioning rules for update packages will be updated but the one faulty feature will not. This results in very hard to find bugs why an update was only partially successful.

Things got better with Windows Installer 4.5 but you cannot rely on that nobody will use an older installer. It is a good idea to add to your update msiexec call MSIENFORCEUPGRADECOMPONENTRULES=1 which will abort the installation if you did violate this rule.

What are the Red Components? Why do they appear?

Red Components is an error component. When components are not satisfied by the component rules

then we get red component.

What are the component Rules?

Σ every component have unique GUI

Σ Every Component Should have a key path

Σ HKLM&HKCU registries are not present in the same component

Σ .exe, .dll, ocx files should not present in the same component

Σ Two components can't install in the same resource

What are the Component attributes 0, 2, 4, 8, 16, 32?

0 => 0X0000

msidbComponent attributes local only

Component can't run from source.

Prevent the feature from being run from my computer.

2 => 0X0002

msidbComponent Attributes Optional

Run locally or from source.

16 => 0X0010

msidbComponent Attributes Permanent

Installer doesn't remove the component during un-installation.

32 => 0X0020

msidbComponent Attributes ODBC Data source

This bit is set the value in the key-path column a key into the ODBC data source.

64 => 0X0040

msidbComponent Attributes Transitive

Reevaluates the value of the statement.

128 => 0X0080

msidbComponent Attributes Never Overwrite

Installer does not install or reinstall the component if key-path file or key-path registry entry of the

component already exists.

256 =>0X0100

MsidbComponent Attributes includes both 32-bit&64-bit

If the bit is not set, the component is registered as a32-bit component. If this is a 64-bit component

replacing 32-bit.

BIT FLAG DESCRIPTION	DECIMAL VALUE
Component cannot be run from source	0
Component can only be run from source	1
Component can run locally or from source	2
Has a Registry Keypath	4
Increments Shared DLL Registry Count	8
Permanent Component (doesn’t remove on uninstall)	16
Has an ODBC Data Source Keypath	32
Re-evaluates Condition on Reinstall	64
Do Not Overwrite if Component Exists	128
64-Bit Component	256
Disable Registry Reflection	512
Prevent Leaving Orphan Components	1024
Share Component	2048

When we want to set multiple bit flags on a component, we add the decimal values together. For example, let’s say we have a component which contains a 64-bit DLL as the keypath, and we want to incrememnt the shared DLL reference count. The attribute of our component would be:

(Increments Shared DLL Registry Count + 64-Bit Component)
= 8 + 256
= 264

All About Feature Table:

Feature Column:

 It is a Primary key used to identify a particular feature record.

Feature_Parent:

Feature 2 will be its parent feature, since Feature 1 feature is a child feature of Feature 2.

Title:

Title will be the Short string of text identifying the feature. So in this case it will be Feature –1.

Description:

Longer string of text describing the feature. It can be NULL

Display:

     

Value	Appearance in UserInterface
NULL	Feature not displayed
ODD NUMBER	Displayed as expanded
EVEN NUMBER	Displayed as collapsed

Level:

The initial installation level of this feature. An install level of zero disables the item and prevents it from being displayed.

Directory:

Directory_ column specifies the name of a directory that can be configured. In this particular example the Directory is INSTALLDIR.

Directory	Full path
1) INSTALLDIR	C:\ProgramFiles\{Application Name}. Ex: “C:\Program Files\Adobe”. Where Adobe is application name.
2) TargetDir	Ex: “C:\”

Attributes:

This field specifies the remote execution option for features that have not yet been installed 

A component with a blank Component ID is not installable or manageable via the Windows Installer APIs.

●     If the Component table’s component field is left null, justification must be documented.

●     There must not be more than one COM server included per component. 

●     If a component contains a COM server, this must be the KeyPath for the component.

●     No two components should share the same KeyPath.

●     There must not be more than one file specified per component as a target for the Start menu or a Desktop shortcut.

Do not keep more than one critical file on same component as you won’t be able to keep all as key-paths, which is mandatory.

In case of multiple critical files, make separate component for each of them.

●     Components should not contain multiple EXE’s, DLL’s, OCX’s, CHM’s, or HLP’s.

●     Only one ODBC Data Source or INI file should be specified per component.

●     Only one Shortcut should be included in a component.

●     In general, all ICE errors should be fixed. Only exceptions are ICE33 and ICE36 warnings.

●     If ICE errors can’t be fixed they have to be documented

Troubleshooting Tips: check the KEY PATH of each affected component, when the application is not running, as it is the KEY PATHS of every component that are checked during application startup, and any missing KEY PATHS trigger the repair of the entire feature which holds the component.

Typical causes are components that are hard coded to install to a specific user profile, instead of installing by reference to the current user's profile. Since users do not usually have access to other user's profiles, such self healing operations will fail each time, and therefore will continue to happen at every future application startup.

Component Table:

KeyPath: The KeyPath is a reference to a file or registry key which is used to detect if the component is already installed. This becomes important when you repair or uninstall a component. To find out if the component is already installed MSI checks if the registry key or file referenced by the KeyPath property does exist.

Directory:
This is the directory where the component will install. This field is not editable.

What is self-healing?

When an MSI-based application is launched (by clicking on an advertised shortcut or file type association), Windows Installer checks the existence of key path items. If there is a mismatch between the current system state and the value specified in the MSI package (e.g., a key file or registry is missing), then the related feature is reinstalled. This process is also known as self-healing or self-repair.

Every component is assigned a unique component code GUID.

What is Product?

A single, installed, working program (or set of programs) is a product. A product is identified by a unique GUID (the ProductCode property). A product is not the same as a package: a single MSI package might install multiple different products. For example, an MSI might install French and English versions of a program, each of which is a different product.