Easy Setup

After introducing the Msi in Article 1 and providing some background to its “roll-back” action in Article 2, I would like now to continue and clarify some of its basic concepts.
As you have probably understood by now, the Msi platform registers each and every action during the installation process, and enables its retrieval / “roll-back”. The Msi logs these actions in two separate locations:

• c:\WINDOWS\Installer – stores a transformed copy of the original Msi, according to the actions performed during the installation process. This copy is later used, for example, to enable “Remove/Repair” and other maintenance sequences.
   
• Registry Key – stores the GUIDs, as well as information about the features and components installed by each product and the relationship between them.

 
Let’s shed some light on the terms “Feature” and “Component” of a product:
   
Product-Feature relationship as wall as Feature-Component relationship are of a “one-to-many” type. It means that each Binary (files / registry / services / fonts / shortcuts / file types / COM registration) Management (install / uninstall / repair) Product includes at least one Feature that has at least one Component.
 
The Feature manages the Components that are installed. The Features are the “logical” elements of the Msi and are stored according to their names (unlike the Components, which are stored according to their GUID). Note: For that reason, you are not required to determine the management condition for each Component in the Msi you create. Instead, you can determine the condition for the Feature containing the components only.
 
A Component, on the other hand, is the “atomic” unit of the Msi. When you work with binary management, your actions are associated with Components. There is no limit to the extent to which a Component uses binary management. It can also manage itself – whether to be installed or not.
 
Out of the many attributes of Components, I chose to focus on those which are most relevant for Msi design:

• Destination: The location of the Components’ resources installation. Note that the destination of a Component has preference over the destination of the Feature under which it is located.
     
• Destination Permissions: Allows you to set the RW permissions for folders created by the Component.
   
• GUID: Each and every Component is defined by a universal and unique GUID. Don’t try to set the same GUID for two different Components.
   
• Shared: Set this property to true for Components which are allowed to be overwritten by other products. A new counter shall be created under: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDlls with the installed file location.
   
• Permanent: When you don’t want to allow the associated resources of certain Components to be uninstalled, set the “Permanent” property to true for these Components.
   
• 64 bit Component: set this property to true for Components to be installed on 64 bit machines. You should indicate in the “Template Summary” Property the Operating System (OS) type supported by this installation (32 or 64 bit). Although it is possible to bypass this limitation and allow a single Msi to support both Operating Systems, such a move might incur future complications and I highly recommend against it.
   
• KeyPath: You can mark a certain file or registry key as a “KeyPath” within the attributes of an installed Component. The Msi uses the attributes to determine the Component’s need to “repair/upgrade” during the various maintenance modes. It should be noted that even if only the “KeyPath” resource needs to be maintained in a certain Component, the Msi will still execute the maintenance mode for all its binary management tasks.  This rule applies also to Components missing the “KeyPath” resource.

If you want to get the most out of your Msi, you must follow a strict set of rules. I invite you to read the 4th Article in this series, in which I will specify the steps you need to take for the design of an effective and solid Msi.