An MSI is a Windows Installer Database that can be installed by the Windows Installer subsystem on a Microsoft machine. As it is a database instead of a traditional script based install, an MSI has the ability to maintain the “installed” product.
Its advantages over an EXE or script based installation are:
1. Self-repair (healing) of corrupted applications
2. Rollback support for un-install of failed installations
3. Logic to ensure old files never overwrite newer versions (downgrade)
4. A background, silent method for reliable application installations.
5. Automatic reporting capabilities on the successful install of applications.
6. Automatic logging of faults with application installations.
MSI databases consist of standard tables that can be “Transformed” by overlaying a separate table… these overlays are known as Transforms or MST’s. An MST can completely change any of the database fields within the original MSI so destination directories, registered owner and selected features may all be customised.
Components
The basic building block of an MSI is the component. Windows Installer doesn’t just install components but it manages them. It will track how many applications use a component and prevent them from being removed it it’s shared and used by other applications. Windows Installer also performs validation checks on the components every time an application is used. When Windows Installer heals an application it’s because it is checking each of the components to see if they appear damaged or altered.
The component is the smallest divisible unit when creating an MSI. It may contain a combination of files, registry keys or shortcuts. To adhere to Microsoft’s rules for creating components, all resources (files, shortcuts, registry keys) that reference each other directly should be grouped within a single component. That means that registry keys that point to doe within a particular DLL (known as COM entries) should be grouped in the same component as that particular file.
There can be instances when a component has more than one file. This is fine as long as none of the files contain COM entries. As a general rule, every DLL,.EXE or OCX should reside in it’s own component.
Features
The FeatureComponent table lists the components assigned to a particular feature.
Think of a feature as a grouping of components that can be selected or deselected for installation. by the installing user. If you are installing an application such a Microsoft Office, every option that you can select or deselect represents a feature.
Features are nested as well. In the graphic below, “Help for Wordperfect Users” is a nested feature of “Help” whereas, “Help” is a nested feature of “Microsoft Office Word”
Every MSI must have at least one feature. Although it’s easy to think of a feature as something selectable at install time, there can actually be hidden features who have a behaviour that can’t be controlled at all.
Windows Installer and Self Repair
When an MSI based application starts, the primary executable isn’t actually run first. This is the secret of how MSI files use self-repair. The shortcuts for an MSI are known as Advertised shortcuts and they don’t point to an executable but instead point to GUID’s for an installed MSI. When you run an Advertised shortcut it calls the Windows Installer subsystem which will eventually call the executable for you. Before it calls the executable it checks to make sure all of the required files and Registry entries are present before starting the application.
Every component within an MSI has a “key” which is checked by the subsystem and verified as present before the application starts. The Window below shows that the “Key” for the comct332.ocx component is the file “comct332.ocx”. It’s important to remember that you choose where a component is installed to – not a file. Although a component may contain a number of files, they all must install to the same subdirectory. You might install a number of files with one component if they were likely to be changed and you didn’t want the altered files all repaired when the MSI started… as long as the file is a “key”, any changes will be automatically reverted when the application is started.
A component will try and group everything together for a particular file. If that file has COM entries, they will be associated with the same component, same as Registry entries.
If the key-file or registry entry is removed or altered, the whole component will be forced back again at application start-up.
- Log in to post comments