Build Configuration attributes (MSI)

Wrap the installation database in a self-extracting loader. During installation, the loader will check the required MSI version on the target system and abort with an error message if the required minimum version is not present. Otherwise it will extract the MSI database and start the installation.

Tip: This option results in the smallest MSI installation packages because it internally compresses the .msi installation database, which more than compensates for the (modest) additional size of the loader.

As Self-extractor only, but the loader will try to download and install an MSI update if the target system does not contain the minimum required version. You must enter the appropriate download URLs in the Advanced... options settings (see below).

Tip: This option results in installation packages that are only marginally larger than Self-extractor only (but still smaller than the stand-alone .msi database) and may represent the best overall option.

As Self-extractor only, but the loader includes the MSI redistributables and will install an MSI update if the target system does not contain the minimum required version. You must specify the appropriate redistributable files in the Advanced... options settings (see below).

Note: This option adds 1.5 to 3 MB to the size of the installation package, because it includes the full MSI redistributables in the package.

Enter the name for the build configuration. This is also the name of the folder in which the installer package will be created; its full path is <ProjectFolder>\Project name\Config name, which is available through the BuildFolder variable.

The value of the Config name field is available through the BuildName variable; you can use the values of these variables as <BuildFolder> and <BuildName> in any build actions.

Note: If you select Per language for the Languages attribute (below), then the configuration name is modified internally during the build process. Each language's installation package is stored in a separate folder called Config name-langID, where langID is the 4-digit hexadecimal language identifier for the build language. The BuildFolder and BuildName variables reflect this.

Enter the name of the installation package; for a Windows Installer package, this should have either an .msi extension (if no bootstrapper is included; see Bootstrap below) or an .exe extension (with bootstrapper).

The installation package will be created as <ProjectFolder>\Project name\Config name\Installer name and is available through the BuildTarget variable. You can use the value of this variables as <BuildTarget> in any build actions.

Tip: To retrieve portions of the installer's file name, you can use expressions such as <$fbase(<BuildTarget>)> and <$fname(<BuildTarget>)>.

Check this box to use a custom icon as the product icon for the installation package; clear it to use the default MSI icon. If you check this box, you can select the desired icon file by clicking on ... (browse). To revert to the default icon, click X.

The custom or default icon is used when your product is registered for the Add/Remove Programs control panel applet. For plain MSI packages (Bootstrap option set to None), it is not the icon of the package itself; because of its .msi extension, the package will always be displayed with the icon that is associated with .msi files. For packages that include a bootstrap loader, the icon will also be used for the package itself.

Check this box to protect the installation package with a password, and either enter the desired password or click Generate to generate a pseudo-random password. If the installer is protected with a password, the embedded .msi package is encrypted and can only be opened after the correct password is entered during installation.

Note: This option is only available and only applies if the installation package contains a bootstrap loader. This is the case if you select anything but None in the Bootstrap field (see below).

Note: The password protects the initial installation of your product only. Once installed, anyone with access to the target system can change or remove your product.

Enter the default command line arguments for the installer. Any arguments that you enter here are stored in the installation package and will be used as if they were command line arguments when the installation package is started.

Note: This option is only available and only applies if the installation package contains a bootstrap loader. This is the case if you select anything but None in the Bootstrap field (see below).

During installation, the installer parses its command line arguments in the following order:

1. Anything that you enter in Default args;
2. Any piggy-backed command line arguments;
3. Any arguments entered on the actual command line that started the installer.

Because of the way the installer processes its command line arguments, later arguments may override earlier ones. As a result, the Default args may be overridden by the piggy-backed arguments, and they both may be overridden by arguments on the actual command line. This enables you, for example, to configure the installer for silent mode by default (by setting Default args to /qb), but still allow the user to run it interactively by specifying /qf on the command line.

Note 1: You must use "quotes" in the Default args field just as you would on a normal command line to enclose arguments that contain spaces. Unquoted spaces are used as separators between arguments.

Note 2: If the Default args field contains symbolic references such as <ProgramFilesFolder>, then you must enclose them in `backticks` to prevent expansion at build time. For example, this:

/q "INSTALLDIR=<ProgramFilesFolder>\MyApp"

...will be expanded when the installer is built, which is probably not what you intend because it resolves <ProgramFilesFolder> on your own development system instead of on the target system. Instead, use extra `backticks` like so:

/q "INSTALLDIR=`<ProgramFilesFolder>\MyApp`"

This will pass the string <ProgramFilesFolder>\MyApp literally to the installer, which in turn will resolve it at installation time as intended. (Obviously, if you have any symbolic references that must be resolved at build time, such as build-time variables like <BuildDate>, then you should not use the backticks.)

Note 3: The Default args and piggy-backed command line arguments are only present in the installation package and are used when the original installation package starts. During subsequent Modify or Repair runs or the removal of your product, they are not present and not used.

Enter a list of variables to set when the configuration is being built. The list must consist of name=value pairs that are separated by semicolons, for example IncludeMe=1;IncludeYou=0. You can use build variables to embed configuration-specific variable values anywhere in the installer, or to use as part of build conditions in components or features.

The variables are set just before the configuration is built and removed immediately afterwards. Some important notes about the build variables:

• If the name portion refers to an existing product variable, that variable's value is replaced temporarily; it is restored once the configuration is built. Existing read-only variables are left unchanged.
• If the name portion does not refer to an existing variable, a new variable is created for the duration of the configuration's build process and is removed afterwards.
• The value portion is used to set the Value attribute of the product variable; you cannot set the Value (NT) attribute here.
• The value portion cannot be localized and will remove any localization in the name variable for the duration of the build.
• By default, newly created build variables are saved in the installer's database. If this is not desired, you must explicitly create the name variable on the Product Variables project page and set or clear its Save for MSI attribute as required.

Except as noted above, build variables behave as regular variables for the duration of the build process and in the installer. Among other things, this means that:

• You can use symbolic expressions for the value portion;
• You can use them anywhere in the project (and installer) where you can use variables, including in conditional expressions;
• You can use them in build conditions for components and features.

Select the desired language build mode from the drop-down list. The following choices are available:

If you select Per language, each installation package is stored in a separate folder; see Config name above for details.

Regardless of the language build mode, an installation package will only contain the project contents that are relevant for the package's language. This affects the following:

• If a component is marked for one or more languages, that component and the objects that it contains are only included in the package if the build language is among the component's languages. (Components that are marked Install for all languages are always included.)
• For any localizable attributes and localized action texts, error messages, and strings, only the translation for the build language is included in the package.
• Dialog box translations are included only for the build languages.

Select the desired minimum MSI version from the drop-down list. The MSI version determines which Windows Installer features are available and is used during preflight checks. It is also stored in the .msi installation package.

For packages that include a bootstrap loader (Bootstrap option set to anything but None), the loader will automatically check the installed MSI version on the target system and will either try to update the MSI version or refuse to install if the minimum version is not available. See the Installer bootstrapping section above for an explanation of the available options.

Check this box to treat any preflight warning messages as errors; clear it to treat them as mere warnings. If you check this option, any preflight warnings will terminate the build process; this will be flagged by an additional BLD:E0005 message.

Because preflight warnings indicate issues that might cause the installation to fail, you should attempt to build your installers without preflight warnings. This option helps you to enforce that.

Check this box to generate a build manifest during the build process; clear it to build without generating a manifest. The build manifest is an XML file that contains a detailed list of all files that were included in the installation package; it can be used as part of an audit trail for your product's release.

If generated, the build manifest is stored as <ProjectFolder>\Project name\<BuildName>.Manifest.<BuildDayNo>.xml, i.e., with the name of the build configuration (modified for per-language packages, if necessary) and the serial number of the day it was built.

Check this box to attach a digital signature (Authenticode) to the installation package; clear it to create an unsigned package. Using this option involves two prerequisites:

1. You must obtain and configure the Microsoft SignCode tool in the Preferences - SignCode dialog box. You can open that dialog box by choosing Edit > Preferences from the main menu.
2. You also need a Software Publishing Certificate (SPC), which you can create yourself using Microsoft's MakeCert tool or obtain from a Certificate Authority (CA) such as Verisign or Thawte. Certificates issued by a certificate authority have the advantage that they are countersigned by a trusted third-party, which allows the recipients of your installation package to verify your identity if they check the signature.

See Digital Signatures for background information about SignCode and digital signatures.

Click this button to open the Select Installation Platforms dialog box, which allows you to specify the Windows versions for the package.

The configuration's build platforms affect which project contents are included in the installation package. In particular, if a component is marked for some platforms but not for all, that component and its contents will only be included in the package if its platforms overlap with the configuration's build platforms. The System Requirements are also intersected with the platforms that you specify, and the installer will refuse to install on any of the non-build platforms.

Tip: If you want to build separate installation packages for different Windows versions, for example one for Windows 95, 98 and Me, and another for Windows NT4, 2000, XP and later, you can do so as follows:

1. Create two MSI Configurations (or create one first, set its options, then use Copy and Paste to create a duplicate).
2. Set the Config name attribute of the first configuration to, for example, Install-9x and the second to Install-NT. It is important to choose a unique Config name for each configuration, or they will overwrite each other.
3. In the first configuration, check the Windows 95, 98 and Me platforms and clear the rest; in the second configuration, clear Windows 95, 98 and Me and check the rest.

You can now build both versions of the installer from a single Tarma ExpertInstall project. Obviously, you can create further configurations as needed.