Build Settings

Build settings control how your setups are built. These settings allow for changing the deployment type (uncompressed, compressed, web), among other things. To access your build settings:

• Press SHIFT+CTRL+F11.
• On the Project tab, in the Manage group, click Project Settings.
• On the MSIcode tab, in the Compile group, click Project Settings.

Build Node

This page lets you configure your deployment type. The various kinds of deployment types, along with their uses, are explained below. Pick the one that is most suitable for your target audience.

Uncompressed Directory Layout

Your setup is contained in multiple files spanning several layers of multiple nested folders. Each file is uncompressed and immediately available, minimizing installation time, since files will not be uncompressed from an archive or downloaded before installation.

This type of deployment is ideal for CD/DVD media where disk space is not a concern and multiple files/folders can be stored. It also works well on network drives.

This build type does not cache its setup sources by default.

Compressed Single Self-Installing EXE

Your setup is contained inside a single self extracting file. This file, when run, will first extract its contents to a temporary folder, and then start the main setup program. In essence, when executed, the compressed layout converts into the uncompressed layout.

This type of deployment is suitable for Internet distribution, since the entire setup is contained inside a single file.

This build type does not cache its setup sources by default.

Compressed Web-Based EXE

Your setup is comprised of a self extracting file, which similarly to the compressed layout, extracts its contents and starts the main setup; as well as web media blocks, which are defined in your setup script and are downloaded as required from the web.

This type of deployment is ideal for Internet distribution. Setup will download only the web media blocks which are required on the target system. This saves download times and bandwidth since users will not waste either downloading portions of your application and/or its runtimes which they do not need.

This build type does cache its setup sources by default.

Use Pre-Compiled Application Runtimes

This option accelerates building Compressed Web-Based EXE setups.

Build MSI outputs instead of EXE outputs

This option automatically wraps Compressed Single Self-Installing EXE or Compressed Web-Based EXE setups inside external Group Policy MSI wrappers.

Please note that in order to use Unit Testing with virtual machines, you must enable this option within the InstallAware IDE on this dialog box, instead of manually using the external Group Policy Wizard. Setups wrapped externally using the Group Policy Wizard are not supported for virtual machine Unit Testing.

Always Cache Setup Sources (enables easy patching)

This three-state check-box lets you control setup source caching. When the box is filled, the default source caching option (as described above for each build type) is in effect. When cleared, setup sources are never cached. When checked, setup sources are always cached.

Caching setup sources consumes additional disk space on the target system. This loss of space is partially offset by the usage of NTFS compression if the target file system is NTFS. The advantage of caching setup sources is that when a patch is being applied, or when setup is being re-run in maintenance mode without the original installation file or media, setup will never prompt for the original setup sources - patching, or repairing/adding new application features automatically.

When setup sources are not cached, no disk space is wasted on the target system for a copy of the installation files. However, running setup in maintenance mode (other than uninstalling the application) will require access to original setup sources, as will patching setup.

Debug Build (allows setups to be debugged in IDE)

If you will be debugging your setup inside the IDE, also ensure the Debug Build checkbox on this page is checked. Note that you cannot run debug builds outside of the IDE.

Authenticode Node

This page lets you digitally sign your packages with authenticode. Provide the paths to your certificate and key files to enable code signing. The default value for the time stamp URL is http://time.certum.pl.

Sign All Executables (EXE, DLL, OCX, SYS, CPL, DRV, SCR)

This is a three-state check-box which has effect only if the main Sign the package with Authenticode check-box is checked.

When this check-box contains a check mark, all mentioned file types included in your setup through the Install Files, Install Service, Install Assembly, and Install ODBC Driver commands will be automatically code signed.

When this check-box contains a square (does not contain a check mark but is not empty either), files will be code signed only if a signature does not already exist.

When this check-box is clear (does not contain a check mark or a square), no automatic code signing occurs for files included in your setup.

Compression Node

Compression

This slider lets you configure the strength of the compression employed while creating your setups. Move the slider and choose a setting that is optimal for your system. You may wish to set the slider to choose no compression while testing and debugging your setup, as at maximum compression, builds take a long time to complete.

Use 256 bit AES Encryption

You may encrypt your compressed setups with strong 256 bit AES encryption technology. The entire setup payload, including the setup and data files, will be encrypted (even if the compression slider is set to use no compression).

Compiler Node

This page provides compiler optimization switches which improve the runtime Windows Installer performance of your setups, as well as the time it takes InstallAware to build your setups. The default settings on this page reflect the safest settings to use (all compiler optimizations disabled), providing maximum compatibility for:

• ICE Validation (required for the Designed for Windows logo program),
• Patching,
• Advertising (self-healing and installation-on-demand),
• Web Media Block sharing (sharing/re-using web media blocks across different setup projects, or even different rebuilds of the same project).

You may selectively enable some compiler optimizations to improve the build speed of your setups, as well as their runtime Windows Installer performance. Please note that these optimizations are best turned off for smaller setup projects - since smaller setup projects will not experience build time or runtime performance issues, its best to enable all available compatibility settings instead of a performance trade-off that really is not necessary.

Reduce MSI file component count

The InstallAware compiler normally generates one MSI component for each file that is included with your setup. This can slow down processing significantly on the Windows Installer side (once Apply Install has been called), since Windows Installer has to keep track of every MSI component defined in your setup. Check this box to group multiple files inside a single MSI component. InstallAware will still follow MSI component authoring guidelines when grouping your files together inside fewer MSI file components.

Please note that MSI components are not the same entity as your setup features or components as seen in the either visual IDE or your setup script. Refer to Windows Installer documentation for more information on MSI components - InstallAware does not expose you to MSI components in either the visual IDE or your setup script, and handles them internally at all times.

With this setting enabled, only files that are part of a single Install Files command are optimized. Files that span across different Install Files commands will still be placed inside different MSI components. Use wildcards with the Install Files command to optimize MSI component creation for files.

Reduce MSI registry component count

The InstallAware compiler normally generates one MSI component for each registry value that is created by your setup. This can slow down processing significantly on the Windows Installer side (once Apply Install has been called), since Windows Installer has to keep track of every MSI component defined in your setup. Check this box to group multiple registry values inside a single MSI component. InstallAware will still follow MSI component authoring guidelines when grouping your registry values together inside fewer MSI components.

Please note that MSI components are not the same entity as your setup features or components as seen in the either visual IDE or your setup script. Refer to Windows Installer documentation for more information on MSI components - InstallAware does not expose you to MSI components in either the visual IDE or your setup script, and handles them internally at all times.

With this setting enabled, registry values that reside inside the same If / Else / End block are optimized. Registry values not inside the same If / Else / End block are not placed inside the same MSI component.

Generate stable identifiers

The InstallAware compiler normally generates stable MSIcode statement identifiers for each line of your setup script. These identifiers do not change between each build of your setup, and make each of your MSIcode statements "unique" - they can be tracked and identified by InstallAware and Windows Installer during the different iterations of your setup source code. However, it is costly to generate stable identifiers in terms of processing power; therefore using stable identifiers will slow down the build speed of your setup project.

Stable identifiers do not negatively impact runtime setup performance, and permit Web Media Block sharing between different builds of your setup, as well as different setup projects sharing the same source media layout and plug-ins.

Use dynamic identifiers

If you need to improve the build speed of your setup projects, use dynamic identifiers instead by selecting this option. The InstallAware compiler will not make an effort to generate unique identifiers for each MSIcode statement. This may create problems with patching, and will almost always break Web Media Block reuse. Even when you are rebuilding the same project, when the ordering and/or number of the MSIcode statements in your setup script change, you will need to regenerate your Web Media Blocks with this option.

Blend

Blend offers a "best of both worlds" approach for generating MSIcode statement identifiers. The InstallAware compiler will use stable identifiers for each MSIcode statement that is associated with a source file, enabling Web Media Block reuse. For every other statement, such as registry entries, unstable identifiers will be used, improving build performance. However, this setting might still create problems with patching.

Output Node

This page allows you to customize additional build settings:

• If you wish to customize the output folder, check Custom Folder and provide your preferred output folder. By default, builds will exist under your project folder.
• If you wish to customize the name of your main setup executable, enter it in the Output filename field. Leave this field empty to use the default name, which is the same as your project file name.
• If you wish to automatically update the revision code every time you build (excluding batch builds), check Change revision code automatically upon rebuild. This setting must be unchecked when debugging your setup. Checking it will enable seamless, automatic upgrades of your product.
• If you wish to generate file hashes for your non-versioned application files, check Calculate file hashes for Windows Installer. To improve build speeds, uncheck this setting. Checking it will enable Windows Installer to better identify changes made to your already-installed application files, but will slow processing.

Patch Node

This page lets you configure how patches are created for your setups.

Include whole files only

Enable this option to disable binary differential patching. Files that have changed between product versions will be included in their entirety. This option may be useful when patching against a large number of reference packages, or the differential algorithm fails to provide satisfactory results.

Optimize for large files

Enable this option if the files you are patching are more than eight megabytes in length.

Ignore missing files

If your patch references contain missing source files, enable this option to allow patching to continue.

Leave debug files

Enable this option to manually investigate the by products of the patching process and the interim installer databases created by the patch engine.