Orcas SP1 TFS Build Changes

Brian Harry put up a post on the improvements that will be available in the upcoming Team Foundation Server 2008 SP1 release.  Here’s some more in depth info on two of the TFS Build changes:

1. Conditionalize builds on the trigger.

There are actually a few changes here…  Essentially we exposed a property on IBuildDetail called Reason that tells you why the build was started.  Reason is an enum of type BuildReason, and can have the following values:

  • Manual.  This indicates that the build was manually started (e.g. by a user through the Queue Build dialog).

  • IndividualCI.  This indicates that the build was started due to a checkin, and that it’s build definition is set up to build on each checkin.

  • BatchedCI.  This indicates the the build was started due to one or more checkins, and that it’s build definition is set up to accumulate checkins.

  • Schedule.  This indicates that the build was started due to the time, and that it’s build definition is set up to build on a regular schedule if changes have occurred.

  • ScheduleForced.  This indicates that the build was started due to the time, and that it’s build definition is set up to build on a regular schedule whether or not changes have occurred.

In addition to exposing this new property on IBuildDetail, we have also exposed it as an output property of the GetBuildDetails task and as an MSBuild property available in your TfsBuild.proj files.  This could be useful in a couple situations:

  • You can use it to detect whether a build of an individual definition is running as a result of being triggered by the system or as a result of being started manually by a user.  It may be useful to distinguish these two cases and set various properties to different default values, etc.

  • When pointing more than one build definition at the same TfsBuild.proj file (e.g. so that you can use the same script for your CI build and your Nightly build) you can use it to detect which build definition a particular build is for.  Again, it may be useful to distinguish these two cases.

For example, if you only wanted to generate a custom build number for your nightly build, you could do something like this:

  <Target Name=BuildNumberOverrideTarget Condition= ‘$(Reason)’ == ‘Schedule’ >
MyBuildNumberGenerator TeamFoundationServerUrl=$(TeamFoundationServerUrl) BuildUri=$(BuildUri)>
Output TaskParameter=BuildNumber PropertyName=BuildNumber />

2. Reduce build log noise.

In Orcas RTM, we tried to reduce the dependency of TFS Build on the names of particular targets, tasks, events, etc. in MSBuild.  The goal was to make it more usable by people who wanted to radically customize their build process, and in general I think we did a pretty good job here.  Unfortunately, one side effect of the associated changes was the presence of lots of “noise” build steps in the Build Details dialog.  In particular, each project-to-project reference resulted in three build steps of the form:

  • Project ‘project’ is building project ‘dependent project’ for targets ‘GetTargetPath’.

  • Project ‘project’ is building project ‘dependent project’ for targets ‘GetNativeManifest’.

  • Project ‘project’ is building project ‘dependent project’ for targets ‘GetCopyToOutputDirectoryItems’.

These build steps should all magically disappear when Orcas SP1 is installed. 

To accomplish this, we added a property called TargetsNotLogged to the TFS Build targets file that specifies the target names for which build steps should not be added when our logger receives ProjectStarted events, and made the default value of this property ‘GetTargetPath;GetNativeManifest;GetCopyToOutputDirectoryItems’.  If you want these build steps back, just set the property to the empty string in your TfsBuild.proj file.  If you want to exclude other targets as well, just set the property to your desired semicolon-delimited list of excluded targets in your TfsBuild.proj file.

(NOTE: I modified the above text on 12/30/2008 to make it more clear that the TargetsNotLogged property should be modified by overriding the default in your TfsBuild.proj file(s), not by modifying it in place in the TFS Build targets file.)

Next week I’ll post on Detect test result and/or Dynamically created properties

Comments (10)

  1. Balaji.Dave says:

    Hi Arron

          Is there any performance improvement on BUILD in Orcas SP1.


    Balaji Dave

  2. Garry Trinder says:

    Yes, there are several performance improvements:

    (1) The reduced build log noise also corresponds to reduced server calls during compilation, which should speed things up a bit.

    (2) There were several database tweaks for SP1 (a new index, modified stored procedures, etc.) that should speed things up a bit as well.

    (3) Certain information nodes are now updated in bulk (in one server call) rather than individually (in multiple server calls).

    The amount of benefit you see from these changes will depend on the specifics of the solutions you are building, but everyone should see some performance gains.


  3. John Powell on Team Explorer Window Won’t Open Or Is Blank. Alanpa on James Whittaker on software testing….

  4. Team Explorer 2008 SP1: Miglioramenti nella Build

  5. danielm says:

    Hi Aaron,

    I have just installed TFS 2008 SP1 on our server and build machines,

    however I am still getting those addional build steps in our build logs ( ‘GetTargetPath’, ‘GetNativeManifest’ and ‘GetCopyToOutputDirectoryItems’).  Is there anything else that I have to do to our build scripts to remove these entries?



  6. mfreidge says:

    Hi Aaron,

    After upgrading to TFS 2008+SP1 from TFS 2005 I have problems related to incorrect/corrupted tfsBuild database (in particular column Reason).

    Could you look at http://social.msdn.microsoft.com/Forums/en-US/tfssetup/thread/fa81ffed-4574-410e-be7f-7a86462f15fc thread and give me any ideas if possible?

  7. joverbeek says:

    Hi Daniel,

    We had the same problem, it looks like TFS SP1 doesn’t update Microsoft.TeamFoundation.Build.targets on the build machines. I copied the file manually from a michine that has the latest (SP1) version, and then the additional build steps disappeared.



  8. I did a post a while back on a change in TFS Build SP1 which reduced build log noise by cutting out the

  9. j.oliver says:

    Regarding not updating the Microsoft.TeamFoundation.Build.targets file – we experienced this and after some testing deduced that if you have previously modified the targets file, the SP1 installer will not overwrite your copy.  It doesn’t warn or log or tell you about this either though!  We installed on a vanilla machine, then manually merged our changes in.

  10. shail_k_patel says:

    Could you please post configuration setting where we need to set TargetNotLogged property in TfsBuild.proj file?  I don’t know where to set that property.