What is a Component?

A component is a piece of the application or product to be installed. They are the fundamental unit that defines the functionality of the software application.  Examples of components include single files, a group of related files, COM objects, registry keys, INI file settings, shortcuts, resources, libraries grouped into a directory. The following list provides a summary of information about Component structure and attributes:

• File resources: – Components can contain file resources. If a file resource is the key path to the Component, it is known as the key file. If a file is not the key path, it is known as a companion file. There is no practical limit on the number of files or file types that can be in a Component. There are, however, rules about Component structure that define when certain types of files should have an entirely dedicated Component.
• Registry resources: – Registry resources are registry keys that are required by the Component.
• Shortcut resources (entry point): – Shortcuts are defined within a Component and must point to a file within the Component. Shortcuts can be advertised (entry points) or standard Windows shortcuts.
• Document extension mappings and MIME types (entry points): – Document extensions and MIME types are configured at the Component level and point to a file within the Component.
• Additional resources and attributes: – Components can have many resources and configuration items associated with them. Some of these include:
  • Controlling and installing services
  • Making INI file entries
  • Creating directories
  • Setting environment variables
  • Configuring ODBC

Some new attributes that are specific to Windows Installer can also be a part of a Component, including entry points, key paths, and Component Codes.

---

How are components identified?

A component is identified by its Component Code which is unique. Although a Component can contain these items, it is not required to contain all of them. The installer service installs or removes a component as a single coherent piece. It tracks every component by the respective Component GUID specified in the ComponentId column of the Component table. Two components that share the same component ID are treated as multiple instances of the same component regardless of their actual content. Only a single instance of any component is installed on a user’s computer. Several features or applications may therefore share some components.

What are Reference Counts?

Components are also reference counted to prevent uninstallation when more than one application is using a shared piece of software. Reference counts were introduced with Windows 95. All installation programs that follow Microsoft’s installation guidelines increment a counter in the registry whenever a DLL is installed to a shared location, such as the system directory. For example, if four applications had installed abc.dll to the System32 directory, that DLL would have a reference count of 4 in the registry. If one of the applications is uninstalled, the uninstall program would simply change the reference count to 3 and leave the file in place because other applications are obviously using the DLL. If the reference count for a file is 1, the uninstall program is free to remove the file because it can assume that the program being uninstalled is the only program using the file. Occasionally, uninstall programs will break other software because they remove shared registry keys required for a DLL to work properly. Windows Installer improves on reference counts by putting them at the Component level. Because a Component contains all the various system resources required for a DLL to operate properly, these related resources will remain on the system if other software is still using the DLL. When a user selects a feature for installation, the installer determines which components must be installed to provide that feature.

What are entry points?

A very important attribute of a Component are the Entry Points. These allow Windows Installer to proxy the startup of an application and perform application management tasks before the user is allowed to access the application. In other words, when you double-click the icon for a Windows Installer packaged software application, it does not actually attempt to start the application directly. The icon is a special icon that asks Windows Installer to find the software application and start it. This is when Windows Installer can use the MSI repository information, the installed application resources (files, registry keys, and so on), and the original package file to perform the magic of self-healing and install on demand. An entry point turns into an advertised interface when any Feature that its Component belongs to is advertised or installed on a target computer system. When a Windows Installer package is advertised, advertised interfaces make it appear as though the application is installed and ready to use. When a Windows Installer package is installed, advertised interfaces trigger Windows Installer for self-healing and user profile fix-up checking. An entry point/advertised interface can be:

• A shortcut (special Windows Installer shortcut)
• A document extension (association)
• A MIME type (Internet document types)
• A Class ID (CLSID)—Programmatic identities used for sharing software within and between various applications

How do Components work?

Through the concept of a Component, Windows Installer uses metadata to model a functional unit of the application software it is describing. This Component definition is placed in the repository of any machine on to which it is installed. However, if the Component becomes broken, how does Windows Installer tell that the Component is not installed as defined in the repository? For each Component that is installed on a computer, Windows Installer checks the existence of a specially tagged resource known as a key path within the Component to determine whether the Component is healthy or in need of repair. If this tagged resource is missing, the entire Component is re-installed. A key path can be a directory, a file, a registry key, or an ODBC data source. The reason that Microsoft Word still works when winword.exe is deleted is because winword.exe is the key path of a Windows Installer Component. When a user attempts to use Microsoft Word, Windows Installer checks to see that the key path of this Component (winword.exe) exists. If it does not exist, self-healing would be invoked to fix the problem. Among the uses of a key path, three are very relevant to administrators:

• Self-healing detection
• Advertising/Install-on-Demand detection
• User profile fix-up detection– Although not a formal term, user profile fix-up refers to a lesser known feature of Windows Installer that lets installed packages properly set up a user profile when the user has not previously used the application. This functionality works even when the user has previously logged on to the computer. When a user starts an application, standard self-healing checks are performed. If the package is structured correctly, Windows Installer will perceive the lack of user information for the application as being “broken” and self-heal the user portions of the package.

Component Rules

Because components are commonly shared, the author of an installation package must follow strict rules when specifying the components of a feature or application. This is essential for the correct operation of the Windows Installer reference-counting mechanism. In brief, these rules are:

• Each component must be stored in a single folder.
• No file, registry entry, shortcut, or other resources should ever be shipped as a member of more than one component. This applies across products, product versions, and companies.
• Never create two components that install a resource under the same name and target location. If a resource must be duplicated in multiple components, change its name or target location in each component. This rule should be applied across applications, products, product versions, and companies.
• Note that the previous rule means that two components must not have the same key path file. If two components have the same key path file, the installer would be unable to distinguish which component is installed. Two components however may share a key path folder.
• Do not create a version of a component that is incompatible with all previous versions of the component. This rule should be applied across applications, products, product versions, and companies.
• Do not create components containing resources that will need to be installed into more than one directory on the user’s system. The installer installs all of the resources in a component into the same directory. It is not possible to install some resources into subdirectories.
• Do not include more than one COM server per component. If a component contains a COM server, this must be the key path for the component.
• Do not specify more than one file per component as a target for the Start menu or a Desktop shortcut.
• Apart from the above rules, Windows has some of its own requirements for component sharing. There are four requirements in this group:

• Do not attempt to defeat Windows File Protection- Windows File Protection is a new feature of Windows 2000 that prevents attempts to overwrite most files that Windows 2000 itself installs. This feature is designed to increase the stability of Windows by preventing other applications from overwriting necessary system files with newer but potentially conflicting versions. If you properly follow the Installer rules for componentization you won’t run afoul of system file protection. That’s because you’re only allowed to create components from files that you produce, and all of the files protected by system file protection are produced by Microsoft. When those files need replacing, Microsoft will do so via a service pack for Windows 2000 only.
• Build side-by-side components- Side-by-side components are a new attempt on the part of Microsoft to avoid the “DLL Hell” syndrome in which upgrading a shared library would break older applications that depended on the old version of the library. Windows 2000 and Windows 98SE support side-by-side components. Basically, this means that you can install .DLLs in the same folder as their parent application, and the operating system will allow multiple versions of the .DLL to be loaded at one time. If you’re using the Windows Installer to install your application, and you install a .DLL to the same folder as your application, it will automatically do the right thing.
• Install side-by-side components- This is the flip side of the previous requirement. If you build side-by-side components, you must use them. The Windows Installer will make the correct Registry entries for side-by-side .DLLs to ensure this.
• Install shared files to the correct locations- If your application installs shared files for older operating systems, you must put them in one of two places:
• Common Files\<company name>
• Program Files\<company name>\Shared Files

The Windows Installer provides built-in properties to locate the Common Files and Program Files directories, so installing files to these locations is just a matter of making the right entries to the File and Directory tables.

What happens when Component rules are broken?

In certain cases, authors may decide they need to break the rules for creating components Authors need to be aware of the possible consequences of doing this and must otherwise guarantee that their components are never installed where they can damage other applications or components on the user’s system. The following list describes ways that authors sometimes break the recommended component rules and the possible consequences.

An author adds resources to a component without the changing the component code

• Products installed with the old component have no information about the added resources in their installation database.
• If both a new product that has the added resources and an old product are installed on the same computer, the resources can be left behind if the new product is uninstalled first.
• An old product without the added resources cannot repair the newer version of the component. Reinstalling the old product does not restore the added resources.

An author removes resources from a component without changing the component code.

• Products installed with the new component have no information about the removed resources in their installation database.
• If both an old product, having the resource information, and a new product are installed on the same computer, the resources can be left behind if the old product is uninstalled first.
• A new product with the removed resources cannot repair the older version of the product. Reinstalling the new product does not restore the removed resources.

An author includes a file that is incompatible with previous versions without changing the component code

If an incompatible file is included in a component without changing the component code, Default File Versioning causes the installer to overwrite the original file with the more recent incompatible file. This can damage old products needing the original file. It may also prevent the installer from repairing the old product because the version of a component’s key path file determines the version of the component. If a newer version of the key path file is already installed, the installer does not install an older version of the component. In this case, the new product must be removed before the old product can be reinstalled.

• Default file versioning causes the installer to overwrite the original file with the more recent incompatible file.
• Old products that need the original file are damaged.
• It may also prevent the installer from repairing the old product because the version of a component’s key path file determines the version of the component. If a newer version of the key path file is already installed, the installer does not install the older version of the component. In this case, the new product must be removed before the old product can be reinstalled.

An author includes the same resource in two different components

If two components have a resource under the same name and location and both components are installed into the same folder, then the removal of either component removes the common resource, which damages the remaining component.

• Uninstalling either component removes the resource and breaks the other component.
• The component reference-counting mechanism is damaged.

How to organize an application into Components?

The following outlines how to organize your application into Windows Installer components.

1. Begin by obtaining a directory and file tree for all of the files and other resources used in your application.
2. Identify any files, registry keys, shortcuts, or other resources that are shared across applications and can be provided by existing components available as merge modules. You must not include any of these resources in the components you author. Instead obtain these components by merging the merge modules into your installation package. The following steps describe how to organize the remaining resources of the application into components.
3. Define a new component for every .EXE, .DLL, and .OCX file. Designate these files as the key path files of their components. Assign each component a component code GUID.
4. Define a new component for every .HLP or .CHM help file. Designate these files as the key path files of their components. Add the .CNT or .CHI files to the components holding their associated .HLP and .CHM files. Assign each component a component code GUID.
5. Define a new component for every file that serves as a target of a shortcut. Designate these files as the key path files of their components. Assign each component a component code GUID.
6. Group all of the remaining resources into folders. All resources in each folder must ship together. If there is a possibility that a pair of resources may ship separately in the future, put these in separate folders. Define a new component for every folder. Try to keep the total number of components low to improve performance. Divide the application into many components when it is necessary to have the installer check the validity of the installation thoroughly. Designate any file in the component as the key path file. Assign each component a component code GUID.
7. Add registry keys to the components. Any registry key that points to a file should be included in that file’s component. Other registry keys should be logically grouped with the files that require them.

Attributes column in the Component Table

All data related to a Component is stored in the Component table. This table has many columns. Out of those columns, the Attribute column is of special importance because this column decides the behavior of that particular component.

This column contains a bit flag that specifies options for remote execution. Add the indicated bit to the total value in the column to include an option.

Bit flag name	Decimal	Remote execution option
msidbComponentAttributesLocalOnly	0	Component cannot be run from source. Set this bit for all components belonging to a feature to prevent the feature from being run-from-network or run-from-source. Note that if a feature has no components, the feature always shows run-from-source and run-from-my-computer as valid options.
msidbComponentAttributesSourceOnly	1	Component can only be run from source. Set this bit for all components belonging to a feature to prevent the feature from being run-from-my-computer. Note that if a feature has no components, the feature always shows run-from-source and run-from-my-computer as valid options.
msidbComponentAttributesOptional	2	Component can run locally or from source.
msidbComponentAttributesRegistryKeyPath	4	If this bit is set, the value in the KeyPath column is used as a key into the Registry table. If the Value field of the corresponding record in the Registry table is null, the Name field in that record must not contain “+”, “-“, or “*”. For more information, see the description of the Name field in Registry table. Setting this bit is recommended for registry entries written to the HKCU hive. This ensures the installer writes the necessary HKCU registry entries when there are multiple users on the same machine.
msidbComponentAttributesSharedDllRefCount	8	If this bit is set, the installer increments the reference count in the shared DLL registry of the component’s key file. If this bit is not set, the installer increments the reference count only if the reference count already exists.
msidbComponentAttributesPermanent	16	If this bit is set, the installer does not remove the component during an uninstall. The installer registers an extra system client for the component in the Windows Installer registry settings.
msidbComponentAttributesODBCDataSource	32	If this bit is set, the value in the KeyPath column is a key into the ODBCDataSource table.
msidbComponentAttributesTransitive	64	If this bit is set, the installer reevaluates the value of the statement in the Condition column upon a reinstall. If the value was previously False and has changed to True, the installer installs the component. If the value was previously True and has changed to False, the installer removes the component even if the component has other products as clients. This bit should only be set for transitive components..
msidbComponentAttributesNeverOverwrite	128	If this bit is set, the installer does not install or reinstall the component if a key path file or a key path registry entry for the component already exists. The application does register itself as a client of the component. Use this flag only for components that are being registered by the Registry table. Do not use this flag for components registered by the AppId, Class, Extension, ProgId, MIME, and Verb tables.
msidbComponentAttributes64bit	256	Set this bit to mark this as a 64-bit component. This attribute facilitates the installation of packages that include both 32-bit and 64-bit components. If this bit is not set, the component is registered as a 32-bit component. If this is a 64-bit component replacing a 32-bit component, set this bit and assign a new GUID in the ComponentId column.
msidbComponentAttributesDisableRegistryReflection	512	Set this bit to disable registry reflection on all existing and new registry keys affected by this component. If this bit is set, the Windows Installer calls the RegDisableReflectionKey on each key being accessed by the component. This bit is available with Windows Installer version 4.0 and is ignored on 32-bit systems.

 

What are Qualified Components?

A qualified component is a method of single-level indirection, similar to a pointer. The easiest way to understand qualified components is to consider some of the problems of localized software. Suppose you’ve created a program that uses a file named tips.txt to hold “tip of the day” information that the user can choose to display. Being a developer of software for the global market, you’ve had tips.txt translated into five different languages. And being a good user of the Windows Installer, you’ve chosen to advertise this component, rather than install it, so that it doesn’t take up disk space unless the user chooses to view tips. Now, think about the code within your product at the time when the user chooses to turn on the tips and you need to install the advertised file. The Windows Installer provides an API call named MsiProvideComponent that, given a component code (the GUID for a component), will install that component. If this was your only choice for installing components, the logic of your code might look like this (of course, this is pseudo code, not actual Visual Basic code):

If Language = English Then

Call MsiProvideComponent (EnglishGUID)

ElseIf Language = French Then

Call MsiProvideComponent (FrenchGUID)

ElseIf Language = German Then

Call MsiProvideComponent (GermanGUID)

ElseIf Language = Japanese Then

Call MsiProvideComponent (JapaneseGUID)

ElseIf Language = Spanish Then

Call MsiProviderComponent (SpanishGUID)

Code based on this pseudo code would get the job done, but there’s a better alternative, and that’s where qualified components come in. The Windows Installer provides another API call named MsiProvideQualifiedComponent. This API call takes a component category code (another GUID) and a text qualifier and uses them to find the actual component to install. Using MsiProvideQualifiedComponent would reduce the pseudo code to the following line:

Call MsiProvideQualifiedComponent (CategoryGUID, Language)

Where to enter Qualified Components?

Qualified components are entered in the Component table in the same way as ordinary components. Every component must have a unique component GUID and component identifier specified in the Component table. In addition, qualified components are associated with a category GUID and a text-string qualifier in the PublishComponent table. Qualified components are referenced by the category GUID and the qualifier, which just points to the ordinary component in the Component table. For example, a qualified component GUID can point to different language versions of a resource DLL. In this case, the group of localized resource DLLs comprises the category and the numeric locale identifiers (LCID) strings are commonly used as the qualifiers.

How to use Qualified Components?

To group components together into a qualified-component category, the following instructions must be followed: –

1. There must be a record in the Component table for each component that is included in the new category of qualified components. Author the fields in the Component table the same as for ordinary components. Note that each qualified component must have a unique component GUID entered in the ComponentId column of the Component table.
2. Generate a qualifier text string for each qualified component. The qualifier must be unique text string that can be easily generated when searching for a qualified component. For example, if the components in the category are being qualified by language, the numeric locale identifier (LCID) is a reasonable qualifier string.
3. Add a record in the PublishComponent table for each qualified component. Enter the qualified-component identifiers from the Component column of the Component table into the Component_ column of the PublishComponent table. Enter the qualifier strings for each qualified component into the Qualifier column. Enter a localized string to be displayed to the user and describing the qualified component into the optional AppData column. An explanatory string should be put in the AppData field, such as “French Dictionary,” rather than just the numeric LCID. Enter the name of the feature that uses this component into the Feature_ column. The feature identifier in this field must also be listed in the Feature column of the Feature table.
4. Generate a category GUID for this category of qualified components. This must be a valid GUID. If you use a utility such as GUIDGEN to generate the GUID be sure that it contains only uppercase letters. For every qualified component in this category, enter the category GUID into the ComponentId field of the PublishComponent table.

The following example illustrates how the “FAX Templates” categories of qualified components are authored into the Component, Feature, and PublishComponent tables.

PublishComponent table: –

ComponentId	Qualifier	AppData	Feature_	Component_
{FAX Template Category GUID}	1033	US English template	FAXTemplate	FAXTemplateENU
	1041	Japanese template	FAXTemplate	FAXTemplateJPN
	1054	Thai template	FAXTemplate	FAXTemplateTHA
	1031	German template	FAXTemplate	FAXTemplateDEU

Component table: –

Component	ComponentId
FAXTemplateENU	{FAX Template (US English) component GUID}
FAXTemplateJPN	{FAX Template (Japanese) component GUID}
FAXTemplateTHA	{FAX Template (Thai) component GUID}
FAXTemplateDEU	{FAX Template (German) component GUID}

Feature table: –

Feature

FAXTemplate

FAXTemplate

FAXTemplate

FAXTemplate

What are Transitive Components?

Transitive components are regular components that are arranged in mutually-exclusive groups. The simplest example of a transitive component is a library that has different versions for Windows 95 and Windows NT. When you install the product, it installs either the Windows 95 or the Windows NT version, depending on the current operating system, but not both. What happens if the user upgrades from Windows 95 to Windows NT after installing the product? Well, in the old days (pre-Windows Installer), the answer was simple: the product stops working, because the wrong library is installed. With the Windows Installer, you can invoke msiexec with the /fm switch, and it will fix the problems.

Why are Transitive Components used?

Transitive Components enable an application installation to adapt to the system configuration during initial installation, and then allow the software to be resilient to system changes after the package has been installed. When a component is marked as transitive, the component’s condition is evaluated during initial installation as well as during subsequent reinstallations, modifications and self repairs

Where to enter Transitive Components?

The Component table inside the Installer database lists all of the components and their component codes. It also has two other columns that are important for transitive components: Attributes and Condition. The Attributes column is made up of a series of bits, one of which identifies transitive components. The Condition column provides a Boolean condition that the Installer evaluates, installing the component only if the condition is true. When a component is marked as transitive, the Windows Installer re-evaluates the Condition column on a reinstall. If the Condition is true, the Installer installs the component. If the Condition is false, the Installer removes the component, even if other products use that component (that way, the first product to be reinstalled gets fixed even if other products aren’t reinstalled). If a component isn’t marked as transitive, reinstalls restore the component to whatever state is was left in at the end of the original installation. That is, the Condition column is not re-evaluated. In addition to operating system changes, you can use transitive components to handle other machine upgrades, such as installation of a better video card or more memory, if your application contains components that can take better advantage of the new hardware.

How to include Transitive Components?

To include two transitive components in the installation package, the following instructions must be followed: –

1. Include both transitive components in the installation package.
2. Author both transitive components into the Component table the same as regular components. Each transitive component must have its own unique GUID specified in the ComponentId column.
3. Include the msidbComponentAttributesTransitive bit in the Attributes column of the Component table for each transitive component. If this bit is set, the installer reevaluates the value of the statement in the Condition column upon a reinstall. If the value was previously False and has changed to True, the installer installs the component. If the value was previously true and has changed to False the installer removes the component even if the component has other products as clients.
4. Enter complementary conditional expressions into the Condition fields of the Control table such that when the condition on the first transitive component changes to False the condition on the second transitive component changes to True. This results in the removal of the first component and installation of the second component upon reinstallation of the application.

A reinstallation of the product is necessary to switch the transitive components. Package authors therefore need to provide users with a method for reinstalling the product and for setting the modes of the REINSTALLMODE property. There are some ways to trigger the reinstallation:

• Run and configure the reinstallation through the user interface by authoring a package that uses the full UI.
• Run the reinstallation from the command line by using msiexec /f and select the modes from the list for the /f command line option.

How do Transitive Components work?

The working of transitive components is illustrated with the help of an example. Suppose you have two components in a .MSI application installation you are creating. One component, component A, contains a Support.dll file, and this file supports particular functionality in your application on Windows 9x systems. You have another component, component B which contains a newer version of Support.dll and supports the functionality on Windows NT. During the application’s installation, you place the appropriate conditions of Version 9x and Version NT for each component on the destination machine so that the correct .DLL is installed.

Now suppose a user installs the application on a Windows 98 system. Because of the system version, only component A installs. If the user later upgrades to Windows XP, they will lose functionality because component B with the Windows NT Support.dll is not installed on the machine. If you did not mark the components A and B as transitive, the user has to completely uninstall the application and then reinstall it.

On the other hand marking components as transitive enables the installation to self-repair or gives the user the option to manually run a repair from the maintenance dialog. In both instances the conditions of all Transitive components are re-evaluated in the installation. In the above example, component A for Windows 9x is removed and component B for Windows NT is installer on the system allowing the software to function properly.

Some common solutions to Component related issues

How to install a missing Component?

You can use the Windows Installer to detect missing components or files, and then reinstall features that contain the missing components. Because the Installer installs features and not components, it must first resolve to which component a missing file belongs, and then install the feature that contains the component. If more than one feature is linked to the component, the Installer installs the feature that requires the least disk space. With Microsoft Windows Installer, an application’s entry points play a major role in installing advertised features and initiating the self repair of an application. When an user uses an entry point to launch an .MSI based application, Windows Installer performs an integrity check by verifying:

• All key paths (files or registry entries).
• All the feature’s components where the entry point resides.
• The components of all features in parent-child relationship.

Application entry points are generally one of the following:

• COM Activation– Internal components known as COM objects, in COM applications can be shared and used by other applications. Examples of COM applications include Macromedia Flash Plug-in for a Web.
• Advertised Shortcut– These are shortcuts for an uninstalled application and generally do not have configurable properties when viewed. If the shortcut has a target type of application, rather than the .EXE application path, then the shortcut is advertised. Advertised features are also known as Install on Demand.
• File Extension Association– And association between a file extension and an application populates through the .MSI’s extension table.
• File MIME Type Association– Web browsers use MIME types and other Internet/Network related tools to identify the contents sent over the network and how to display that file. Example includes a PDF file that opens within a web browser
• Command Verb Activation– when end user right-clicks a file with a system registered extension, a context menu displays Operating System commands such as Open or Print. Executing a command this way can initiate self repair.
• Direct call to Windows Installer-An application queries Windows Installer for the state of a component or feature, causing a self-repair if necessary. By reviewing the application log files within the operating systems, event viewer and comparing the MSI’s logged installation events, you can determine which of the entry points the MSI uses. Understanding entry points lets you troubleshoot and repair packages quickly and effectively

How to Install Permanent Components, Files, Fonts and Registry Keys?

To install a file, font, or registry key so that it is not removed when the product is uninstalled, the entire component containing the file, font, or registry key must be made permanent. To make a component permanent, set msidbComponentAttributesPermanent in the Attributes column of the Component table i.e. a value of 16 should be entered in the Attributes Column. Note that the installer removes a registry key after removing the last value or sub key under the key. To prevent an empty registry key from being removed on uninstall, write a dummy value under the key you need keep, and enter + in the Name column of the Registry table.

Isolated Components

What is Isolation?

Isolation is a process by which authors of installation packages can specify that the installer copy the shared files (commonly shared DLLs) of an application into that application’s folder rather than to a shared location so that these private sets of files (DLLs) are then used only by the application. System administrators looking for an escape from DLL Hell can eliminate file versioning conflicts through application isolation.

Why is Isolation important?

Isolating the application together with its shared components in this manner has the following advantages:

• The application always uses the versions of the shared files with which it was deployed.
• Installing the application does not overwrite other versions of the shared files by other applications.
• Subsequent installations of other applications using different versions of the shared files cannot overwrite the files used by this application.

How is Isolation implemented?

Because the current implementation of COM keeps a single full path in the registry for each CLSID/Context pair, it forces all applications to use the same version of a shared DLL. To enable an application to keep a private copy of a COM server, the system loader in Windows 98 and Windows 2000 checks for the presence of a .LOCAL file in the application’s folder. If the system loader detects a .LOCAL file, it alters its search logic to prefer DLLs located in the same folder as the application. When Windows Installer version 1.1 and later versions execute the IsolateComponents action they copy the files of the component (commonly a shared DLL) specified in the Component_Shared column of the IsolatedComponent table into the same folder as the component (commonly an .exe file) specified in the Component_Application column. The installer creates a file in this directory, zero bytes in length, having the short file name of the key file for Component_Application (typically the name is the same as the application’s .exe) appended with .LOCAL. The installer uses the registration for the component in its shared location and does not write any registration information for the copy of the component in the private location.

How are Isolated Components installed?

Windows Installer (version 1.1 and later) performs the following actions during installation of an application when the package contains isolated components. Typically, Component_Shared is a DLL that is shared by Component_Application and other client executables.

• ·     Copy the files of Component_Shared into the same folder as Component_Application only if Component_Application is also being installed.
• Create a zero-byte file with the short file name of the key file of Component_Application. Locate this file in the same folder as Component_Application. Append the extension .LOCAL to this file name.
• Increment the SharedDLL refcount if the msidbComponentAttributesSharedDllRefCount bit is set in the Attributes column of the Component table.
• Register Component_Application as a client of Component_Shared and register a key path pointing to the shared location of Component_Shared.
• Install all of the resources of Component_Application as usual.

If Component_Shared or its key file is already installed on the computer do not copy files to the shared location of Component_Shared.

If Component_Shared or its key file is not yet installed on the computer:

• Copy the files of Component_Shared to the shared location.
• Process all install actions for Component_Shared.
• If Component_Shared is a COM component, register the full COM path such that the syntax [$Component] and [#FileKey] point to the shared location of Component_Shared.

How are Isolated Components reinstalled?

Windows Installer (version 1.1 and later) performs the following actions during reinstallation of an application when the package contains isolated components. Typically, Component_Shared is a DLL that is shared by Component_Application and other client executables.

• ·     Reinstall of the files of Component_Shared into the same folder as Component_Application only if Component_Application is also being reinstalled.
• Do not increment the client list of Component_Shared and do not increment the SharedDLL count.
• Recreate the zero-byte file with the short file name of the key file of Component_Application. This file must be located in the same folder as Component_Application and have the extension .LOCAL.
• Reinstall all of the resources of Component_Application as usual.

If the SharedDLL refcount for Component_Shared is more than 1, or if other products remain on the client list of Component_Shared:

• Reinstall no files to the shared location of Component_Shared.

If the SharedDLL refcount for Component_Shared equals 1 or if there are no other remaining clients of Component_Shared:

• Reinstall of the files of Component_Shared into the shared location using the File Versioning Rules.
• Process all reinstall actions for Component_Shared.
• If Component_Shared is a COM component, register the full COM path such that the installer syntaxes [$Component] and [#FileKey] point to the shared location of Component_Shared.

How are Isolated Components removed?

Windows Installer (version 1.1 and later) performs the following actions during the removal of an application when the package contains isolated components. Typically, Component_Shared is a DLL that is shared by Component_Application and other client executables.

• ·     Remove the files of Component_Shared from the folder containing Component_Application only if Component_Application is also being removed.
• If the msidbComponentAttributesSharedDllRefCount bit is set in the Component table decrement the SharedDLL refcount.
• Remove the .LOCAL zero-byte file from the folder containing Component_Application.
• Remove Component_Application from the client list of Component_Shared.
• Remove all of the resources of Component_Application as usual.

If there are other products remaining on the client list of Component_Shared:

• Remove no files from the shared location of Component_Shared.

If the SharedDLL refcount for Component_Shared is 0 after being decremented or if there are no other remaining clients of Component_Shared:

• Remove the files of Component_Shared from the shared location.
• Process all uninstall actions with respect to this component.