Many thanks for sharing all of these efforts. I'm having some trouble implementing the QueueNewBuild activity, and was wondering if I'm missing something stupid.
I'm assuming that based on how the QueueNewBuild classes are broken out, that I want the following steps in my workflow:
1) GetBuildServer, which returns an IBuildServer object to a currentBuildServer
IBuildServer variable I have made. I am passing BuildDetail.BuildServer.TeamProjectCollection.Uri.ToString()
as the TeamFoundationServerURL In argument
2) GetBuildDefinition, where I pass in currentBuildServer and "MyTeamProject" and "MyBuildDefinitionName" strings, and store the result to a
desiredBuildDefinition IBuildDefinition variable.
3) QueueNewBuild where I pass in the desiredBuildDefinition and currentBuildServer to hopefully queue the build.
Step 1 appears to be working; if I run the build in diagnostic mode, currentBuildServer looks to be properly set to some Microsoft.TeamFoundataion.Build.Client.BuildServer object.
The build errors on Step 2 though, throwing the following (http://engtfs:8080/tfs/engineering is our Team Project Collection URI):
Team Foundation services are not available from server engtfs\Engineering. Technical information (for administrator): Cannot access a disposed object. Object name: 'Microsoft.TeamFoundation.Client.TfsTeamProjectCollection'.
The TfsTeamProjectCollection object referred to I assume is what's used to get the IBuildServer object in Step 1, but just the IBuildServer object is passed into GetBuildDefinition.cs, so I wasn't sure how to make it persist from one WF step to the other.
As a workaround, I was going to throw all of the steps and inputs into a single code activity, but I would like to keep the less-obfuscated approach of the multiple steps if anyone know what might be wrong.