InstallBuilder User Guide 24

Contact Support Download

Variables

Basic Syntax

Installer variables are an important concept in InstallBuilder. They allow you to store user input, temporary values, establish flags and use that information at different points during the build and installation processes. There are a number of built-in variables and you are also able to create them directly. The basic way of creating or changing the value of a variable in InstallBuilder is using the <setInstallerVariable> action:

 <setInstallerVariable name="foo" value="bar"/>

The action above will store the value bar in the variable foo. Once you have defined the variable, its value can be accessed in any other part of the project as ${foo}. If you require a variable that you are creating at install time to be also available in the uninstallation steps, you have to set the optional persist attribute to 1:

 <setInstallerVariable name="foo" value="bar" persist="1"/>

At uninstallation time, this variables will contain the value of the last assignment using the persist property.

Variable names must not contain characters other than digits, letters, dashes and underscores. There is only one exception to this rule: it is possible to use a variable as part of the name of another variable (as long as it is a valid one).

For example, if you have a variable foo with a value of bar, then:

 <setInstallerVariable name="${foo}" value="Hello"/>

will be equivalent to:

 <setInstallerVariable name="bar" value="Hello"/>

In addition to regular variables, parameters can also be accessed as variables. One good example is the well-known installdir variable which is in reality a <directoryParameter>:

<runProgram program="${installdir}/myApplication.run" programArguments="--install"/>

Some additional information to take into account when working with variables is:

Curly brackets are mandatory: Although the syntax is similar to the notation used in Unix bash-like shells to access variables, it is not the same. If $foo is used instead of ${foo}, it will not be resolved but treated as a literal string.
Accessing an undefined variable will not throw an error. Instead, if the variable name was bar, the value will be set to ***unknown variable bar***
Variables are not case sensitive. This means that you can use any of the following variants, ${variablename}, ${VariableName} or ${VARIABLENAME} and obtain the same value in all cases.

Modifier Suffixes

When accessing a variable, some operations can be specified through the usage of special suffixes:

${installdir.dos}: If the variable contains a path, this modifier returns the DOS-style name for it. This will only take effect if the file exists and the platform is Windows. This is particularly useful when the value of the variable may contain spaces and you need to pass it as an argument to a program. Using the .dos suffix will remove the need of quoting the path as spaces will be removed. Take into account that using .dos over a path with forward slashes won’t convert them to backslashes.
${installdir.unix}: If the variable contains a path, it will be converted to a Unix-style path and all of the backslashes will be translated into forward slashes. This will only take effect if the platform is Windows.
${myPassword.password}: The .password suffix is used to mark a variable as a password to be hidden in the logs. This way, you can use a password as an argument in a <runProgram> action and log the execution without showing the plain text password. For example, the following action:

     <setInstallerVariable name="pass" value="myhiddenpassword!"/>
     <runProgram>
         <program>mysql</program>
         <programArguments>-u root --password=${pass.password}</programArguments>
     </runProgram>

will be logged as:

Executing mysql -u root --password=****
Script exit code: 0

Please note this suffix is only considered when resolving variables that will be used when writing to the installation log or in the error messages thrown by the <runProgram> and <setInstallerVariableFromScriptOutput> actions. For example, <logMessage> will interpret the suffix when logging its information but <writeFile> will ignore it.

${myVariable.escape_backslashes}: This will escape all of the backslashes in the text stored in the variable. It is especially useful for substitution of values in Java property files.
${installdir.dos.unix.escape_backslashes}: The modifiers can be combined.

The below table summarizes all the suffixes:

Original value

Modifier

Resolved value

alongfilename.txt

${installdir.dos}

ALONGF~1.TXT

c:\Program Files\myFile.exe

${installdir.unix}

c:/Program Files/myFile.exe

c:\Program Files\myFile.exe

${myVariable.escape_backslashes}

c:\\Program Files\\myFile.exe

c:\Program Files\myLongFile.exe

${installdir.dos.unix}

C:/PROGRA~1/MYLONG~1.EXE

Note

Convert forward slashes to backslashes

InstallBuilder does not have a modifier suffix to convert forward slashes to backslashes the same way as the .unix suffix does. To achieve the same result you just have to use a <setInstallerVariableFromRegEx> action:

 <setInstallerVariableFromRegEx>
    <name>backslash_path</name>
    <pattern>/</pattern>
    <substitution>\</substitution>
    <text>${forwardslash_path}</text>
 </setInstallerVariableFromRegEx>

The above will store the backslash-version of the Unix-like ${forwardslash_path} in the backslash_path variable.

Modifying buttons attributes

You can change the installer navigation buttons attributes using <setInstallerVariable>. Currently, the text and state are supported.

<directoryParameter>
  <name>installdir</name>
  <insertBefore>readytoinstall</insertBefore>
  ...
  <preShowPageActionList>
    <setInstallerVariable>
      <name>ui.button(next).text</name>
      <value>Next</value>
    </setInstallerVariable>
  </preShowPageActionList>
  <postShowPageActionList>
    <setInstallerVariable>
      <name>ui.button(next).text</name>
      <value>Install</value>
    </setInstallerVariable>
  </postShowPageActionList>
</directoryParameter>

<project>
  ...
  <readyToInstallActionList>
    <!-- Disable cancel button while installing -->
    <setInstallerVariable>
      <name>ui.button(cancel).state</name>
      <value>disabled</value>
    </setInstallerVariable>
  </readyToInstallActionList>
  ...
  <postInstallationActionList>
    <!-- Enable the cancel button back -->
    <setInstallerVariable>
      <name>ui.button(cancel).state</name>
      <value>enabled</value>
    </setInstallerVariable>
  </postInstallationActionList>
  ...
 </project>

Accessing Environment Variables

It is possible to access any environment variable using the ${env(varname)} construct, where varname is the name of an environment variable. For example, on Windows you can refer to the system drive with ${env(SYSTEMDRIVE)} and, on Linux, Mac OS X and other Unix systems to the user home directory with ${env(HOME)}

To get a list of the environment variables on your system that will be available to the installer you can execute:

On Windows Systems: Open a command window and execute: set
On Unix Systems: Open a console and execute: env

Both commands will print a list of the defined environment variables. However, you must take into account that some of these variables could vary from one machine to another.

Advanced syntax

Almost all of the elements of an InstallBuilder project can be accessed and modified as variables. This makes InstallBuilder a very versatile tool because it allows installers to customize themselves at runtime, based on the environment or on end user feedback. The three basic elements which can be accessed are:

Project properties

All of the project properties such as <version>, <shortName>, <installerFilename> and so on, can be referenced using the notation ${project.property}. For example, ${project.shortName} for the <shortName>. Similarly to regular variables, you can use any capitalization when referencing an element. Using ${PrOjEct.InstallerFilename} is equivalent to using ${project.installerFilename}.

The below example changes the <installationType> at runtime to perform an upgrade if the previous installed version, stored in an environment variable, is lower than the current one:

<project>
   ...
   <shortName>myProduct</shortName>
   <installationType>normal</installationType>
   ...
   <initializationActionList>
     <setInstallerVariable>
       <name>project.installationType</name>
       <value>upgrade</value>
       <ruleList>
         <!-- Check that the env variable exists -->
         <compareText>
            <text>${env(MYPRODUCT_VERSION)}</text>
            <logic>does_not_equal</logic>
            <value></value>
         </compareText>
         <!-- Compare the versions -->
         <compareVersions>
            <version1>${project.version}</version1>
            <logic>greater</logic>
            <version2>${env(MYPRODUCT_VERSION)}</version2>
         </compareVersions>
       </ruleList>
     </setInstallerVariable>
   </initializationActionList>
   ...
</project>

You can refer to the Project Properties appendix for the complete list of properties.

Components

Using this notation you can also modify component settings:

${project.component(default).selected}
${project.component(mysql).show}

This allows, for example, disabling components at runtime when the user does not provide a license key:

<stringParameter>
  <name>licenseKey</name>
  <description>Please provide a license key. If you leave the field empty
  you just will be able to test the basic functionality</description>
  <insertBefore>components</insertBefore>
  <postShowPageActionList>
    <actionGroup>
      <actionList>
        <setInstallerVariable>
          <name>project.component(premiumComponent).selected</name>
          <value>0</value>
        </setInstallerVariable>
        <setInstallerVariable>
          <name>project.component(premiumComponent).canBeEdited</name>
          <value>0</value>
        </setInstallerVariable>
      </actionList>
      <ruleList>
        <compareText>
          <text>${licenseKey}</text>
          <logic>equals</logic>
          <value></value>
        </compareText>
      </ruleList>
    </actionGroup>
  </postShowPageActionList>
</stringParameter>

You can refer to the Components appendix for the complete list of properties.

Parameters

Using the advanced syntax on parameters will allow you to modify not only their values but their entire set of properties such as <description>, <explanation> and the especially useful <ask>. The basic usage is:

${project.parameter(nameOfTheParameter).propertyName}

For example:

${project.parameter(installdir).value}
${project.parameter(tomcat).description}
${project.parameter(mySQL).default}

If the parameter to access is a child of a <parameterGroup>, the parent must also be specified. For example, the port parameter in the below code:

<project>
  ...
  <parameterList>
    <parameterGroup>
      <name>mysqlConfiguration</name>
      <parameterList>
        <stringParameter name="port" description="MySQL port" value="3306"/>
        <passwordParameter name="password" description="MySQL root password" value=""/>
        ...
      </parameterList>
    </parameterGroup>
  </parameterList>
  ...
</project>

Can be accessed using:

${project.parameter(mysqlConfiguration).parameter(port).value}

If the parameters are also included inside a component, instead of directly under the <project> <parameterList>, it must be also specified. For example, reusing the above example:

<project>
  ...
  <componentList>
    <component>
      <name>mySQL</name>
      <parameterList>
        <parameterGroup>
          <name>mysqlConfiguration</name>
          <parameterList>
            <stringParameter name="port" description="MySQL port" value="3306"/>
            <passwordParameter name="password" description="MySQL root password" value=""/>
            ...
          </parameterList>
        </parameterGroup>
      </parameterList>
    </component>
  </componentList>
  ...
</project>

The parameter should now be accessed using:

${project.component(mysql).parameter(mysqlConfiguration).parameter(port).value}

You can use this functionality to disable pages or parameters at runtime based on the user input:

<project>
  ...
  <componentList>
   <component>
     <name>mySQL</name>
     <parameterList>
       <booleanParameter>
         <name>enableAdvanced</name>
         <description>Do you want to enable the advanced configuration?</description>
         <postShowPageActionList>
           <!-- Enable the page, which is disabled by default -->
           <setInstallerVariable>
             <name>project.component(mySQL).parameter(mysqlAdvanced).ask</name>
             <value>1</value>
             <ruleList>
                <isTrue value="${project.component(mySQL).parameter(enableAdvanced).value}"/>
             </ruleList>
           </setInstallerVariable>
         </postShowPageActionList>
       </booleanParameter>
       <parameterGroup>
          <name>mysqlAdvanced</name>
          <parameterList>
             <stringParameter name="mysqlPort" description="MySQL port" value="3306"/>
             <passwordParameter name="mysqlPassword" description="MySQL root password" value=""/>
             ...
          </parameterList>
       </parameterGroup>
     </parameterList>
   </component>
  </componentList>
  ...
</project>

Parameters are also handy when you want to preserve variables defined at build time. Accessing a variable defined in the <preBuildActionList> at runtime will result in an ***unknown variable varName*** error. To workaround this issue, you could use a hidden parameter (setting ask="0"), that won’t be displayed in the help menu nor the installer pages. For example, to pass a random generated key for each of the built installers you could use the below code:

<project>
  ...
  <parameterList>
    ...
    <stringParameter name="build_identifier" value="" ask="0"/>
    ...
  </parameterList>
  <preBuildActionList>
     <!-- Create random identifier for the build -->
     <generateRandomValue>
       <variable>build_identifier</variable>
     </generateRandomValue>
     <!-- Date of the build -->
     <createTimeStamp>
        <variable>timestamp</variable>
     </createTimeStamp>
     <!-- Register the build information in a local file -->
     <addTextToFile>
        <file>${build_project_directory}/builds</file>
        <text>${build_identifier} - Product Version: ${project.version} - IB Version: ${installer_builder_version} - Built On: ${timestamp}</text>
     </addTextToFile>
  </preBuildActionList>
  ...
</project>

As you are using a hidden parameter, the ${build_identifier} will be available at runtime and you could, for example, send it to your server using an <httpPost> action to register the installations for each release:

  <postInstallationActionList>
     ...
     <httpPost url="http://www.example.com/register.php" filename="${installdir}/activationUrl">
        <queryParameterList>
           <queryParameter name="build_identifier" value="${build_identifier}"/>
           <queryParameter name="version" value="${project.version}"/>
        </queryParameterList>
     </httpPost>
  </postInstallationActionList>

Note

Accessing a parameter as a regular variable

If you try to access a parameter as if it were a regular variable, it will give you its value. That is, using ${installdir} or ${project.parameter(installdir).value} will return the same result.

The advantage of using the long notation is that it provides a very descriptive path to the element you are modifying. For example, if you are working with a very big project that is maintained by multiple developers and divided into multiple files using the <include> directive, locating where the below values are located could be troublesome (they could be parameters or regular variables, located in any of the included files or the main project):

   <throwError text="You have selected strict password checking and your password is too short" >
     <ruleList>
       <isTrue value="${enableStrictChecking}"/>
       <compareTextLength>
         <text>${password}</text>
         <logic>less</logic>
         <length>${minLength}</length>
       </compareTextLength>
     </ruleList>
   </throwError>

Where using the long location will point you directly to where they are defined (assuming the included files are named according to the component names, for example):

   <throwError text="You have selected strict password checking and your password is too short" >
     <ruleList>
       <isTrue value="${project.component(settings).parameter(basicConfiguration).parameter(enableStrictChecking).value}"/>
       <compareTextLength>
         <text>${password}</text>
         <logic>less</logic>
         <length>${project.component(settings).parameter(defaultPasswordSettings).parameter(minLength).value}</length>
       </compareTextLength>
     </ruleList>
   </throwError>

In addition to the above-mentioned elements, any other tag in the XML project with a unique identifier can be referenced. For example, is possible to reference a folder in a component to get its destination:

`<showInfo text="${project.component(mysql).folder(mysqlConfig).destination}"/>`

But not a file in its <distributionFileList> because files do not have a unique name.

Accessing Language Strings

You can also access language strings, either built-in or user-defined (check the Languages section for more details), using the special notation ${msg(stringKey)}. It will be resolved to the localized string identified by the key stringKey in the current installation language:

   <showInfo text="${msg(hello.world)}"/>

If you have defined the hello.world localized string in the <customLanguageFileList>, depending on the installation language you will get results such as Hello world!, Hola Mundo! or Hallo Welt.

Escaping Variables

In some cases, for example when modifying shell scripts programmatically, you may need a literal ${foo} instead of the contents of the foo variable (which may result in an ***unknown variable foo***). For these cases, InstallBuilder implements a special notation to specify that you want the text treated literally, without trying to be resolved: ${'${variableName}'}.

For example, ${'${foo}'} will be resolved to: ${foo}. More complex text can be escaped as shown in the snippet below:

     <writeFile>
       <path>~/.bashrc</path>
        <text>${'
PATH=${PATH}:/some/path
Foo=${bar}
'}</text>
     </writeFile>

It will write:

PATH=${PATH}:/some/path
Foo=${bar}

As shown in the example, it accepts line breaks in the text to escape. The only limitation is that it cannot contain the characters '} in the text to escape or it will be interpreted as the end of the escaped reference.

Nested Variables

Nested variables are also allowed. They will be evaluated from the most inner reference:

     <showInfo>
       <text>${text_${foo-${i}}_${bar}}</text>
     </showInfo>

This feature is especially useful when iterating using a <foreach> action. For example, if you have a list of component names and you want to create a list with those that are selected:

<setInstallerVariable name="selectedComponents" value=""/>
<foreach variables="component" values="componentA componentB componentC componentD">
   <actionList>
      <setInstallerVariable name="slectedComponents" value="${selectedComponents} ${component}" >
         <ruleList>
            <isTrue value="${project.component(${component}).selected"/>
         </ruleList>
      </setInstallerVariable>
  </actionList>
</foreach>

Built-in variables

InstallBuilder also provides a list of built-in variables containing information about the installer or the environment in which it is executed:

HTTP

installer_http_code: Contains the HTTP status code of the last httpGet or httpPost action.

Example values:

200, 404, 500

installer_http_proxy: Contains the configured HTTP proxy address

Example values:

http://example.org:8080/proxy

Java

java_autodetected: Whether or not a valid Java was autodetected

Possible values:

0, 1

java_bitness: Autodetected Java bitness

Possible values:

64, 32

java_executable: Location of the autodetected Java executable

Example values:

/usr/bin/java, c:/Program Files/Java/jre1.6.0_10/bin/java.exe

java_vendor: Autodetected Java vendor

Possible values:

IBM, Sun, Any

java_version: Autodetected Java version

Example values:

1.6.0, 1.5.0

java_version_full: Autodetected Java full version

Example values:

1.6.0_07, 1.5.0_11

java_version_major: Autodetected Java major version

Example values:

1.6, 1.5

javaw_executable: Autodetected javaw executable path

Example values:

/usr/bin/java, c:/Program Files/Java/jre1.6.0_10/bin/java.exe

javaws_executable: Location of the autodetected Java Web Start executable

Example values:

/usr/bin/javaws, c:/Program Files/Java/jre1.6.0_10/bin/javaws.exe

User Interface

installer_interactivity: The level of interactivity of the installation mode

Possible values:

none, minimal, minimalWithDialogs, normal

installer_ui: The mode in which the installer is run

Possible values:

text, gui, unattended

installer_ui_detail: The detailed mode in which the installer is run

Possible values:

text, gtk, qt, osx, win32, xwindow, unattended

.NET Framework

dotnet_autodetected: Whether or not a valid .NET framework was autodetected

Possible values:

0, 1

dotnet_framework_type: .NET framework type

Possible values:

, client, full

dotnet_version: .NET framework version

Example values:

2.0, 3.5, 4.0, 4.5

Installer

installation_aborted_by_user: Whether or not installation was manually aborted by user

Possible values:

0, 1

installation_finished: Whether or not the installation finished successfully

Possible values:

0, 1

installation_guid: Unique installation ID

Example values:

b2cef26e-526b-4199-653b-1cc067abf371

installation_language_code: Language code of the installation

Possible values:

sq, ar, es_AR, az, eu, pt_BR, bg, ca, hr, cs, da, nl, en, et, fi, fr, de, el, he, hu, id, it, ja, kk, ko, lv, lt, no, fa, pl, pt, ro, ru, sr, zh_CN, sk, sl, es, sv, th, zh_TW, tr, tk, uk, va, vi, cy

installer_builder_timestamp: Timestamp of the InstallBuilder used to build the installer

Example values:

201001220702

installer_builder_version: Version of InstallBuilder used to build the installer

Example values:

6.2.7

installer_command_line_arguments: Command line arguments as passed to installer

Example values:

--mode gtk, --installdir /opt/app-1.0

installer_error_message: Contains the error of the last failed action, possibly masked by its <customErrorMessage>

Example values:

Unknown error installing MySQL

installer_error_message_original: Contains the original error of the last failed action

Example values:

Unknown error executing action

installer_exit_code: Installer Exit Code value. It’s value is 0 by default and set to 1 if there was an error executing an action.

installer_installation_log: The location of the installer log

Example values:

/tmp/installbuilder_install.log, C:\Users\Username\Appdata\Local\Temp

installer_is_root_install: Whether or not the current user has root privileges

Possible values:

0, 1

installer_package_format: Type of installer

Possible values:

executable

installer_pid: PID of the running installer or uninstaller

Example values:

53008

program_exit_code: Exit code from program; set by runProgram and setInstallerVariableFromScriptOutput actions

Example values:

0, 1

program_stderr: Program’s error output; set by runProgram and setInstallerVariableFromScriptOutput actions

Example values:
program_stdout: Program’s output; set by runProgram and setInstallerVariableFromScriptOutput actions

Example values:
required_diskspace: Required disk space to install the application in Kilobytes

Example values:

10000, 25000

Windows Folders

windows_folder_program_files: Directory for program files

Example values:

C:\Program Files

windows_folder_program_files_common: Directory for components shared across applications

Example values:

C:\Program Files\Common Files

windows_folder_system: Windows system directory

Example values:

C:\Windows\system32

windows_folder_systemroot: Windows root directory

Example values:

C:\Windows

windows_folder_windows: Windows root directory

Example values:

C:\Windows

Windows Folders - System Scope

windows_folder_common_admintools: Directory that stores administrator tools for all users

Example values:

C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Administrative Tools

windows_folder_common_appdata: Directory that stores common application-specific data

Example values:

C:\ProgramData

windows_folder_common_desktopdirectory: Directory that stores common desktop files

Example values:

C:\Users\Public\Desktop

windows_folder_common_documents: Directory that stores common document files

Example values:

C:\Users\Public\Documents

windows_folder_common_favorites: Directory that stores common favorite items

Example values:

C:\Users\Administrator\Favorites

windows_folder_common_music: Directory that stores common music files

Example values:

C:\Users\Public\Music

windows_folder_common_pictures: Directory that stores common picture files

Example values:

C:\Users\Public\Pictures

windows_folder_common_programs: Directory that stores common program groups in start menu

Example values:

C:\ProgramData\Microsoft\Windows\Start Menu\Programs

windows_folder_common_startmenu: Directory that stores common start menu items

Example values:

C:\ProgramData\Microsoft\Windows\Start Menu

windows_folder_common_startup: Directory that stores common Startup program group

Example values:

C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup

windows_folder_common_templates: Directory that stores common templates

Example values:

C:\ProgramData\Microsoft\Windows\Templates

windows_folder_common_video: Directory that stores common video files

Example values:

C:\Users\Public\Videos

Cross-platform Folders

installdir: The installation directory

Example values:

/home/user/programx, C:\Program Files\programx

installer_directory: The directory location of the installer binary

Example values:

/home/user/example, C:\example

installer_pathname: The full path of the installer binary

Example values:

/home/user/example/installer.bin, C:\example\installer.exe

platform_install_prefix: The platform specific default installation path

Example values:

/home/user, C:\Program Files, /Applications

system_temp_directory: Path to the system’s temporary directory

Example values:

/tmp, C:\Users\Username\Appdata\Local\Temp

user_home_directory: Path to the home directory of the user who is running the installer

Example values:

/home/username, C:\Users\Username

Build-time Variables

build_project_directory: Directory containing the XML project used to generate the installer.

Example values:

/home/username/installbuilder-7.0.0/projects, C:\Program Files\InstallBuilder for Windows 7.0.0\projects

installbuilder_install_root: Installation directory of InstallBuilder. This variable is available only at build time, as it does not make sense to access this information at runtime

Example values:

/home/username/installbuilder-7.0.0, C:\Program Files\InstallBuilder for Windows 7.0.0

installbuilder_output_directory: InstallBuilder output directory. This variable is available only at build time, as it does not make sense to access this information at runtime

Example values:

/home/username/installbuilder-7.0.0/output, C:\Program Files\InstallBuilder for Windows 7.0.0\output

installbuilder_output_filename: Location of the generated installer. This variable is available only at build time, as it does not make sense to access this information at runtime

Example values:

/home/username/installbuilder-7.0.0/output/sample-1.0-linux-installer.run, C:\Program Files\InstallBuilder for Windows 7.0.0\output\sample-1.0-window-installer.exe

installbuilder_ui: The mode in which the builder is run

Possible values:

text, gui

Windows Folders - User Scope

windows_folder_admintools: Directory that stores administrator tools for individual user

Example values:

C:\Users\Administrator\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Administrative Tools

windows_folder_appdata: Directory that stores user application-specific data

Example values:

C:\Users\Administrator\AppData\Roaming

windows_folder_cookies: Directory that stores user cookies

Example values:

C:\Users\Administrator\AppData\Roaming\Microsoft\Windows\Cookies

windows_folder_desktopdirectory: Directory that stores user desktop files

Example values:

C:\Users\Administrator\Desktop

windows_folder_favorites: Directory that stores user favorite items

Example values:

C:\Users\Administrator\Favorites

windows_folder_history: Directory that stores user Internet history items

Example values:

C:\Users\Administrator\AppData\Local\Microsoft\Windows\History

windows_folder_internet_cache: Directory that stores user temporary internet files

Example values:

C:\Users\Administrator\AppData\Local\Microsoft\Windows\Temporary Internet Files

windows_folder_local_appdata: Directory that stores user local (non-roaming) repository for application-specific data

Example values:

C:\Users\Administrator\AppData\Local

windows_folder_mymusic: Directory that stores user music files

Example values:

C:\Users\Administrator\Music

windows_folder_mypictures: Directory that stores user picture files

Example values:

C:\Users\Administrator\Pictures

windows_folder_myvideo: Directory that stores user video files

Example values:

C:\Users\Administrator\Videos

windows_folder_nethood: Directory that stores user network shortcuts

Example values:

C:\Users\Administrator\AppData\Roaming\Microsoft\Windows\Network Shortcuts

windows_folder_personal: Directory that stores user document files

Example values:

C:\Users\Administrator\Documents

windows_folder_printhood: Directory that stores printer shortcuts

Example values:

C:\Users\Administrator\AppData\Roaming\Microsoft\Windows\Printer Shortcuts

windows_folder_profile: Directory that stores user profile

Example values:

C:\Users\Administrator

windows_folder_programs: Directory that stores user program groups in start menu

Example values:

C:\Users\Administrator\AppData\Roaming\Microsoft\Windows\Start Menu\Programs

windows_folder_recent: Directory that stores shortcuts to user’s recently used documents

Example values:

C:\Users\Administrator\AppData\Roaming\Microsoft\Windows\Recent

windows_folder_sendto: Directory that stores user Send To menu items

Example values:

C:\Users\Administrator\AppData\Roaming\Microsoft\Windows\SendTo

windows_folder_startmenu: Directory that stores user start menu items

Example values:

C:\Users\Administrator\AppData\Roaming\Microsoft\Windows\Start Menu

windows_folder_startup: Directory that stores user Startup program group

Example values:

C:\Users\Administrator\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup

windows_folder_templates: Directory that stores user templates

Example values:

C:\Users\Administrator\AppData\Roaming\Microsoft\Windows\Templates

Linux Specific

linux_distribution: Type of Linux distribution

Possible values:

redhat, amazon, fedora, debian, ubuntu, suse, mandrake, slackware, redflag, gentoo, arch

linux_distribution_codename: Linux distribution code name (based on Linux Standard Base tool: lsb_release)

linux_distribution_description: Linux distribution description (based on Linux Standard Base tool: lsb_release)

Example values:

Debian, GNU/Linux

linux_distribution_fullname: Linux distribution fullname

Possible values:

Red Hat Enterprise Linux, Red Hat Linux, CentOS, SME Server Linux, Scientific Linux, Red Hat Enterprise Linux, Red Hat Linux, CentOS, SME Server Linux, Scientific Linux, Fedora, Core, Debian, Debian, openSUSE, Suse, Mandrake, Slackware, Red, Flag, Gentoo, Arch

linux_distribution_id: Linux distribution distributor’s ID (based on Linux Standard Base tool: lsb_release)

Example values:

Debian

linux_distribution_release: Linux distribution release number(based on Linux Standard Base tool: lsb_release)

Example values:

3.1

linux_distribution_shortname: Linux distribution shortname

Possible values:

rhel, rh, amazon, fedora, debian, ubuntu, suse, mandrake, slackware, redflag, gentoo, arch

linux_distribution_version: Linux distribution mayor version

Example values:

5.0

OSX Specific

osx_major_version: OSX major version number

Example values:

10.3, 10.5

osx_version: OSX version number

Example values:

10.3.9, 10.5.7

Windows Specific

windows_os_build_number: Windows OS build number

Example values:

19043, 22000

windows_os_family: Type of Windows OS

Possible values:

Windows 95, Windows NT

windows_os_family_shortname: Windows OS family shortname

Possible values:

win9x, winnt

windows_os_flavor: Flavor of Windows OS

Possible values:

Advanced Server, Business, Data Center, Enterprise, Essentials, Foundation, Home, Home Basic, Home Premium, Professional, Server, Standard, Starter, Storage Server, Storage Server Standard, Storage Server Workgroup, Ultimate, Web Edition, Workstation

windows_os_name: Windows OS name

Possible values:

Windows 7, Windows 7 WSLK, Windows 8, Windows 8.1, Windows 10, Windows 11, Windows 95, Windows 98, Windows 2000, Windows 2003, Windows 2008, Windows 2008 R2, Windows 2012, Windows 2012 R2, Windows 2016, Windows 2019, Windows 2022, Windows Vista, Windows XP

windows_os_service_pack: Windows OS Service Pack version number

Example values:

1, 2, 3

windows_os_uac_enabled: Whether or not UAC is enabled

Possible values:

0, 1

windows_os_version_number: Windows OS version number

Possible values:

4.0, 4.1, 5.0, 5.1, 5.2, 6.0, 6.1, 7.0, 10.0

System Configuration

machine_cpu_count: Number of CPUs in the machine

Example values:

1, 2

machine_cpu_speed: The machine’s CPU speed in MHZ

Example values:

1500

machine_fqdn: The machine’s fully qualified domain name

Example values:

installbuilder-desktop.mydomain.com

machine_hostname: The machine’s hostname

Example values:

example.com

machine_ipaddr: The machine’s IP address

Example values:

10.0.0.2

machine_swap_memory: The machine’s swap memory in MB

Example values:

512

machine_total_memory: The machine’s total physical memory in MB

Example values:

512

platform_exec_suffix: The platform specific binary suffix

Possible values:

exe, run, app

platform_has_smp: Whether or not the machine has multiple processors

Possible values:

0, 1

platform_name: At build-time, it contains the target build platform. At runtime, the platform in which the installer is running

Possible values:

windows, linux, osx

platform_path_separator: The platform specific path separator

Possible values:

\, /

system_locale: Current system locale

Possible values:

sq, ar, es_AR, az, eu, pt_BR, bg, ca, hr, cs, da, nl, en, et, fi, fr, de, el, he, hu, id, it, ja, kk, ko, lv, lt, no, fa, pl, pt, ro, ru, sr, zh_CN, sk, sl, es, sv, th, zh_TW, tr, tk, uk, va, vi, cy

system_username: Name of the user who is running the installer

Example values:

root, Administrator, guest

Installer Page Order Control

back_page: The previous page to show

Example values:

installdir, welcome, installation, installationFinished

next_page: The next page to show

Example values:

installdir, welcome, installation, installationFinished