Installer Components, Files, and Folders

  • Article

   

Visual Studio Installer makes it easy to build application installers on the foundation of installer components. "Component" has a special meaning for the Microsoft® Windows® installer, and thus for Microsoft® Visual Studio® Installer projects. You may be familiar with the concept of a COM component, but the components you work with in Visual Studio Installer projects are different, as described below.

Features and Components

Applications installed with the Windows installer consist of features and components:

  • Features are the basis of the application's functionality from the end user's perspective. For example, the Microsoft® Word spelling checker is a feature of Word. Features are composed of installer components.

  • Installer components are the basis of the installed application from your development perspective. End users do not see components; they see only features constructed with them. When authoring an installer package file, however, you work with components.

An installer component is the smallest entity the Windows installer installs or uninstalls. A single component can consist of a single file, a logically related group or combination of files, file shortcuts, file extensions, MIME types, registry entries, or any combination.

No matter how many different elements comprise a component, the Windows installer views the component as a single piece of the installed application. Windows installers, including those authored with Visual Studio Installer, always install and uninstall each component as a single piece. This provides increased stability in installing and uninstalling applications.

For additional information about Windows installer components and features, search for "Components AND Features" in the MSDN™ Library Visual Studio 6.1 under the topics*, Platform SDK, Setup and Systems Management Services, Setup*, and Windows Installer Programmer's Reference.

Stable Installations and Uninstallations

When the Windows installer installs or uninstalls a component, it treats every element of that component as part of a single entity. This component-based (rather than file-based) installation has important implications for installation and uninstallation stability.

Instead of keeping a traditional reference count of installed files, the Windows installer maintains a list of products that have installed each component (installed with the Windows installer). That means, whenever a particular application installs a component, the Windows installer makes a note of which product installed the component.

For example, suppose the Windows installer installs a component related to a spelling checker as part of both a Word and a Microsoft® Outlook® installation. If Word installs the component first, then the Windows installer records that Word installed the component. The information about which product uses it becomes part of the component information. If Outlook then installs the same component, the component is not physically reinstalled. Instead, the Windows installer just adds Outlook to the list of applications using this component.

Component with reference list of installed applications

When the Windows installer uninstalls an application, it also updates product information for any components using that product. That means, for every component the uninstalled product used, the installer removes the product's name from the component's list of applications that use it. So, Windows always knows exactly which applications still use which components (providing those components were installed with the Windows installer).

If all applications and components are installed with the Windows installer, this reference listing of applications using components ensures no component is removed unless and until it is no longer required by any application. And, because the Windows installer treats all elements of a component as part of the single entity, no single files, shared libraries, controls, or other component elements are individually removed either. Application installers correctly based on installer components provide increased installation and uninstallation stability to your users.

Important   In order for Windows installer component installation to work correctly, all applications that share components must install exactly the same component. So, if Word installs a spelling checker-related component under one component ID, and Outlook installs exactly the same spelling checker-related files and information but under a different component ID, the Windows installer cannot keep correct information about which products use the shared files. To share a file correctly among internal and external application installers, you must use exactly the same component in every installer.

Rules for Installing Components

To gain the maximum benefit of installation and uninstallation stability from the Windows installer, you must install all shared files as elements of installer components — that is, as components in an installer package (.msi) file. An even better practice is to install any file you think you may someday want to share as part of an installer component.

The best practice is to install each file as an installer component. This sets the groundwork for correctly sharing files, and reduces installation instability in the future. Visual Studio Installer makes it easy to write component-based application installers. For more information, see Managing Components, Files, and Folders in an Installer Project.

Merge modules (.msm files) are the vehicle for sharing components among .msi files. For more information about installer and merge modules, see Installer Package Files and Merge Modules.

Packaging shared installer components in merge modules (.msm files) is essential for correctly writing Windows installer package (.msi) files. You can use merge modules correctly in all of these cases:

  • To include any standard Microsoft shared components with Windows installer packages (.msi) files, you must use the .msm file for the component. Microsoft provides standard merge modules for many commonly shared components, including the Microsoft® Visual Basic® run-time file, Microsoft Foundation Classes (MFC), and Active Template Libraries (ATLs).

  • To include a shared component authored by a third-party vendor in an .msi file, contact the vendor for the correct .msm file.

  • To share a component you have written among multiple applications, you should author and package the component as an .msm file. You can author .msm files with Visual Studio Installer.

Installing Legacy Files

Though increased installation and uninstallation stability depends on using Windows installer components as application building blocks, there may be some cases when you must install shared files that do not belong to an installer component. For example, you might write or use a component that includes a shared file that already exists on the target machines. In this case, deleting the shared file when your shared component is uninstalled could break the older application that originally installed the file. Visual Studio Installer provides protection for cases like this by allowing you to set a legacy flag for files that may be used by applications installed by non-Windows installers. For more information, see .

Components in Visual Studio Installer

Visual Studio Installer makes it easy to build application installers on the foundation of installer components. Specifically, Visual Studio Installer:

  • Manages all installed files as component elements.

  • Makes it easy to identify the component a file belongs to.

  • Provides visual component display and management.

Visual Studio Installer Components, Files, and Folders

One way to create components in Visual Studio Installer is to add a file to your installer project. Every file you add to an installer project is initially its own component: when you add a file to an installer project, Visual Studio Installer creates a component with that file as the key file. Visual Studio Installer best practice recommendation is to make each file included in your installer project a component.

To meet Windows installer requirements, all files belonging to a component must be installed in the same directory on the target machine. For example, if your localized components are stored in a localization directory (as they often are), the Windows installer requires you to create localized components separate from their source components. All files for the source component will be installed in one target machine directory, and all files for the localized component will be installed in a different target machine directory.

Visual Studio Installer Component Identification

Globally Unique Identifier (GUID) strings uniquely identify installer components. A sample GUID might be {880DE2F0-CDD8-11D1-A849-006097ABDE17}. Visual Studio Installer automatically generates a unique GUID for every installer component you create.

Visual Studio Installer also gives each component the name of its key file, so a unique key file identifies each component. For example, if the file comp1.dll is the key file for an installer component, the component's name (for purposes of working within Visual Studio Installer) is also comp1.dll. This gives you a way to identify and manage components without relying on the component's GUID.

Important   The key-file naming convention only applies within Visual Studio Installer and is provided simply for your convenience. Remember the component's true identifier is its GUID.

Visual Studio Installer Visual Component Management

The Visual Studio Installer File System editor provides a limited visual display of the files that make up your application, where they will be installed on the target machines, and how they are grouped into components.

The File System Editor File and Component Display

The Visual Studio Installer File System editor displays the file structure of installer components on target machines. In the File System editor, you can add files to the installer project, create new installer components, and drag files among components.

Icons and indentation in the File System editor provide information about component composition:

  • File names displayed with this component key icon are component key files: .

  • Files indented and listed without a component key icon beneath a component key file are non-key files belonging to that component.

The File System Editor Folder Display

The Visual Studio Installer File System editor displays the target machine's folder (directory) and file structure. In the File System editor, you can create new folders for components and drag files and components among target machine folders. By providing this visual folder, file, and component management system, Visual Studio Installer helps to ensure you meet the Windows installer requirement of installing all files belonging to a component in the same target machine folder.