Today I needed to use the TFS API to get the last successful green build info from TFS so I thought whilst I'm still learning PowerShell I'll give it a go in that.  Anyway here's what I came up with, I could have condensed the lines but whilst I was debugging in PowerShellGUI (which is REALLY good for PowerShell development!) I wanted to see what each method returned.

 [void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.TeamFoundation.Client")  
 [void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.TeamFoundation.Build.Client")  
 [void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.TeamFoundation.Build.Common")  
   
 $tfsCollectionUrl = "http://SERVERNAME:8080/tfs/COLLECTION"
 $server = new-object Microsoft.TeamFoundation.Client.TfsTeamProjectCollection(New-Object Uri($tfsCollectionUrl))
 $buildServer = $server.GetService([Microsoft.TeamFoundation.Build.Client.IBuildServer])
 $buildDetail = $buildServer.QueryBuilds("TEAM_PROJECT", "BUILD_DEFINITION_NAME") | where { $_.BuildDefinition.LastGoodBuildUri -eq $_.Uri } #| select BuildNumber
   

$buildDetail will contain an IBuildDetail object as described here: http://msdn.microsoft.com/en-us/library/microsoft.teamfoundation.build.client.ibuilddetail.aspx

I had an interesting one today whilst getting an emergency fix out, well trying to!  Here's the scenerio:

Version 2.0.0.6734 of product X has been deployed with a bug. Oh no we need to get a fix out quickly!  That's ok though we have a good CI process of labeling the builds upon every build so we can easily go back to TFS and extract the bad code that needs fixing via the label "6734".

Ok so off I go back to TFS, view history and look at the labels...Er where are the labels for my previous build!?  TFS has removed them!...Arrghhhh damn you TFS.

Turns out by default the TFS retention policy will delete everything so as it's good practice to label your builds it makes sense to keep the labels. 

To change the retention policy in TFS 2010 you can do it per build definition as follows:

If you need to keep your test results just change the corresonding setting.

Had a nasty one today that had me scratching my head.  On our TFS build server for one particular build it suddenly stopped when we executed tf.exe  checkout commands with the error:

Unable to determine the workspace

I tried a few things but in the end it was down to the workspace cache so to resolve:

- Log in to the build server as the account running the Visual Studio Team Foundation Build service

- Shell out to a command prompt and make sure you can execute the tf.exe command (normally in %programfiles%\Microsoft Visual Studio 10.0\Common7\IDE )

- run tf workspaces /remove:*

- run tf workspaces /s:http://tfscontroller:8080   (performs a refresh)

Try the build again!

If it still fails then it's possible that the file you are trying to checkout is not actually part of the workspace in which the case the error message is actually right.