Jason Prickett's Blog : Team Build

TFS 2010 – What’s New On The Build Explorer?

Jason Prickett — Mon, 15 Jun 2009 16:39:47 GMT

The Queued Tab:

So, as you can see not much has changed on the Queued tab of the build explorer since VSTS 2008, but if you look close, there are a few changes.

1. There is a new filter you can apply - “Only show builds requested by me”. This filter will limit the results to only those builds you directly caused by checking in or manually queuing it. This is really helpful when there are lots of builds for your team project and you only care about yours.

2. There is a new column on the left. If you hover over it, you see it’s the “Reason” column. This shows you what caused the build to start. In the picture above, you can see two builds. The one with the icon was triggered by a checkin and the other was manually queued.

3. All columns except the image columns are sizeable. They start off adjusted to their data, but you can change that.

The Completed Tab:

Likewise on the Completed tab, not much has changed. In fact, it has the same changes as the Queued tab – a new filter, a new column, and sizeable columns. They work the same here as on the Queued tab.

TFS 2010 Beta1 – Build DEtails View Log View section

Jason Prickett — Mon, 18 May 2009 21:55:31 GMT

The picture above is of the Log View of the new Build Details View in Visual Studio Team System 2010. See my previous post on the Summary View for more information on the items above the words “Activity Log”. The log view can be seen by opening an in-progress build like the one shown above or by clicking the “View Log” link on a completed build.

Here are some things to notice about this view:

1. There are links (“Next Error” and “Next Warning”) to quickly jump to the first or next error or warning. The Log View can be quite long so this should help you find the errors more quickly. Of course, the error messages will also show up on the Summary view, so you may not need to come here at all.

2. The “Show Property Values” link will expand the log view even further and show you all the property values that were logged for the build activities. Because these values can greatly increase the size of the log, they are turned off by default.

3. On the right is a duration column. This shows you the duration of each build activity. If you are trying to speed up your builds, this information should help you determine what build activities are taking the longest. Note that the values roll up. So, parent duration values are approximately the sum of their children’s durations.

4. The data is presented in a hierarchy. This hierarchy maps perfectly to the build process template (more on that in a later post). This allows you to follow the path that the build took through the template and possibly correct problems with your custom templates. Note: showing the property values is important to understanding the flow.

5. The “play” icon in front of some of the lines indicates that those build activities are currently in progress. Another way to follow along as a build follows the process template logic. Note that a parent activity is considered in-progress if any of its children are in-progress.

6. Lastly, like the summary view, there is a slider in the bottom right corner that allows you to zoom in or out on the log view.

I hope this gives you some more insight into the 2010 release!

tFS 2010 Beta1 – Build Details View Summary section

Jason Prickett — Tue, 12 May 2009 23:23:16 GMT

The picture above is of the new “Build Report” in TFS 2010. I prefer the term Build Details View, because it is not actually a TFS report object. The view has completely changed, so let me take you on a quick tour:

1. The first thing you may notice is that this is a failed build. The icon in the upper left corner notifies you of the status (in progress, succeeded, partially succeeded, or failed).

2. The next thing on that same line is the build number “Build HW_20090512.3” and the status is repeated as a word. Then comes the Build Quality. That’s right you can change the build quality right here on the build details view.

3. The links on the next line allow you to view the summary page (that’s the page we see above), view the log page (need another post for that one), open the drop folder, and delete the build.

4. The bar graph - now things really start getting interesting. This is a graph of the last 9 builds for the same definition. The small triangle denotes this build. The height of the bars show the relative time that the build took and the color indicates the status. You can also hover over the bar to get a tool tip with that information. This graph is really helpful when the build is in progress, because you can see how long the other builds took and guess how much longer this one will be :)

5. The rest of the information beside the graph includes who started the build (jpricket), what definition was triggered (Build HW), what changeset was built, how long the build took, what build controller was used, and when it was started. A lot of info in a small space!

6. Latest Activity – this section includes who last modified the build and when. It also lists any work items that were opened during the build. Notice the link! Clicking on the link will open the work item :)

7. Summary – This section contains a lot of information. The main purpose is to report the results of the build. It is divided by Configurations with another section at the end for any Errors or Warnings that may have happened outside of a configuration. Each configuration has four sections: errors and warnings, projects/solutions compiled, test results, and code coverage results. Notice the links! You can go to the actual build log for the configuration, or you can click on a particular error and go straight to the source line. (this actually downloads the file and opens the exact version that the Build Machine was attempting to build).

8. Impacted Tests – this section is completely new and allows you to see which tests were impacted by the changes that were checked in.

9. If there were test results, you would also have a link to them, just like you did in TFS 2008.

10. Associated changesets and work items will also show up in their own sections for a successful build. They also have links to open the Changeset details or the Work Item.

11. Oh, and that slider in the bottom right hand corner allows you to zoom in or out.

Hopefully this encourages you to download the Beta and start playing with it!

Keeping Version Control Labels When Team Builds Are Deleted in TFS 2008 SP1

Jason Prickett — Tue, 30 Sep 2008 16:42:00 GMT

We have had quite a few complaints about the fact that we delete the labels created during a build when the build is deleted. The reason this behavior was added was to keep from creating a ton of labels for CI builds. But some customers still want the labels to exist after the build has been deleted. Long term we will allow you to choose what gets deleted with the build. But for now, we have made a change that is available in Team Foundation Server 2008 SP1 that you should like.

If you want to always keep labels even though builds are being deleted by retention policies or manually, you can simply make a change on the Application Tier in the web.config file. Here are the details:

1) Locate the Team Foundation Web.Config file on the Application Tier.

2) Add a flag to the Web.config file to specify that labels should not be deleted. When this value is present, labels are not deleted from Source Control. The default behavior is still the same as RTM; labels get deleted with their corresponding builds. Here is an example of what that line in the web.config file would look like:
<add key="PreserveLabelsOnBuildDeletion" value="True"/>

3) Run IISReset to force the changes to be used.

I hope this helps those customers that use labels a lot.

Filtering the Build Status Change Event (BuildStatusChangeEvent)

Jason Prickett — Tue, 13 May 2008 15:10:00 GMT

In an previous post (long long ago), I described some scenarios around why you would want to subscribe to change the work item tracking subscription to the build completion event. The purpose there was to help users "correct" the subscription that came out of the box. In this post, I would like to answer a question I got from a user about how to subscribe to the other build event - BuildStatusChangeEvent. The question was basically this: How do I get notified when the build quality changes from 'X' to 'Y'?

First, let me say that the name of this event is all wrong. It does not fire when the status of a build changes, but rather when the quality field of the build changes. In the future, it may do more, but not for now. The name aside, it is important to look at the structure of the xml that is sent when the event fires. It is actually very short. Here is an example:

<?xml version="1.0" encoding="utf-16"?><BuildStatusChangeEvent xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<TeamFoundationServerUrl>http://jpricket-test:8080</TeamFoundationServerUrl>
<TeamProject>TestProj</TeamProject>
<Title>TestProj Build CSharp_Tests_20080507.3 Quality Changed To Ready for Deployment</Title>
<Id>CSharp_Tests_20080507.3</Id>
<Url>http://jpricket-test:8080/Build/Build.aspx?artifactMoniker=9</Url>
<TimeZone>Eastern Daylight Time</TimeZone>
<TimeZoneOffset>-04:00:00</TimeZoneOffset>
<ChangedTime>5/9/2008 3:05:33 PM</ChangedTime>
<StatusChange>
    <FieldName>Quality</FieldName>
    <OldValue>Lab Test Passed</OldValue>
    <NewValue>Ready for Deployment</NewValue>
</StatusChange>
<ChangedBy>NORTHAMERICA\jpricket</ChangedBy>
</BuildStatusChangeEvent>

The important bit is under the StatusChange node which also makes it a little more interesting than the last post that I did. To filter this event in any useful way requires you to know a little more about XPath. Or at least how the "path" to the OldValue and NewValue fields are formed. It's actually pretty simple. Ignore the root node BuildStatusChangeEvent and then use a slash between each node that you need to reference in the path. For example, if you want to filter on the NewValue field, you might want to use the filter expression 'StatusChange/NewValue'='Ready for Deployment'.

Finally, here are some scenarios that you might find yourself in:

I want to be notified when a build is marked as "Released"
I want to be notified when the build quality is removed (only applies to 2008 and above)
I want to be notified when the build changes from "Rejected" to "Released"

And here are the filters that correspond to those scenarios:

'StatusChange/NewValue'='Released'
'StatusChange[count(NewValue) = 0]' <> null AND 'StatusChange[count(OldValue) > 0]' <> null
'StatusChange/OldValue'='Rejected' AND 'StatusChange/NewValue'='Released'

The first and last are exactly what you might expect. But the second filter was quite a challenge. It turns out that when OldValue or NewValue are null, they are not included in the XML at all. So, to see if NewValue was set to null, we have to get the StatusChange nodes that have a count of NewValue nodes equal to zero. If any StatusChange nodes are returned then that half of the filter is true. The other half is just the opposite. We want to make sure that the StatusChange node has at least 1 OldValue field. The syntax of the xPath query is a little hard to get right, but it does exactly what we want.

Hopefully, this will help you with this and other TFS Events! I have attached the code that I used to add these subscriptions to my server. It is very similar to the code in my previous post.

Where's the TfsBuild.proj file for this Definition?

Jason Prickett — Mon, 05 May 2008 15:58:05 GMT

In Team Build 2005, the "definition" of the build was the same as the TfsBuild.proj file. However, in 2008, we changed this so that the TfsBuild.proj only held some of the information for the build. The rest of the information (like retention policies, workspace definition, and triggers) were all stored in the build database. 2008 even allows two different Build Definitions to share the same TfsBuild.proj file.

Unfortunately, due to this diversion of "definition" and source control file (TfsBuild.proj), users have found it difficult to easily get to the TfsBuild.proj file from the UI. Okay, you can find it, but you have to follow this procedure:

1) open the associated definition from team explorer

2) go to the project file tab

3) write down the server path

4) open Source Control Explorer

5) Navigate to the right server path

6) look for the file TfsBuild.proj

Well, in 2008 SP1, you don't have to do all that work any more. Simply right click on the definition in team explorer and choose "View Configuration Folder". This menu item will do all the of the above for you. In future versions, we may even dream of world without TfsBuild.proj files :o

For more information on all the new features in Team Foundation Server 2008 SP1, see bharry's blog about them.

Changing the recursion type for the initial "Get" that Team Build does

Jason Prickett — Mon, 10 Dec 2007 16:27:00 GMT

In Visual Studio Team System 2008, the build machine downloads the files that it needs to launch MSBuild before it creates any workspaces. Because this initial "get" is before MSBuild is called, users don't get much say in what gets downloaded. By default, the build machine downloads all the files in the ConfigurationFolderPath of the build definition that is being built. You specify that path in the Build Definition dialog. Everthing at the root of that folder is then downloaded before the build starts.

The problem that some people have run into is that we only download the root of the folder. They have some assemblies or other specific build files that are nessesary in subfolders of that location. Luckily we thought of that. You can change the download parameters so that all subdirectories are downloaded as well. Be careful, however, if you specify to download everything, you will get everything under that folder that exists in version control. You cannot cloak anything out. Also note that this "fix" is per build machine, not build, and not build definition.

Here are the steps:

Log into the build machine that you want to change (you probably need to be an admin on the box).
Locate the TFSBuildService.exe.config file (most likely in "C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies")
open it in notepad or some other text editor
Near the bottom (before the /appsettings closing tag) add the following line:

<add key="ConfigurationFolderRecursionType" value="Full" />
other values include OneLevel or None. OneLevel is the default.

Save the file
Restart the "Visual Studio Team Foundation Build Service" from the Services control panel applet.

That's it. I hope this helps!

Stopping a Build -> Cancelling a Workflow

Jason Prickett — Thu, 01 Nov 2007 15:11:00 GMT

This post continues my quest to learn more about Windows Workflow and share that experience with you. It assumes knowledge of Windows Workflow. If you don't understand some of the concepts please take a look at one of the books that I mentioned in my first WF post.

One of the operations that we require is the ability to Stop a Build that is in progress. This corresponds to Terminating a workflow. However, in our investigation of how WF handles Terminate, we discovered that it isn't what we really want. Termination of a workflow does not end the workflow immediately. That's not so bad, but it also doesn't give the workflow a chance to clean up anything (i.e. there are no handlers for termination). So, we looked into Cancellation of a workflow instead of using terminate.

We found that it is really hard to cancel a workflow. First of all there is not a WorkflowInstance.Cancel method. So, if you plan to cancel the workflow from outside the instance, you have a hurdle to jump already. But if your workflow is like ours and you can put your own Activity class at the root, you can leap the hurdle pretty easily. What we did was to have the root activity create a Queue (we called it the cancellation queue) with a well known name (a hard coded Guid). From there it seemed obvious that we could Queue an item to this well known Queue and from within the instance call CancelActivity on the root. But alas, that is not allowed. You can only call CancelActivity on the currently executing activity. Bummer! So, we tried cancelling the executing activity, but that ended up just continuing the execution of the next activity after it which wasn't cancelled. Double Bummer!

So, our final solution was to Throw when we got something in the Queue. Throwing automatically causes all activities to cancel including the active one. It also gives the workflow a place to do any clean up that needs to be done by catching the CancellationException at the top of the workflow.

It wasn't pretty, but we were able to accomplish what we wanted. Here is a summary of the steps that actually worked for us:

In the root level activity (which is our own class derived from one of the WF activities) we create a special Queue just for this situation. The Queue has a constant GUID for the name
From outside the workflow, we get the WorkflowInstance and Enqueue an item into this special Queue.
When an item is enqueued, our activity class Throws a special exception. That causes everything to get cancelled.
Our cancellation handlers can do any clean up.
We have a special fault handler that also catches this special exception and eats it, so that the workflow completes normally.

My Introduction to Windows Workflow Foundation (WF)

Jason Prickett — Tue, 09 Oct 2007 14:59:00 GMT

Team Build is a build workflow tool. It manages how and when builds are performed. Currently (in VS2005 and VS2008), that workflow was written in the language of MSBuild. This allows us a lot of flexibility and power on the machine that runs the build. However, modifying the MS.TF.Build.Targets file that contained the description of the workflow was heavily discouraged and by no means easy. So, how can we make changing the workflow of the build easier. The first step (we believe) is to change the language that the workflow is described in. Windows Workflow is a natural choice. As we look at using Windows Workflow within Team Build, I will attempt to write some useful posts on things that we have discovered or realized. Mostly things that the books don't talk about. This is my first attempt...

First let me tell you about the books that I have read on WF. I read Bruce Bukovics' "Pro WF" first. This is a great starter for a developer wanting to write WF solutions. Bruce covers all of the functionality you would need to know. But, if you want to host WF and allow your users to manipulate the workflow directly, you need more details about how it works. The second and last book that I read on WF was "Essential Windows Workflow Foundation" by Dharma Shukla and Bob Schmidt. The Essentials book is really brief, but explains how WF Activities really work. If you plan on writing your own custom activities, this book is very useful.

So, what did I learn. More importantly, what have I learned that I didn't get from the books. Well the first thing you should know is that you can represent a workflow in many different ways. The workflow is basically a tree of classes derived from Activity. There are two ways to represent the tree in the Visual Studio world: in code; and in XAML (basically XML). Workflow uses the extension XOML, however, to let VS know that its a workflow and not some kind of WPF stuff (more on WPF in another post). Working with code is the most natural way to deal with the Activity tree. In fact, even if you choose to create your workflow in XOML, VS will create a code behind file for you and compile your XOML into a dll.

The first lesson we learned was... If you want to use XOML only and not do any code behind, you must create the XOML yourself or hand edit the XOML created by Visual Studio. When Visual Studio creates the XOML file, it assumes you will compile it. To compile XOML you need a special attribute on the root element in the XOML that tells the compiler to create a class. The attribute is "x:Class". If you create a XOML workflow in Visual Studio and open that XOML in the XML editor or in notepad, this should be the first attribute of the root element.

When you load a workflow in the workflow runtime, there are two ways to do it. Call load with a type, this implies that the XOML or straight code workflow is compiled. Or you can call load with an xml reader, that has the XOML loaded. If you choose the xml reader option and that x:Class attribute is in the XOML, an error will be thrown by the runtime. However, if you try to compile XOML without that attribute, compilation will fail. So, the first choice you have to make in using XOML files is "To compile or not to compile" - that is the question ;)

TFS 2008 - Running two Build Agents on the Same Machine

Jason Prickett — Fri, 03 Aug 2007 21:20:00 GMT

There have been at least a couple of forum posts from users that would like to run more than one build agent on the same physical machine. The normal reason is that they have more than one TFS server and want to use the machine as a build agent for both.

In this post I will describe how to add another build agent to a machine that already has one installed. The steps are very manual but should be simple enough.

First you need to copy the actual binary for the service and it's config file. The config file is keyed off the name of the binary, and we have to have a separate config file for each.

cd "C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies"
copy TfsBuildService.exe TfsBuildService-2.exe
copy TfsBuildService.exe.config TFSBuildService-2.exe.config

Next you need to edit the new config file to point to the other server and use a different port number.

notepad TFSBuildService-2.exe.config
Search for port and change the port number from 9191 to something new like 8181
There's also another port number for interactive running that defaults to 9192, you should change that one as well. Let's say to 8182.
Now, search for AllowedTeamServer and set the value to the full URL of the new server.
Save your changes.

Now, you can install the new service using sc.exe and get it started.Take note of the spaces after the equals signs in the sc command line.

sc \\jpricket-test create "MyVSTFBuild" binPath= "C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies\TfsBuildService-2.exe" DisplayName= "My Team Build Service"
Now, open up Control Panel\Administrative Tools\Services.
Find "My Team Build Service". Right click on it and open Properties.
On the Log On tab, set it to the service account and password that you want to use.
Hit OK to save your changes and then start the service.

Finally, you have to create a build agent on the other server that points to this new machine and port.

Open Visual Studio
Connect the other TFS server and the correct Team Project
Right click on the Builds node in team explorer and select Manage Build Agents.
Make sure to create one with the correct port number and machine name.
You will also want to change the "Working Directory" to something different that the other instance of the build service uses. I used "$(Temp)\my\$(BuildDefinitionPath)"

Now, you're ready to build on both agents using the same machine.

UPDATE: I neglected to mention that you should reserve the new port number that you decide to use in step 2. You can read up on how to do this with the wcfHttpConfig tool here. Basically you just need to run a command prompt, change to the privateassemblies area of the Visual Studio program directory (usually C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies) and type the following at the command line: wcfhttpconfig.exe reserve DOMAIN\TeamBuildAccount 8181

Creating Fake builds in Orcas with IBuildDefinition.CreateManualBuild

Jason Prickett — Fri, 06 Jul 2007 18:28:00 GMT

In my last post about creating a Fake build, I gave you the code to create a fake build in V1 and I promised to give you the code to do the same thing in Orcas. So, here it is. This code won't work in Beta1 or Beta2, but should work as is when you get an RC or RTM version of Orcas. The CreateManualBuild API was added to the code base post Beta2 cutoff.

So, here's the code:

using System;
using System.Collections.Generic;
using System.Text;
using Microsoft.TeamFoundation.Build.Proxy;
using Microsoft.TeamFoundation.Client;
using Common = Microsoft.TeamFoundation.Build.Common;
using Microsoft.TeamFoundation.Build.Client;

namespace AddFakeBuild
{
    class Program
    {
        static void Main(string[] args)
        {
            AddBuild("http://jpricket-test:8080", "jpricket-070507", "fakebuild23");
        }

        static void AddBuild(String serverName, String teamProject, String buildNumber)
        {
            // Get the TeamFoundation Server
            TeamFoundationServer tfs = new TeamFoundationServer(serverName);

            // Get the Build Server
            IBuildServer buildServer = (IBuildServer)tfs.GetService(typeof(IBuildServer));

            // Create a fake definition (and agent)
            IBuildDefinition definition = AddDefinition(buildServer, teamProject, "FakeDefinition1");

            // Create the build detail object
            IBuildDetail buildDetail = definition.CreateManualBuild(buildNumber);

            // Create platform/flavor information against which test 
            // results can be published
            IConfigurationSummary confSummary = InformationNodeConverters.AddConfigurationSummary(buildDetail, "Debug", "x86", "");
            ICompilationSummary compSummary = confSummary.AddCompilationSummary();
            compSummary.ProjectFile = "Dummy.sln";
            compSummary.Save();

            // Complete the build by setting the status to succeeded and setting the drop location.
            buildDetail.Status = BuildStatus.Succeeded;
            // The drop location is not copied properly from the definition so we have to copy it manually.
            buildDetail.DropLocation = definition.DefaultDropLocation;
            buildDetail.Save();
        }

        private static IBuildDefinition AddDefinition(IBuildServer buildServer, string teamProject, string definitionName)
        {
            try
            {
                // See if it already exists, if so return it
                return buildServer.GetBuildDefinition(teamProject, definitionName);
            }
            catch (BuildDefinitionNotFoundException)
            {
                // no definition was found so continue on and try to create one
            }

            IBuildAgent agent = AddAgent(buildServer, teamProject, "FakeAgent1");

            IBuildDefinition definition = buildServer.CreateBuildDefinition(teamProject);
            definition.Name = definitionName;
            definition.ConfigurationFolderPath = "$/";
            definition.ContinuousIntegrationType = ContinuousIntegrationType.None;
            definition.DefaultBuildAgent = agent;
            definition.DefaultDropLocation = @"\\MySharedMachine\drops\";
            definition.Description = "Fake build definition used to create fake builds.";
            definition.Enabled = false;
            definition.Workspace.AddMapping("$/", "c:\\fake", WorkspaceMappingType.Map);
            definition.Save();

            return definition;
        }

        private static IBuildAgent AddAgent(IBuildServer buildServer, String teamProject, String agentName)
        {
            IBuildAgent agent = buildServer.CreateBuildAgent(teamProject);
            agent.Name = agentName;
            agent.BuildDirectory = "c:\\nobuilddir";
            agent.Description = "Fake build agent used to create fake builds.";
            agent.MachineName = "NoBuildMachine";
            agent.Port = 9191;
            agent.Status = AgentStatus.Disabled;
            agent.Save();

            return agent;
        }
    }
}

There are a couple of things to take note of here. First, you may have noticed that I am creating a Build Definition and a Build Agent. In Orcas, if you try to create a Build without these things existing, you will get exceptions thrown from the server. However, if you were to use existing Definitions and Agents, the code gets a lot smaller. The next thing you should look closely at is the call to definition.CreateManualBuild. This new method encapsulates most of the code that we did in the V1 version.

CreateManualBuild is located off the IBuildDefinition interface. This allows you to get all the definition defaults for free. There are several overloads for this call. The shortest is used here. It takes in a build number and defaults all the other values. If you really had a manual build that you had copied to a drop location, you could specify the drop location as the next parameter to this call. The long version allows you to specify buildNumber, dropLocation, buildStatus, agent, and requestedFor.

In the above example code, the status of the build after calling CreateManualBuild is InProgress. I then add some project details to the build information and change the status to Succeeded. By setting the Build Status to a completed status myself, the BuildCompletion event is fired as if this was a real build. If the status was set to Succeeded in the CreateManualBuild call, the event would never be fired for this build. This gives you the ability to create historical builds (no events needed) or to create manual builds where you might want the events.

I know many customers will find this new API very useful.

Adding a Fake Build to the Team Build Server

Jason Prickett — Mon, 21 May 2007 17:58:00 GMT

Why would anyone want to add a fake a build to the team build server? Well, there is one very big reason - Integration with Team System. If you don't use Team Build V1 to build your sources (for whatever reason), you may want to at least store some build information in the Team Build server. This allows you to publish test results, associate work items with builds, and view your build information from within Visual Studio.

I saw an older post by someone else that had most of the code. Unfortunately, they were missing the line at the bottom that actually Completes the build. Without this line you won't be able to associate work items with a build number. The code is commented and should be very straight forward. Note that in V1 this process requires several Web Service calls not just one.

So, here is the code:

using System;
using System.Collections.Generic;
using System.Text;
using Microsoft.TeamFoundation.Build.Proxy;
using Microsoft.TeamFoundation.Client;
using Common = Microsoft.TeamFoundation.Build.Common;

namespace AddFakeBuild
{
    class Program
    {
        static void Main(string[] args)
        {
            AddBuild("http://TeamBuildRTMSP1:8080", "MsfAgile", "FakeBuild001");
        }

        static void AddBuild(String serverName, String teamProject, String buildNumber)
        {
            // Get the TeamFoundation Server
            TeamFoundationServer tfs = new TeamFoundationServer(serverName);

            //Construct build store and build controller objects
            BuildStore bStore = (BuildStore)tfs.GetService(typeof(BuildStore));
            BuildController bController = (BuildController)tfs.GetService(typeof(BuildController));

            //Create a build entry
            BuildData bd = new BuildData();

            //Fill in mandatory information for BuildData object
            bd.BuildNumber = buildNumber;
            bd.BuildType = "DummyBuildType";
            bd.TeamProject = teamProject;

            // Make sure that this drop location exists, otherwise 
            // test publish will fail
            bd.DropLocation = @"\\MySharedMachine\drops\" + buildNumber;
            bd.BuildMachine = "NoBuildMachine";
            bd.RequestedBy = Environment.UserName;

            // These string values are locale dependent in V1
            bd.BuildStatus = Common.BuildConstants.BuildStatus.BuildSucceeded;
            bd.BuildQuality = "Not Examined";

            // Add build entry to TeamBuild DB
            bStore.AddBuild(teamProject, bd);

            // Get the URI of the build
            string buildUri = bStore.GetBuildUri(teamProject, buildNumber);

            // Create platform/flavor information against which the test 
            // results will be published
            ProjectData pd = new ProjectData();

            // Fill in mandatory information for ProjectData object
            pd.FlavourName = "Debug";
            pd.PlatformName = "x86";
            pd.ProjectFile = "Dummy.sln";

            // Add project data entry for this build.
            bStore.AddProjectDetailsForBuild(buildUri, pd);

            // Fill in the finish time
            bStore.UpdateBuildFinishTime(buildUri, DateTime.Now);

            // Complete the build and fire the BuildCompletion Event
            bController.BuildCompleted(buildUri);
        }
    }
}

In my next post, I will show you how to do this in Orcas!

Visual Studio 2005 Client starting builds on an Orcas server and build machine

Jason Prickett — Wed, 16 May 2007 15:26:00 GMT

One of the problems that we are seeing pop up internally is with groups that for whatever reason have not upgraded their clients to Orcas, but are starting builds with VS 2005 clients on an Orcas server. This scenario is completely supported, but they seem to be running into one main problem.

Problem:

TF215036: The build request cannot be queued at or below position 1 on agent \tp\agent1. The resulting position would be 2.

Reason:

That error message is given to a V1 client trying to start a build when there is already a build in the Queue. In V1 we didn't have a queue, so for V1 to work correctly, when we get a Start Build call from the V1 web service we throw an error unless the build can be started right away. But why is there one in the Queue? What seems to typically happen is that at some point the Build Agent is rebooted or shut down for some period of time. During the shutdown, a build is started. Since the agent is unreachable by the server, the server errors out the build and marks the agent as unreachable. The next build that is started is Queued, but never actually runs, because the server doesn't retry starting a build on an agent that is unreachable. Now, the V1 client is stuck in limbo. There is no way to see the Queue or cancel that build and starting another build just errors out.

Solution:

The easiest solution is to connect to the server with an Orcas client, open up the Manage Build Agents dialog, open the Agent in question and set the status to enabled. This should cause the Queued build to start right away. Once the Queue is cleared, starting builds should work as expected.

Build Type BuildDirectoryPath => Build Agent Working Directory

Jason Prickett — Mon, 30 Apr 2007 16:18:00 GMT

In Team Build version 1, all information about how to perform the build was stored in the Build Type, which was basically a folder that contained the TfsBuild.proj file, the WorkspaceMapping.xml file, and the TfsBuild.rsp file. In the Orcas release, we have divided the information up so that some of it now resides in the Team Build database. One of the pieces of information that moved to the database is the build location (now called the working directory).

A Change in Location and Usability

In version 1, the user could override the build location when starting a build. In Orcas, the user can't do that. The build location (working directory) is part of the information associated with the Build Agent and can only be changed on the Build Agent Properties dialog. Why, you may ask? As we move towards a model where the user doesn't pick the actual machine that the build runs on (not there yet in Orcas), it is important to keep the details of how the build will actually be performed, tucked away in a safe place. For example, what if the user expected the build agent to have a d: drive and used that as the build location. The build would succeed on some machines but would fail on any that didn't have a d: drive. Assuming that the build machines are maintained by a central IT group (or perhaps the one IT guy), it is much easier for that group to also maintain the build agent information like the working directory. By centrally locating this information and keeping it out of the hands of the average user, we hope to avoid needless build breaks.

Fixing the Problems

One of the problems that some users encountered in version 1 was that the directory structure under the build location root was too long. There is a limit of 260 characters in any path. The real problem is that the user couldn't change anything but the root of the directory structure. Setting the build location to "d:\BL" still produced a path like "d:\BL\TeamProject\TypeName\Sources" as the root of the workspace. In some cases, this was just too long when appended with the longest workspace path. To help fix this problem in Orcas, we now allow the user to specify most of the working directory path. And you can use environment variables as well! The default working directory is "$(Temp)\$(BuildDefinitionPath)" which ends up being something like "C:\DOCUME~1\jpricket\LOCALS~1\Temp\TeamProject\daily\". On to the end of this root we still add "Sources". If that's too long, you can change it to a hard coded path. But we recommend that you make the path unique for each Build Definition. To do that in the shortest space possible, we have provided $(BuildDefinitionId) which you can use in place of $(BuildDefinitionPath). Both of these values are unique for each build definition in the database. For example, a working directory of "d:\BL\$(BuildDefinitionId)" would produce a root folder something like "d:\BL\1245\Sources". By giving you control of this path, we hope to solve the problems associated with long paths in source control.

The Structure Under the Root

In V1 the structure under the build location was something like this:

c:\BuildLocation\TeamProject\TypeName\Binaries - The Output Directory for MSBuild is overridden so that all the outputs of the build process are put under this folder.
c:\BuildLocation\TeamProject\TypeName\BuildType - The build type information is downloaded here.
c:\BuildLocation\TeamProject\TypeName\Sources - The root of the workspace is mapped to this folder.
c:\BuildLocation\TeamProject\TypeName\TestResults - The results of the test runs are placed in this folder.

In Orcas, we have maintained this same structure by default, but you can change it! In TfsBuildService.exe.config file, there are keys for each one of the above subfolders that can be overriden. The only real reason to do this is to shorten the names of these folders to avoid the 260 character limit on paths. Keep in mind, that this entire structure only serves as a working area for MSBuild. When the compilation and tests are done, all of the important files like the Binaries, Test Results, and build log are copied to the Drop Location share. Then this space can be reused by the next build.

Queuing a build in PowerShell

Jason Prickett — Wed, 25 Apr 2007 16:37:00 GMT

I just read Aaron's post "Team Build Object Model - Queueing a Build" and I just had convert his code to PowerShell (for those of us that just hate waiting for code to compile!).

So, here is how to Queue a build in PowerShell (uses my Get-BuildServer script found here):

> $buildserver = Get-BuildServer "http://tfs:8080"
> $teamProject = "TeamProject"
> $buildDefinition = "Nightly"
> $definition = $buildserver.GetBuildDefinition($teamProject, $buildDefinition)
> $request = $definition.CreateBuildRequest()
> $buildserver.QueueBuild($request, "None")

As you can see the code is almost identical (minus the great comments that Aaron's code has). The benefit that I see to doing this in PowerShell is simply that you don't have to open VS, create a new project, write the code, compile it, open the bin folder, and then run the exe. Instead, you can simply open PS, type the code, and see the results.

Look for more PowerShell scripts coming soon like Queue-Build.ps1!