Property Table
Standard details such as the name of the application, it’s manufacturer and the install-type that should be performed are all contained within the Property table of the MSI. You don’t always have to create a separate Transform for your MSI – certain values within the MSI can be altered at install time from the command line.
Anything in Uppercase is a “Public Property” and may be directly altered from the command line. Consider the following installation command:
Msiexec / i c:\test.msi OWNER=”Me” /qb
This would force an install (/i) of the MSI found at C:\test.msi. the /qb states that it’s a quiet install with bare dialogs. /qn would give no dialogs. In the example, the Public Property OWNER is being set to “Me”.
When you use variables within your MSI, you normally have to declare them as Public Properties.
Common Property Additions
ALLUSERS=1
When this is added to the Property table, it ensures that the shortcuts are available to all users, not just the User Account that installed the MSI.
INSTALLLEVEL=32767
This ensures that all optional features within a Package are installed. Typically, an Install level of 3 installs a “Typical” configuration, 1 is the same as minimal. When an install level is set, every feature with an install level the same or less that the number specified in the property table will be installed.
ROOTDRIVE=C:\
The ROOTDRIVE property forces the package to install to a particular drive. By default, the MSI package installs to the local drive with most free space.
REBOOT=ReallySuppress
The REBOOT property can be used to stop Windows Installer from rebooting the machine at the end of the installation of the product. As there is additional auditing taking place, we do not want the machine to be rebooted immediately after the MSI installation. Packages are also designed to be distributed during the day and having machines forcibly rebooted while staff members have open work is dangerous.
SOURCEPATH=<NetworkPath>\<Package Subdirectory>
Sourcepath works the same as the old DOS Path statement. This property represents a list of semicolon separated entries that may be searched to find an original copy of the MSI and associated files. When a package is installed onto a workstation, the original location it was installed.
SelfReg Table
Later in this booklet the registration of COM dll’s is discussed in detail. The traditional method for registration was by using the Microsoft utility Regsvr32.exe.
The SelfReg table is a legacy concept for allowing registration in the same way that RegSvr32.exe would act. For multiple reasons use of the SelfReg table is discouraged, registration information should be extracted and placed in appropriate advertising tables.
Feature Table & FeatureComponents Table
With extremely complex packages, a single application can be broken into a number of optional features. A good example of Features is the installer for Microsoft Office which essentially allows a number of applications to be installed from one package.
A single package can contain many features. The determinant as to whether a feature will be installed is the numeric value assigned to the Install Level.
The Property Table will allocate a default INSTALLLEVEL value, in the case of Office 2003 that value is “75”. All entries in the feature table with a value equal to or less than 75 will be installed.
Due to the rules regarding the repair of MSI’s, many organisations insist that internal packagers produce single-feature MSI packages.
FeatureComponents Table
The FeatureComponent table simply lists which features a component belongs to.
Directory Table
The Directory Table links all directories that are referenced with the MSI. Every entry has three references within the MSI directory table. “Directory_” is a unique reference within the MSI for referring to a particular directory. That directory will be listed with a “Directory_Parent” that has it's own unique identifier. The actual name that is assigned to the directory is normally contained in the “DefaultDir” table entry.
Directory_Parent Notes
A number of entries within the Directory_Parent column will be the TARGETDIR entry. Targetdir is used to indicate that the directory will be on the machine being installed to as a Target Directory. The actual physical location of these directories is determined at install time, In these situations, the directory name that is a standard directory with a name that the Windows Installer service can resolve when installed on a target machine.
Eg.
DIRECTORY DIRECTORY_PARENT DEFAULTDIR
ProgramFilesFolder TARGETDIR .:ProgramF|Program Files
The preceding entry from the Directory Table will reference an internal directory name of ProgramFilesFolder when referring a directory called ProgramFilesFolder.
A list of predefined folders used by Windows Installer is available with the Windows Installer SDK.
DefaultDir Notes
Default directory names are displayed in both 8x3 notation and Long Filename notation. Both names are displayed separated by a vertical bar character.
Actual directory locations are resolved at install time where the internal directory reference will be resolved to a physical location on the Target machine. A point to be conscious of is that directory references are actually properties. Custom Actions (type 51 in the CustomAction Table) can actually be used to specify a physical directory path for an internal directory reference.
Shortcut Table
The shortcut table is relatively self descriptive. When an MSI packaged application is run, the advertised shortcut forces Windows Installer to check the integrity of the application before the service calls the executable that’s been specified. Advertised shortcuts “Target” a feature, not a specific executable in the way that traditional shortcuts work.
A Packager will commonly need to convert a traditional shortcut to an advertised shortcut by altering the Target field within the shortcut table.
The Name field within the shortcut table is written to show 8x3 and Long File Name notations separate by a Pipe symbol such as:
Access12|Microsoft Office Access 2007
TypeLib Table
The Typlib table works the same way that the Self-Reg table does, it performs a Registration call against a file (the key file for a particular component).
Quoted from Microsoft:
Installation package authors are strongly advised against using the TypeLib table. Instead, they should register type libraries by using the Registry table. Reasons for avoiding self registration include:
If an installation using the TypeLib table fails and must be rolled back, the rollback may not restore the computer to the same state that existed prior to the rollback. Type libraries registered prior to rollback may not be registered after rollback.
http://msdn2.microsoft.com/en-us/library/aa372092.aspx
This may also be viewed under Windows Installer best practice guidelines:
Do not use the SelfReg and TypeLib tables!
Installation package authors are strongly advised against using self-registration and the SelfReg table. Instead they should register modules by authoring one or more of the tables in the Registry Tables Group. Many of the benefits of the Windows Installer are lost with self-registration because self-registration routines tend to hide critical configuration information. For a list of the reasons for avoiding self-registration see SelfReg table.
Installation package authors are strongly advised against using the TypeLib table. Instead of using the TypeLib table, register type libraries by using Registry table. If an installation using the TypeLib table fails and must be rolled back, the rollback may not restore the computer to the same state that existed prior to the rollback.
http://msdn2.microsoft.com/en-us/library/bb204770.aspx
InstallExecuteSequence Table
The InstallExecuteSequence table is the main table used for controlling what takes place during an install. MSI’s have other sequence tables, primarily for dealing with different types of user interface. The InstallExecuteSequence table is unique in the fact that it will always run during any installation whereas other sequence tables are not initiated unless a GUI is running on the target workstation.
Windows Installer processes actions from lowest to highest sequential numbers.
Many of the Actions will represent standard actions such as writing INI files, or installing or removing files. Other will be specific only to that package. If Custom Actions are authored, if a Custom Action is to run, it will be written as a line item with it’s own sequence.
InstallExecute Actions may often hold Conditions. A common condition on Vendor based installers is ISSETUPDRIVEN that represents a property that’s set when an Installshield executable has been used to launch the installation.
The insertion of any new Custom Actions should normally take place before the “InstallFinalize” action (which is normally right toward the very bottom of the list).
- Log in to post comments