Written by D. G. Schneider ContactEZ.net


Free Automation Tips for MSI Installer - Windows Installer Tables - SQL Examples

For contextual information you may need to first read the topic: Setup Engineer will always need a full understanding of Microsoft Windows Installer!

Related topics: MSI Tables Overview, MSI Command Line, Create MSI Tables, MSI UAC VISTA, MSI Error Table, BootStrapper VISTA, MSP VISTA, Install MSI SDK Tools V3.1.4 Create CAB File, Build MSPs VB Script to Update PCP / MSI

This overview summarizes the MSI packaging of a product or Localized product.

Start the MSI packaging of your product(s) with a base MSI that has been approved by the Product Managers, Certification and regions. You can then use that base MSI for English and all Localized versions for the products in question.

To accomplish stability between versions, to relocate all the packaging processes on the localization group, and to eliminate TRs related to packaging localized versions of a particular product I divided the tables of the MSI in 3 categories:

1) Tables that "never" change during the life of a product.
They have been approved by Product Managers, Certification, and Regions.
These tables include all text, buttons, and controls that are displayed on each dialog (Action text, Control, ControlCondition, ControlEvent, Dialogs, Error, InstallexecuteSequence and so on )
This English base MSI is translated in all localized languages, this way all languages inherit the original English modifications if any, and force them to use what the developers (CM) have implemented.

2) Tables that change on a per version basis.
Such as bitmaps, animations, and icons. This includes mainly the Binary Table (Banner, Dialog bitmaps, VB scripts, DLLs).
By the same token if modifications have been done by the English developers (CM), the localization group inherits the changes in the base MSI.

3) Tables that change on-the-fly during each packaging process.
These tables include (Files, Components, Directories, Features, Registry, Shortcuts and the RemoveFiles, Custom Actions, Media, and so on ) and may include (LockPermission, Shortcuts, CreateFolders and so on )

We use definition files (in text format) to define CAs, added components, features, and registry keys.
You can also use REG, RGT to feed the Registry Table.

During the packaging process of the English product (by CM) or of a localized version (by the localization group) these tables are updated to reflect the delivered files, folders, shortcuts, components, registry keys and so on delivered by the language in question.
The L10n kit contains the Definition files, REG, RGT, ready for packaging.
This allows the regions to customize their delivery without breaking setup or introducing errors.
The localization group has a limited power in modifying some tables like for example the InstallexecuteSequence sequence which is part of the base MSI not the tables created on-the-fly.

Using simple VB scripts I can also automate the merging of MSMs, validation, extraction of MSM CAB files, creation of the MSI s CABs, update of a single CAB to include last minute fixes without repackaging and re-certifying all the product.

Command Line SDK examples

You can create MSI tables on the fly and automatically import them in the MSI, then create the DDF files that will in their turn create the CAB files. Some custom tools can for example import REG files into the Registry Table.

Creating IDT files on-the-fly

To create the CAB files use Microsoft MakeCab.exe and on the fly a batch process.
Tables Overveview - CAB automation examples using DDF files

To import the table use MsiDb.exe (provided with the Windows installer SDK).
To validate the packages use Orca or Msival2.exe (both are provided with the Windows installer SDK).
The .cub file darice.cub is also provided with the SDK.
This file contains the ICE (Internal Consistency Evaluators) custom actions needed by Msival2.exe to perform validation.

Examples how to run SQL commands against MSI:

WiRunSQL.vbs is script from the Microsoft Windows SDK Components for Windows Installer Developers.

To change a component attribute:
cscript WiRunSQL.vbs "Test.MSI" "UPDATE `Component` SET `Component`.`Attributes`= 264 WHERE `Component`.`Attributes`= 8"

If a Post Processing of the MSI (latest1 MSI for a patch) is a required method it can easily be automated using the following 2 SQL command line:

Cscript WiRunSQL.vbs My_Product.msi "UPDATE `File` SET `File`.`Version`='My_CompanionBinary.dll' WHERE `File`.`Version`='' AND `File`.`Component_`='NameOFComponent'"

This will set the same Companion files for all the Files of the component.
Once this is done clear the companion for the file that is the key file of the component using the following SQL command line:

Cscript WiRunSQL.vbs My_Product.msi "UPDATE `File` SET `File`.`Version`='' WHERE `File`.`Version`='My_CompanionBinary.dll' AND `File`.File`='KeyFileValueOfComponent'"

See more discussions and posts about MSI:
Replacing Non-versioned Files User Data with companion files
New tools to Import VBS JPG - Unable to place file in stream - MSIDB
MSM Validation - ATL.MSM - Documentation
Remove registry info entries for all users in system or just current owner
ARPPRODUCTICON OK for XP not for W2K Add/Remove Programs
Msidb Command Line Folder Path MSI name limitations
Do NOT Associate Extension set flag file types as No Open in Verb Table
Property for All Users Shared Documents or CA?
File Hidden Attribute after installation - Source in CAB files
260 characters limit in shortcut's targets Windows not MSI/Setup Limitation

The MsiZap utility is intended for removal of products installed with MSI that, for some reason, cannot be uninstalled.
You can log an uninstall with: msiexec /x {your product code guid} /l*v mylogfile.log

Return Home - Index