Secure Transforms

Secure transforms are simply transforms that are kept in a place where the user does not have write access. This might be the root of the location where an administrative installation of the package has been performed (Secure-at-Source transforms). It might also be a share or full path elsewhere on the network (Secure-Full-Path transforms).


You can indicate that the Installer should use secure transforms by special
characters in the TRANSFORMS property (discussed in the next section) or by setting the TransformsSecure or TransformsAtSource properties within the Installer database to 1.


When the Installer uses a secure transform, it will cache a copy of that transform locally. If the local copy becomes lost or damaged, it will restore it only from the original location.

Custom Action Types

This table also shows how you should interpret the Source and Target columns for each type of custom action

Type	Description	Source	Target
1	.dll stored in a binary Stream	Key to a row in the Binary table	Name of the .dll entry point.
2	.exe stored in a binary Stream	Key to a row in the Binary table	Command-line string used to launch the .exe.
5	JScript in a binary Stream	Key to a row in the Binary table	Name of the JScript function to call.
6	VBScript in a binary Stream	Key to a row in the Binary table	Name of the VBScript function to call
7	Installation of a package nested inside of the first package	Name of the substorage containing database of nested application.	Properties settings string.
17	.dll installed as part of a product	Key to a row in the File Table	Name of the .dll entry point.
18	.exe installed as part of a product	Key to a row in the File Table	Command-line string used to launch the .exe.
19	Displays a specified error message and returns failure, terminating the installation	Blank	Formatted text string. The literal message or an index into the Error table.
21	JScript file installed as part of a product	Key to a row in the File Table	Name of the JScript function to call.
22	VBScript file installed as part of a product	Key to a row in the File Table	Name of the VBScript function to call.
23	Installation of a package that resides in the first application’s source tree	Path of nested package specified relative to the root of the source location	Properties settings String
34	EXE in a known Directory	Key to a row in the Directory table	Name of the executable file and any options. Use quotes to surround long file names.
35	Directory set via formatted text	Key to the Directory Table	Formatted text string that will be set as the directory path when this action is executed.
37	JScript text	Null	A string of JScript code to execute.
38	VBScript text	Null	A string of VBScript code to execute.
39	Installation of an application that is advertised or already installed	Product Code for the application to install	Properties settings String
50	.exe named by a Property	Property name or key to a row in the Property table	Command-line string used to launch the .exe.
51	Property set via formatted text	Property name or key to the Property table	Formatted text string that will be stored in the property when this action is executed.
53	JScript text stored in a Property	Property name or key to a row in the Property table	Name of the JScript function to call.
54	VBScript text stored in a property	Property name or key to a row in the Property table	Name of the VBScript function to call.

File Versioning Rules

Suppose your installation source contains a file named XXXXX.dll, and the
Installer finds a copy of XXXXX.dll already on the user’s hard drive. How
would you decide whether to overwrite the existing copy on the hard drive with a new copy from the source media? Your first idea might be to compare file dates; you would then overwrite if the copy in the source media was newer. A more sophisticated version of this technique is to look at the internal file version information, and overwrite if the copy in the source media has a higher version.

The Windows Installer uses an even more complex algorithm when deciding
whether to keep an existing file or install a new copy. It takes into account not just the file dates and the version, but the languages involved as well. Here’s the set of rules the Windows Installer follows:

Highest version wins: All other things being equal, the file with the highest
version number wins, whether that’s the file on the hard drive or the file in the
source media.

Any version is higher than no version at all: If the copy in the source media
contains version information, and the copy on the hard drive has no version
information, Windows Installer chooses the one with the version information.

Favor the new language: All other things being equal, if the file being
installed is localized for a different language than the file on the computer, Windows Installer uses the copy with the language that matches the product being installed.

Meet the product’s needs for multiple languages: If both copies support
multiple languages, Windows Installer ignores the common languages and uses the copy that supports the most languages out of the set of languages that the product uses.

Keep the maximum number of languages: If the copies differ in the number
of languages they support and both support all the languages that the product
needs, Windows Installer keeps the copy that supports the most languages.

Treat non-versioned files as user data: If there is no version information for
either copy, Windows Installer compares the file creation date and the last modification date for the file on the computer. If the modification date is later than the creation date, Windows Installer assumes this file has been customized by the user and does not overwrite it. Otherwise, it installs a new copy.

Companion files go along with the versioned file: It’s possible to mark a
file within the Installer database that does not include version information as a companion file to a file that does include version information. In this case, the companion file is installed if the other file is installed. There is one exception to this rule, though. If the companion file is not present on the target machine, it’s installed even if the versioned file is not installed.

It’s a good thing that these rules match the way most developers would like
installations to behave because there’s no way for you to change them. Of course, you can pervert their intention if you feel you must. One way to guarantee that a file from the source media is installed is to set its version string in the File table to 65535.65535.65535.65535, which is the maximum version number that the Windows Installer accommodates. Beware, though: if you do this, you’ll never be able to use the Windows Installer to replace that copy of the file with a new version.

INSTALLDIR vs. TARGETDIR

INSTALLDIR represents the main product installation directory 


TARGETDIR represents the installation directory for an administrative Windows Installer–based installation (when the user runs MsiExec.exe with
the /a command-line switch)