Bill Wang’s Blog

November 5, 2008

BuildStep task statuses

Filed under: Uncategorized — Tags: — Bill @ 11:33 am

The BuildStep task enables us to add custom build steps to a team build report. This task exposes 3 possible statuses that we can set to:

  • Succeeded
  • Failed
  • Stopped

Plus one more status which is not exposed:

  • InPrograss

The default status of a build steps is InPrograss. If we don’t set the status, the build step status in the result build report will be:

  • Failed if the team build is aborted. When we stop a team build, all build steps with InProgress status will be marked to Failed.
  • InPrograss if the build completes normally.

As we already know, we can open the build report before the build is finished. When the build engine meets a BuildStep task declaration, it will add an item to the “Build steps” section in the team build report. We usually declare a BuildStep task with the default status InPrograss to show the build engine is performing a set of tasks, then we set the status of the BuildStep when our tasks are finished.

The following example demonstrate how to organize build step declaration and evaluation. The example overrides AfterDropBuild target to run some tasks there. If no error occurs, the status for the build step will be set to Succeeded. If there’s an error encountered in AfterDropBuild target, HandleMyBuildStepFailed target will be executed.

<Target Name=“AfterDropBuild”>
<BuildStep TeamFoundationServerUrl=“$(TeamFoundationServerUrl)”
BuildUri=“$(BuildUri)” Name=“MyBuildStep”
Message=“My build step is executing.”>
<Output TaskParameter=“Id” PropertyName=“MyBuildStepId” />
<!–Add tasks here–>
<BuildStep TeamFoundationServerUrl=“$(TeamFoundationServerUrl)”
BuildUri=“$(BuildUri)” Id=“$(MyBuildStepId)” Status=“Succeeded” />
<OnError ExecuteTargets=“HandleMyBuildStepFailed”/>
<Target Name=“HandleMyBuildStepFailed”>
<BuildStep TeamFoundationServerUrl=“$(TeamFoundationServerUrl)”
BuildUri=“$(BuildUri)” Id=“$(MyBuildStepId)” Status=“Failed” />

What I have missed? Oh, the Stopped status. If the status of BuildStep task is set to Stopped, the whole team build will be stopped. Thus we rarely use this status.

October 31, 2008

How to configure tests based on build configuration

Filed under: Uncategorized — Tags: — Bill @ 11:52 am

Team build provides ability to build both Release and Debug bits in the same build. If there are unit tests, it will run tests for both Release bits and Debug bits. Sometimes, we might want to run tests or use run configure files based on the build configuration. For example, you might want to get code coverage for the Debug build, while you don’t want to instrument the Release build.

The target CoreTestConfiguration in the team build runs for each build configuration. So, we can override target BeforeTestConfiguration to set properties used by TestToolsTask based on build configuration.

The following code demonstrate how to parse in test run configure file based on the build configureation:

<Target Name=”BeforeTestConfiguration”>
<PropertyGroup Condition=”‘$(Configuration)’==’Debug'”>
<PropertyGroup Condition=”‘$(Configuration)’==’Release'”>

Custom build script succeeded while the Team Build failed

Filed under: Uncategorized — Tags: — Bill @ 11:52 am
Aaron Hallberg described how to kick off a custom build script in a team build. Please reference A Minimal TFSBuild.Proj File for more information. The interesting thing is that you may notice the team build fails even if the custom script executed successfully.

In a team build, the overall build status might be Succeeded, Partially Succeeded and Failed. The overall status will be


  • Succeeded if no error occurs.
  • Partially Succeeded if CompilationStatus is succeeded but error occurs in other part of the build
  • Failed if CompilationStatus is failed.

CompilationStatus and TestStatus are 2 properties created during a team build. When the build service is about to determine the overall build status, it checks CompilationStatus, TestStatus and other occurred errors. The default value for CompilationStatus and TestStatus is Unknown. Thus when you kick off custom build script by overwriting EndToEndIteration target, if CompilationStatus and TestStatus are not set, the overall status will be Failed even if no errors are listed in the build log. And SetBuildProperties task can be used to set them:

<SetBuildProperties TeamFoundationServerUrl=”$(TeamFoundationServerUrl)”
TestStatus=”Succeeded” />
After both CompilationStatus and TestStatus are set to Succeeded, the only factor that determines the overall build status will be an internal log property that tracks whether any error occurs. If there’s no error in the custom build script, then the overall build status will be Succeeded.


Create a free website or blog at