Build configuration ignores template parameter: `<Root project>` value takes precedence

Symptoms

When a parameter exists at both the <Root project> level (or any parent project) and the build configuration template level, build configurations linked to the template resolve the parameter to the parent project value, not the template value.

For example:

• <Root project> defines certificate.file = signtool.pfx
• Build configuration template defines certificate.file = template.pfx
• A build configuration linked to the template resolves %certificate.file% to signtool.pfx (the <Root project> value), not template.pfx

Overriding the parameter directly at the build configuration level does take effect. That level has the highest priority.

Environment

• Customer type: Personal and commercial customers
• Region affected: All regions
• Product affected: TeamCity (all current versions, including 2025.03)

Cause

This is the documented parameter resolution behavior in TeamCity, not a defect. Project-level parameters (including those at <Root project>) take precedence over template-level parameters in build configurations that inherit from a template.

The resolution order, from highest to lowest priority, is:

1. Build configuration parameter
2. Parent project parameter (including <Root project>)
3. Template parameter
4. Agent / predefined parameters

Reference: Configuring Build Parameters: Parameter Values.

TW-37239 is an open feature request to invert this so template values would win over parent-project values. It has been open since 2014 with 35 votes and 7 linked duplicates, with no planned timeline.

Resolution

Overriding the parameter at each affected build configuration works but is impractical at scale (hundreds of build configurations). These approaches scale better:

Option 1: Move the parameter out of <Root project>

Define the parameter only in the specific projects that need the <Root project> value. The template value then applies everywhere else.

Option 2: Use distinct parameter names

Define a separate parameter at the template level (for example, template.certificate.file) and reference that name from build steps. This avoids reusing a parameter name that is also defined at the root level.

Option 3: Override at an intermediate parent project

If the affected build configurations sit under a single parent project (or a small number of them), define the parameter at that project level. The value shadows the <Root project> value for everything underneath, so individual build configurations need no changes.