Implement component breakdown correctly

Benefits

• Allows correct implementation of Self-repair and Just-In-Time installs
• Makes programs more robust
• Minimizes hard drive space needed to run your application
• Helps to deliver us from DLL hell

Description

One of the great new features of Microsoft^® Windows^® 2000 is the Windows Installer Service, which allows you to provide a cool functionality such as self-repair and install on demand. To offer these features, you’ll need to ensure that you breakdown your application correctly into features and components.

One of the great new features of Microsoft^® Windows^® 2000 is the Windows Installer Service, which allows you to provide a cool functionality such as self-repair and install on demand. To offer these features, you’ll need to ensure that you breakdown your application correctly into features and components.

So what do we mean by breaking down your application into features and components? Well, the Windows Installer divides applications into a three-level hierarchy. At the top of the hierarchy is a product—something a user can install. A product is composed of multiple features. A feature is the smallest installable unit of functionality and is made up of one or more components or features.

Products represent the overall application or suite being installed. A product is composed of one or more features. An example of a product would be Microsoft Office.

Features are collections of components. If you think of common setup user interfaces, a feature maps to a checkbox in the "custom" or "advanced" installation dialog; it is something a user can choose to not install. A component is the smallest unit of sharing among products and features. While features are specific to a product and identified by a name unique only within the product, components are global across all products installed on a machine and are identified by a GUID. Although a COM component can be encapsulated as an installer component—and most COM components probably will be—don't confuse the terms. An installer component has nothing at all to do with COM.

Components are the actual contents of your product. A single component may be composed of files, registry entries, COM registration information, Microsoft^® Visual Basic^® type libraries, shortcuts for the Windows Start menu, and so on. An installer componentt is either entirely installed on a machine or not installed at all. Because installer component identifiers are global, they are shared across products.

When breaking your application into features, ask yourself these questions, if you answer no to one or more of the following questions, you might want to reconsider your feature breakdown:

• Does the feature present a single functionality to the user?

• Does it make sense to install the feature by itself?

• Conversely, does it make sense to install the entire feature at once?

• Might an administrator want to make the feature available or unavailable, depending on the needs of groups of users?

When breaking down your application into components, ask yourself these questions, if you answer no to any of these questions, you should consider a different separation of the application into components:

• Do your application's features and components have a close relationship?

• Do all parts of the component map to a common feature?

• Do all files of a component have a common installation location?

When designing your components and features, remember to follow the following rules, taken from the Windows 2000 Application Specification:

• A single resource must not be shipped as a member of multiple components across multiple products, unless it is isolated as its own component and is flagged as shared in the component table.

• All files in a given component must be installed to the same directory. This means files in different directories must be in different components.

• All files that are the targets of advertisable shortcuts must be the KeyPath of a component. This means there can only be one advertised file per component, although many different shortcuts can point to that single file.

• COM servers must be the KeyPath of a component. This means there can only be one COM server per component. A single file, which can only be in one component, may serve multiple CLSIDs. However, two files serving different CLSIDs must be in separate components.

• Extension servers must be the KeyPath of the component. This means there can only be one Extension server per component.

See Also

Organizing Applications into Components