Jason Ginchereau is responsible for the creation of the Windows Deployment Toolkit which is incorporated into WIX. The toolkit provides extensions for PowerShell to access Windows Installer databases with managed code. Current releases can be downloaded from: http://wixtoolset.org/releases/
Resolving file paths within MSI databases can be a complex piece of coding. It involves linking files to components and components to the directory table. The complexity is due to the flexibility of Windows Installer in determining how directory table entries are referenced.
Independent of the specifics of MSI technology, medium to large sized organisations have their own requirements for application packaging and software management.This section discusses some of the broader requirements of software management in an enterprise environment.
Windows Installer Upgrades
As a Windows Installer installation routine is a database technology, upgrading in installed version of a product (or patching that product) is theoretically simple and reliable. The technology has its own rules regarding upgrades which must be follows for the upgrade to occur.
MSI Installations run in two halves. The first half is the “Immediate Execution Mode” where object references are calculated to construct a temporary précis of where the files and registry keys will be installed, along with evaluating variables and statements used within the MSI. Once the précis has been created, the installer effectively has a specific install script for the target machine. The second stage or “Deferred Execution Mode” is when the installation script is being acted upon. During this stage, the earlier MSI properties and variables are no necessary or
Sometimes, files need to be copied to a users’ Home Drive when they use and application. You must not hard code an MSI to expect network drives and you have problems expecting a particular drive mapping to be present when an MSI is installed. Mostly, software distribution systems don’t need Home Drive mappings so trying to get a logical solution to this problem requires some inventiveness.
Using Custom Actions with Active Setup is one way to get around all of the profile related tasks you may wish to perform.
Darwin Descriptors
A Darwin Descriptor tells Windows about the package and component key-path it is supposed to check. We have seen in the preceding sections that the Darwin Descriptor below (found in Advertised Shortcuts and the Registry) is somehow associated with Microsoft Word.
']gAVn-}f(ZXfeAR6.jiWORDFiles>P`os,1@SW=P7v6GPl]Xh
A hint is that the Darwin Descriptor is actually comprised of three parts.
Based on same structure as the MSI-Edit scripts (also available from the menu on the left), this set of scripts automates the checking of Windows Installer packages and produces an Infopath based XML report.
The Windows Installer (MSI) checking is modular and allows technical staff members the ability to create their own checks relatively easily.
MSIEdit is a set of modular VB scripts that I used to use for quickly editing Windows Installer packages.
The MSIEdit Launcher is used to select the Windows Installer (MSI) file that requires a transform.
All of the scripts within the directory are called to correct issues with the MSI.
This section is about understanding Windows Installer technology and what makes up MSI packages.