JetBrains TeamCity Blog

As we promised, we continue the configuration parameters story started in the previous post. Today, I’d like to tell you about .NET related properties.
TeamCity .NET plugins provide a bunch of predefined properties indicating that .NET Framework/SDK/Visual Studio/Mono are detected on build agent. Previously you could refer to these properties as to system properties. Now we’ve changed it.

We decided to turn all these properties into configuration parameters, and therefore we’ve converted all refernces to such properties detected in TeamCity to keep builds running. However, it’s not possible to convert references used from a build script. To workaroud the issue you can add system property in build agent configuration or use compatibility mode switch in TeamCity properties:

• teamcity.dotnet.properties.compatibility.mode with value true
• dotNetPropertiesCompatibilityMode configuration parameter with value true in a build configuration settings.

Here is the list of changed parameters:

Note, there will no longer reported .NET Framework configuration parameters without explicit bitness (i.e. x86 or x64).

After our posts about TeamCity’s new multiple build steps (previously called “multiple build runners“) feature and further changes in .NET build runners, I believe that plugin developers might have some questions to be clarified.

So today, I’m going to shed some light on the major agent-side API changes that we’ve made to support multiple build steps. I hope this post will help you to painlessly improve your build runner plugins.

AgentRunningBuild interface no longer represents parameters for a build runner. We’ve introduced new interface BuildRunnerContext that provides parameters for build runner. Starting with TeamCity 6.0 AgentRunningBuild will only describe a build.

Note that there is no getter for BuildRunnerContext in AgentRunningBuild. AgentLifeCycleListener interface now provides BuildRunnerContext in build step related methods.
We’ve added runnerFinished event and updated almost all build-related events signatures to contain AgentRunningBuild and BuildRunnerContext instances. So, in most cases one will not need to cache those instances in a plugin code.

So if you ask yourself, what to do to improve your build runner, the answer is simple. If your build runner is implemented by extending CommandLineBuildService, you need to extend BuildServiceAdapter abstract class. This class contains all getters for all parameters you may need in build runner implementation.

Of course, this post doesn’t cover all the details, but only gives general tips. So don’t hesitate to ask questions, I’ll be glad to answer.