Hello TFSBuildExtensionCommunity,

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.

Thanks much!

--jdavidi

Hi jdavidi,

This particular custom activity isn't ready for prime time just yet so we apologize for any inconvenience.  Would you able to copy/paste the XAML from this particular area of your build process template?  Also, do you have a local variable defined within scope that you are storing the IBuildServer?

Alternately, you can also pass in the BuildServer property off of the build's IBuildDetail directly into the activity.

Hi Ed,

Thanks for the reply.  Your tip to just use the BuildDetail.BuildServer was enough to move this forward to completion, can't believe I didn't notice that sitting right there. when I was drilling further trying to pass BuildDetail.BuildServer.TeamProjectCollection.Uri.ToString() to GetBuildServer.  So that essentially eliminated my need for Step 1.  (To answer your question, yes I had been attempting to pass BuildDetail.BuildServer.TeamProjectCollection.Uri.ToString() to GetBuildServer and store the Result as an IBuildServer variable called currentBuildServer .)

My now-functioning, 2-step cleaned-up-of-superfluous-variables sequence is as follows:

    <Sequence DisplayName="Queue another build" sap:VirtualizedContainerService.HintSize="1950,208">
      <Sequence.Variables>
        <Variable x:TypeArguments="mtbc:IBuildDefinition" Name="installerBuildDefinition" />
        <Variable x:TypeArguments="mtbc:IQueuedBuild" Name="queuedInstallerBuild" />
      </Sequence.Variables>
      <sap:WorkflowViewStateService.ViewState>
        <scg:Dictionary x:TypeArguments="x:String, x:Object">
          <x:Boolean x:Key="IsExpanded">True</x:Boolean>
        </scg:Dictionary>
      </sap:WorkflowViewStateService.ViewState>
      <ta:GetBuildDefinition BuildDefinitionName="Install-CostGuard" BuildServer="[BuildDetail.BuildServer]" sap:VirtualizedContainerService.HintSize="200,22" Result="[installerBuildDefinition]" TeamProjectName="Infrastructure" />
      <ta:QueueBuild BuildController="{x:Null}" ProcessParameters="{x:Null}" BuildDefinition="[installerBuildDefinition]" BuildServer="[BuildDetail.BuildServer]" sap:VirtualizedContainerService.HintSize="200,22" Priority="[QueuePriority.Normal]" Result="[queuedInstallerBuild]" />
    </Sequence>

Before I got this to work earlier, the build log threw the following exception on the QueueBuild step:

Server was unable to read request. ---> There is an error in XML document (1, 332). ---> Instance validation error: '0' is not a valid value for QueuePriority.

Oddly enough, it only throws this error if the build is run with Normal or Detail logging set; Diagnostic verbosity for whatever reason seems to swallow the error.

I'm pretty new to XAML (TFS 2010 is our first exposure to it), but noticed that the QueuePriority InArgument was decorated with a [DefaultValue(QueuePriority.Normal] attribute--I guess this isn't taking.  So I just threw [RequiredArgument] in its stead, updated the xaml to include QueuePriority.Normal and all is now well.

Time for me to merge into my production flows! 

Again, thanks a mil.

--jdavidi

Good to hear you are unblocked!

It's funny because we were just discussing the problems of trying to provide default workflow activity parameter values this morning :)  Haven't figured it out just yet.