Everything About Components [Wise Package Studio]
A component is the smallest installation unit for the Windows Installer Service. It is a collection of installable resources or just resources. A resource is a file, registry entry, shortcut, type library or the like.
Components are commonly hidden from the user. Whenever a user selects a feature for installation the Windows Installer Service determines which components are required.
When a component is installed everything that comprises the component is installed and likewise when a component is uninstalled so too is everything that comprised it.
The Windows Installer Service identifies a component by its unique component GUID. The Windows Installer looks for a component’s keypath in order to check whether the component is installed correctly.
- A keypath is normally one of the files that comprises the component but can also be one of the registry entries associated with the component.
- The keypath defines the location of the component on the system. If the keypath for a component is missing, the Windows Installer treats it as broken and tries to take the necessary steps to repair it.
Because components are commonly shared by more than one application or product they must be correctly organized in your application. There are a number of strict rules that must be followed when creating the components. Following these rules ensures that the uninstallation of an application does not break any other application that is still on the system. See the following list.
Some Rules of Organizing Applications into Components
Proper ‘componentization’ guarantees that all resources that define a component are removed with no orphaned resources left behind. These rules are listed below:
- All files in a component must be installed into the same directory.
- There can be no sub-directory.
- No one file can be included in more than one component (NOTE: this can happen only if file is going to different locations). Change the file name if the information must go into another component.
- Every component must have only one KeyPath – either a file or registry key or the folder in which the component resides. All versioned files .exe, .dll, .ocx, files and those that are the targets of advertisable shortcuts, must be the KeyPath of a component ( ie only be one per component ).
- Every .EXE, .DLL, .OCX, .HLP and .CHM file should be in its own component and these files should be the keypath for the component.
- Recommended: A registry entry, shortcut, or other resource, is not included in more that one component. (This is not policed and does not show up error).
- There can be only one file that is a target for a Start Menu or desktop shortcut in each component. This means that every file that serves as the target of a shortcut has to be in it’s own component.
You can think of the Windows Installer Service both as a Component Management System and as a Setup Service. When talking about the management of components we need to discuss features, since features are basically collections of components.
Common Component Errors
- Component has an empty key path but contains files, registry entries, or ODBC data sources. (component highlighted in red)
- Component has more that one executable. (.EXE,.DLL,.OCX)
- A shortcut is assigned to the component, but the key path for the shortcut is not a file.
- Registry keys are created in HKEY_CURRENT_USER, but the key path is not for a registry key in HKEY_CURRENT_USER
What are Isolated Components
The new functionality of Windows 2000 and Windows 98, which permits an application to have a private copy of a COM component, has been implemented in the system loader. The system loader looks for a file with the extension local in the application folder and if it finds this file it alters its search logic to prefer DLL’s that are located in the same folder as the application.
How do you use Isolated Components
Sharing components among various applications has been one of the major benefits of Microsoft Windows. However, the ever-increasing number of applications requiring special versions of these shared components has created a condition known as “DLL Hell”.
In this situation (DLL Hell), different applications need different versions of the same component. The original concept of sharing components was that each component would be completely compatible with previous versions and thus a newer version of a component would never cause an application dependent on an earlier version to fail.
In reality, sadly this is not often the case as there are many instances of a newer component version breaking an application that was previously successful using the earlier version.
Windows XP/ 2000 and Windows 98 second edition have a new functionality that allows different versions of the same component to reside in memory at the same time.
This enables what is called “side-by-side sharing” and is a huge step towards eliminating DLL Hell. The concept of side-by-side DLL components occurs when one version of the component runs in one process while the other component version runs in another process. This new approach to component sharing applies to both COM DLL’s and WIN32DLL’s.
Isolate Components Action
How it works
The Isolate Components action installs a copy of a component (commonly a shared DLL) into a private location for use by a specific application (typically an EXE).
Why do this?
This isolates the application from other copies of the component that may be installed to a shared location on the computer (like the systems folder).
How does the action operate?
The action refers to each record of the Isolated Component Table (located in the Setup Editor - Tables tab) and associates the files of the components listed in the Component-Shared column with the components listed in the Component-Application column. The Installer installs the Component-Shared files into the same directory as Component-Application. The installer generates a file in this directory, zero bytes in length, having the short filename of the key file for component-application (usually this is the same name as the EXE) appended with '.local'.
Component sharing
Shared Components are components which will be used by other applications and contain files with .DLL, .OCX, .TLB, .OLB, .EXE extensions and any relevant support files (.HLP) or registry information. They are generally files which have been developed by Microsoft or other third parties to provide functionality which is used by several applications.
For Example:
Microsoft’s MSJET35.dll is a file that is used by several applications to connect up to an Access Database. Existing installers manage shared files by maintaining a shared reference count (refcount) for each shared file in the system registry and by not removing a file until that refcount reaches zero. Since Windows Installer maintains a refcount at the component level these resources are more efficiently managed.
EXAMPLE:
Select Component – right click
Component Details Dialog – check “Always increment shared Dll count”
The file has to be .dll and Attributes = 8 means reference (16 means permanent)
Thanks,
Eshwar