How to: Set the product, version, appearance, and launch target

The three pages in the Project group hold the project file's individual settings: General (what gets installed, and where), Appearance (what the starter's windows look like), and Launch target (what the starter launches when it's done). Each page is a set of fields arranged in groups. If you leave a field empty, the starter uses its default. Select the project, select the page in the navigation, and enter your values. Changes take effect in Bootstrapper Manager immediately and are written to the project file when you select Save or press Ctrl+S.

The starter defines what each field does, which values are allowed, and what happens when a field is empty; see The project file (format 2), section Property value (WKL Bootstrapper documentation). This page shows which part of the project file each field corresponds to and what the Bootstrapper Manager itself does with it.

Fill in either Version or Version from file, not both.

Bitness. This field decides which entries on the Files page that have a bitness of their own the starter sets up for the user, such as the WKL components from components\x86 or from components\x64:

In most cases, leave the field empty: each user then gets the entries that match their Access. The starter's checks on the user's computer (Access, WKL components, .NET, ODBC drivers) always follow the installed Access, even with x86 or x64.

To see what the windows look like with these settings, select Preview on the Projects page; see How to: Test a project and build an MSI package.

The person who reads Text while setting up is the user of the application, while the starter copies a new version or sets up the WKL components, often first thing in the morning. Write it for that moment:

• Say what the application is doing, not what the user has to do: the user can't speed it up and has nothing to fix.
• One short line that ends with “ …”, in the language you set under Language. If Language is empty, the window follows the language of Office, and your text would stand next to texts in another language.
• No technical terms, versions, or paths; the diagnostic details of the window keep those for support.
• Leave the field empty for the default text “Preparing the new version …” in the user's language.
• Text while starting follows the same rules; the window shows it while the starter checks the computer and starts the application (starter 2.4.1 and later). Empty: “Starting the application …”.

• Don't change the product ID after your first release. The starter uses the value in the Product ID field to name the app's folder in the user's profile and its entry in Windows Installed apps, so a new product ID looks like a different application to Windows.
• Source folder and MSI package: A relative path is resolved from the starter's folder. That works as long as the starter stays next to the source folder, for example when users launch it from the share. The MSI package, however, installs the starter in Program Files (x86)\WKL\<product ID>, where a relative path no longer resolves. For a project you ship as an MSI package, enter a full path or a share, such as \\server\Kasse\deploy.
• Delivery key: The field holds only the public part of the key. You create the key and sign each delivery with the starter (/new-key, /publish); Bootstrapper Manager does neither. With a delivery key, starter 2.2.4 and later never install a version older than the highest one the user already has, so an older delivery that someone puts back in the source has no effect. To go back to an earlier version on purpose, publish it with /publish /withdraw. Both are covered in How to: Publish a signed delivery (WKL Bootstrapper documentation), section “Going back to an earlier version.”
• Red marker on a field: The starter's last check found a problem with this field; you'll find the starter's message on the Problems page. As soon as you change the field, the marker disappears, because the starter hasn't evaluated the new value yet. Run the check again; see How to: Check a project and fix problems.
• Untranslated values: The choices (access, automatic, auto, …) are the raw project file values described in the starter's reference.
• Not on these pages: The window state at startup (start.window), the minimum time the splash screen stays up (start.splash), and environment variables (start.environment) don't have fields. Bootstrapper Manager keeps them unchanged when it saves; edit them directly in the project file.

• The project file (format 2), sections Property value and Placeholders (WKL Bootstrapper documentation): what each field means, its allowed values, and its default
• How to: Publish a signed delivery (WKL Bootstrapper documentation): create a delivery key, then sign and withdraw deliveries
• How to: Choose which files to install and where
• How to: Save a project