Components and Features

Reference information
Objects on this page Assembly, Component, Feature, Merge Module, Merge Module Dependency, Merge Module Exclusion, Object Reference
Related topics Working with project pages

Introduction

The Components and Features page defines the physical (development) and logical (user-visible) organization of your product's contents in the installer. It also contains any merge modules that you have imported into your project.

The Components and Features page has a tree view on the left and a list view on the right. The tree view combines the Features tree, the Components tree, and the Merge Modules tree. The list view displays the contents of the currently selected tree view item.

Tip: You can use drag & drop to move features in the Features tree and to add components (from the Components tree) to features (in the Features tree). You can also drag & drop objects from the list view of one component to another component in the tree view.

Features and components

In the installer, the features that you define for your product are visible as a tree of installation options; the branches of the trees (i.e., features and subfeatures) can be selected or not selected for installation. Components are not visible in the installer, but are present internally.

For example, assume that you are designing an installer for a suite of office productivity tools. The suite might include a word processor, a database manager, and a spreadsheet. Each of those applications in turn may have one or more optional extras, such as content templates, spell checkers, and additional help resources.

In the installer, each top-level application would be a feature and each of the optional extras would be a subfeature of its application:

Office Suite
    Word Processor
        Document templates
        Spell checker
    Database Manager
        Spell checker
        Programming Reference (Database)
    Spreadsheet
        Solution templates
        Spell checker
        Programming Reference (Spreadsheet)

Internally, the applications might share the same spell checker and dictionaries, but have separate implementations of their other functionality. Therefore, you could define the product's components as follows:

WP_Core           (Word processor application files and settings)
WP_Templates      (Word processor optional template files and settings)
DB_Core           (Database manager application files and settings)
DB_ProgRef        (Database manager programming reference files and settings)
SS_Core           (Spreadsheet application files and settings)
SS_Templates      (Spreadsheet optional template files and settings)
SS_ProgRef        (Spreadsheet programming reference files and settings)
Common_SpellCheck (Spell checker and dictionary files and settings)

You would then link the components to the features that require them:

Office Suite [no components, only subfeatures]
    Word Processor [WP_Core]
        Document templates [WP_Templates]
        Spell checker [Common_SpellCheck]
    Database Manager [DB_Core]
        Spell checker [Common_SpellCheck]
        Programming Reference (Database) [DB_ProgRef]
    Spreadsheet [SS_Core]
        Solution templates [SS_Templates]
        Spell checker [Common_SpellCheck]
        Programming Reference (Spreadsheet) [SS_ProgRef]

The Common_SpellCheck component is used by more than one feature and will be installed if at least one of those features is selected for installation. The other components are each used by a single feature and will be installed for them as required.

In practice, you will probably use finer-grained components; MSI installers require this and Tarma native installers don't mind. As a result, each feature will typically contain several components, but the overall principle remains the same.

MSI note MSI requires very fine-grained components, usually one component per executable file. (Non-executable files may be combined much more freely.) If you plan to build an MSI installer from your Tarma ExpertInstall project, you can make this easier by checking the Create separate component for each item box in the Bulk Import dialog when you add groups of files to your project.

Tarma note Tarma native installers have more relaxed rules for features and components. You can build a Tarma native installer without using any features or components at all; in that case, there are no product options available (although the installation folder can still be selected by the customer) and all product contents are always installed. Most of the time, however, your Tarma native installer will use some features and components, but Tarma imposes very few restrictions on the composition of your components.

Merge modules

Although merge modules are MSI-based packages, you can use them for both MSI and Tarma native installers. When you import a merge module into your project, Tarma ExpertInstall converts the MSI information in the merge module to Tarma's own project format; from then on, you can use the merge module's contents as you would any part of the project.

Tin2 note Tarma Installer 2.x upgrade notes

Tarma Installer 2.x did not use features or components; all product contents except shortcuts were always installed. However, it was possible in Tarma Installer 2.x to control installation of files and certain system settings by using a combination of language and platform options, and by using conditions.

In Tarma ExpertInstall, these options and conditions have moved to the component level. If you import a Tarma Installer 2.x project with any of these options into Tarma ExpertInstall, it will automatically create components that correspond to the various options. Wherever possible, files, registry settings, etc. that use identical options and conditions in the Tarma Installer 2.x project are assigned to the same component.

For more information about the conversion of Tarma Installer 2.x projects, see the topics in the Upgrading from Tarma Installer 2 section.