Skip to main content

Posts

Showing posts with the label Component Rules

Components: Do's and Don'ts & Few Common ICE issues

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. ●    ...

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 ex...