You are viewing the documentation of TeamCity 8.x, which is not the most recently released version of TeamCity.
View this page in TeamCity 2018.x documentation or refer to the listing to choose the documentation corresponding to your TeamCity version.


Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 4.0


The predefined build parameters can originate from several scopes:

  • #Server Build Properties - the parameters generated by TeamCity on the server-side in the scope of a particular build. An example of such property is a build number.
  • #Agent Properties - the parameters provided by an agent on connection to the server. The parameters are not specific to any build and characterize the agent environment (for example, the path to .Net framework). These are mainly used in agent requirements.
  • #Agent Build Properties - the parameters provided on the agent side in the scope of a particular build right before the build start. For example, a path to a file with a list of changed files.

All these parameters are finally passed to the build.

There is also a special kind of server-side build parameters that can be used in references while defining other parameters, but which are not passed into the build. See Configuration Parameters below for the list of such properties.


Reference-only Server Properties
Reference-only Server Properties
Wiki Markup
} These properties are available only *since TeamCity 4.5*. In TeamCity 4.0.x you could only use [#Dependencies Properties] in the build number and VCS labeling pattern.{show-if}
These are the parameters that other properties can reference (only if defined on the Build Parameters page), but that are not passed to the build themselves.

You can get the full set of such server properties by adding the system.teamcity.debug.dump.parameters property to a build configuration and examining the "Available server properties" section in the build log.


  • <btID> — is the ID of the build configuration to get the property from. Only the configurations the current one has snapshot or artifact dependencies on are supported. Indirect dependencies configurations are also available (e.g. A depends on B and B depends on C - A will have C's properties available).
  • <property name> — the name of the server build property of the build configuration with the given ID.


  • <VCS root ID> — is the VCS root ID as described on the Configuring VCS Roots page.
  • <VCS root property name> — the name of the VCS root property. This is VCS-specific and depends on the VCS support. You can get the available list of properties as described above.

If there is only one VCS root in a build configuration, the <VCS root ID>. part can be omitted.


Agent-specific properties are defined on each build agent and vary depending on its environment. Aside from standard properties (for example, teamcity.agent.jvm.os.name or teamcity.agent.jvm.os.arch, etc. — these are provided by the JVM running on agent) agents also have properties based on installed applications. TeamCity automatically detects a number of applications including the presence of .NET Framework, Visual Studio and adds the corresponding system properties and environment variables. A complete list of predefined agent-specific properties is provided in the table below.

If additional applications/libraries are available in the environment, the administrator can manually define the property in the <agent home>/conf/buildAgent.properties file. These properties can be used for setting various build configuration options, for defining build configuration requirements (for example, existence or absence of some property) and inside build scripts. For more information on how to reference these properties, see the Defining and Using Build Parameters in Build Configuration page.


  • Make sure to replace "." with "_" when using properties in MSBuild scripts; e.g. use teamcity_dotnet_nunitlauncher_msbuild_task instead of teamcity.dotnet.nunitlauncher.msbuild.task
  • _x86 and _x64 property suffixes are used to designate the specific version of the framework.
  • teamcity.dotnet.nunitlauncher properties cannot be hidden or disabled.

Wiki Markup


This is not supported

You can disable the automatic detection of the predefined properties by editing the {{buildAgent.properties}} file and adding the *disableDotNetDetection* property.

{note}Please note that {{disableDotNetDetection}} property is case-sensitive.{note}

This property can have the following values:
|| Value || Description \\ ||
| empty string | All versions of .NET Framework will be detected and added to the Agent Properties |
| '*' | All existing versions of .NET Framework will not be detected and thus not included in the Agent Properties |
| version number(s) (Values should be separated by commas) | Excludes versions of .NET Framework starting with that number |
| 'windowsSDK6.0' or 'w' | Excludes Windows SDK 6.0 |
| VS<X> | Excludes Visual Studio version <X>, where <X> can be 2003, 2005, 2008, 2010, 2012, 2013 or left blank to exclude all existing versions of Visual Studio \\ |
|| Examples || Description \\ ||
| {{disableDotNetDetection=3}} | Excludes .NET Framework 3.0, 3.5 and all other versions starting with 3 |
| {{disableDotNetDetection=1.1,2.0}} | Excludes .NET Framework versions 1.1 and 2.0 |
| {{disableDotNetDetection=w,2.0,VS2003}} | Excludes Windows SDK 6.0, .NET Framework 2.0 and Visual Studio 2003 |


Agent Environment Variables


When a build agent starts, first the installed JDK and JRE are detected; when they are found, the Java-related environment variables are defined as described in the section below.


The environment variables are defined only if they are not already present in the environment: if a started agent already has the Java-related environment variables set, the are not redefined.


  • It is checked whether the JAVA_HOME, JDK_HOME, JRE_HOME variables are defined
  • The PATH environment variables are searched and the discovered directories are checked for containing Java
  • If defined, a custom directory on an agent is searched for Java installations. Defining a custom directory to search for Java is described below.

OS-specific locations



Defining Java-related Environment Variables

For each major version V of java, the following variables can be defined:

  • JDK_1V
  • JDK_1V_x64
  • JRE_1V
  • JRE_1V_x64

The JDK variables are defined when the JDK found, the JRE variables are defined when the JRE found but the JDK is not found.
The _x64 variables point to 64-bit java only; the variables without the _x64 suffix may points to both 32-bit or 64-bit installations but 32-bit ones are preferred.
If several installations with the same major version and the same bitness but different minor version/update are found, the latest one is selected.