Aaron Hallberg : Team Build V1

Another Method for using solution-specific binaries subdirectories

aaronhallberg — Tue, 27 Mar 2007 17:22:00 GMT

A problem that comes up over and over again (see forums posts here, here, etc.) with Team Build v1 is that it is very difficult to compile individual solutions and/or individual projects within a solution into their own output directories. I did a post last week on passing custom properties to individual solutions - one of the uses for this functionality is addressing this issue.

A clever hack that addresses this issue was submitted to an internal Microsoft DL yesterday by Guido Pica, who works for Microsoft Consulting Services in Italy. The idea is to use Team Build's built-in ConfigurationToBuild logic to trick it into doing this work for you. Here's Guido's solution in his own words:

Another quick way to get this is to customize Solution Configurations:

In Solution Configuration Manager, create a new solution configuration (name it as you want the subfolder named ex.: FirstSolution, etc.)
Usually you want to Copy from “Release” default configuration
DESELECT the option to create project configuration, cause this should remain *ONLY* a solution configuration, and should not be propagated to projects.
Then, in TFSBuild.proj, add all custom solution configuration to be processed as Flavors:
<ItemGroup>
    <ConfigurationToBuild Include="FirstSolution|Mixed Platforms">
      <FlavorToBuild>FirstSolution</FlavorToBuild>
      <PlatformToBuild>Mixed Platforms</PlatformToBuild>
    </ConfigurationToBuild>
    <ConfigurationToBuild Include="SecondSolution|Mixed Platforms">
      <FlavorToBuild>SecondSolution</FlavorToBuild>
      <PlatformToBuild>Mixed Platforms</PlatformToBuild>
    </ConfigurationToBuild>
</ItemGroup>
This way, the team build process will try to compile each solution against each solution configuration, but having each solution just his own configuration, this will be the only one really processed for that solution, skipping all the others and creating his own right subfolder.
Hope I been clear enough.

The trick here is that the ConfigurationToBuild item group in Team Build is expected to contain solution configurations, and not project configurations. Solution configurations are essentially just a collection of project configurations, and critically can also specify whether or not individual projects get built at all. So - the idea here is just to create several solution configurations which build only one project and then let Team Build do the work of putting the binaries into their own subdirectories. Note that if you use "Any CPU" as the platform it won't even insert the bogus "Mixed Platforms" directory into the mix.

This solution is only really helpful when: (a) you have just one solution and want to copy individual project outputs into their own subdirectories, (b) you have a small number of projects, and (c) you don't have automated unit tests (tests are also run per configuration, which is unlikely to work here). If your build meets these conditions, however, this approach can allow you to solve the custom subdirectory issue without having to override CoreCompile, do any crazy machinations in the AfterDropBuild target, etc. I should also note once more that this sort of thing will be much easier in Orcas, and shouldn't require any hacks like this.

Thanks to Guido for the nice idea!

Passing custom properties to individual solutions in Team Build

aaronhallberg — Mon, 19 Mar 2007 22:54:00 GMT

Gautam Goenka posted an article on this topic way back on April 20, 2006. It included a targets file which overrode the standard Team Build CoreCompile target and allowed user-specified properties to be passed into the MSBuild tast that Team Build uses to build the solution in the SolutionToBuild item group. This approach is fine if you want to pass the same custom property values into each solution in the SolutionToBuild item group, but what if you want to pass different property values into each solution?

Manish Agarwal posted an article that could help get you started here. His goal was to enable redirecting assemblies to solution-specific subdirectories, but it was easily extendable to passing other user-specified properties on a solution-specific basis. Unfortunately, it also some problems, including breaking the calculation of errors/warnings during the compilation phase of the build.

Before pressing on, I should say that we do not recommend overriding the Core* targets in a Team Build build. The primary reason here is that you will almost certainly be broken after you upgrade to Orcas if you override these targets, since most of them will be changing radically in that new version. See this post by Buck Hodges for more details here. The good news here is that the issues that caused people to override the Core* targets in Team Build v1 have been addressed in Orcas, so you should no longer find it necessary to do this sort of thing.

Having said all that, attached you will find a new CoreCompile override that will allow you pass custom property values into each solution via solution-specific metadata. For example, if you wanted each solution to be signed with a different key file you could do something like:

    <SolutionToBuild Include="$(SolutionRoot)\foo.sln">
      <Properties>SignAssembly=true;AssemblyOriginatorKeyFile=C:\foo.snk</Properties>
    </SolutionToBuild>
    <SolutionToBuild Include="$(SolutionRoot)\bar.sln">
      <Properties>SignAssembly=true;AssemblyOriginatorKeyFile=C:\bar.snk</Properties>
    </SolutionToBuild>

NOTE: My original example here, which purported to put individual binaries into individual subdirectories, was broken! Thanks to Esteban Garcia for pointing this out, and sorry for any trouble I might have caused anybody... If you want to put your binaries into individual subdirectories, try out the new attachment and do something like:

    <SolutionToBuild Include="$(SolutionRoot)\foo.sln">
      <Subdirectory>foo</Subdirectory>
    </SolutionToBuild>
    <SolutionToBuild Include="$(SolutionRoot)\bar.sln">
      <Subdirectory>bar</Subdirectory>
    </SolutionToBuild>

To use this modified CoreCompile target, just:

Download the attached CoreCompileOverride.targets file and check it in alongside TfsBuild.proj. (Alternatively, you can install this file somewhere on your build machine(s) and modify the import directory in step 2)

Add an <import> statement to your TfsBuild.proj file - something like:

<Import Project="$(MSBuildProjectDirectory)\CoreCompileOverride.targets" />

Add your custom properties to each item in the SolutionToBuild item group.

Hopefully you'll find this useful! Let me know via comments if you run into any issues with the attached file, etc.

Getting the Modified Files for a Team Build Build

aaronhallberg — Fri, 12 Jan 2007 00:14:00 GMT

I've had several people inquire recently about how to figure out which files have changed since the previous Team Build build... In V1 there is no straightforward way to do this, unfortunately, though we plan to remedy that in the next version of Team Build. For now, here is one approach - the basic idea is to do a preview get prior to doing the actual get. There are issues with this, of course - you might be interested in the list of changesets rather than the list of files, for example; additional modifications might be made to source control between the preview and the actual get; you might want to get one of these lists without having to do an incremental get; and so forth. To a first approximation, however, this should do the trick.

The approach I took was to impement a custom task derived from the TeamBuildTask I presented in an earlier post. I didn't add a lot of bells and whistles here - none of the fancy Get properties are exposed (FileSpec, Version, RecursionType, etc.); only the target local filename is included for each item; etc. If you want stuff like that, you'll have to add it yourself! As always, I make no guarantees about the awesomeness of this sample code, etc. In fact, I would appreciate any feedback on this one - I am in the middle of a bunch of stuff with my dev box and didn't even have a chance to test this one... All I know for sure is that it compiles!

using System;
using System.Collections.Generic;
using Microsoft.Build.Framework;
using Microsoft.Build.Utilities;
using Microsoft.TeamFoundation.VersionControl.Client;
using Microsoft.TeamFoundation.VersionControl.Common;

namespace CustomTasks
{
    class PreviewGet : TeamBuildTask
    {
        /// <summary>
        /// Mirrors the v1 Get task property.
        /// </summary>
        [Required]
        public String Workspace
        {
            get
            {
                return m_workspace;
            }
            set
            {
                m_workspace = value;
            }
        }

        /// <summary>
        /// Output property that contains the list of all deletes that will be performed by the Get task.
        /// </summary>
        [Output]
        public ITaskItem[] Deletes
        {
            get
            {
                return m_deletes.ToArray();
            }
        }

        /// <summary>
        /// Output property that contains the list of all gets that will be performed by the Get task.
        /// </summary>
        [Output]
        public ITaskItem[] Gets
        {
            get
            {
                return m_gets.ToArray();
            }
        }

        /// <summary>
        /// Output property that contains the list of all replaces that will be performed by the Get task.
        /// </summary>
        [Output]
        public ITaskItem[] Replaces
        {
            get
            {
                return m_replaces.ToArray();
            }
        }

        /// <summary>
        /// Lazy init property that gives access to the VersionControlServer service of the TF Server.
        /// </summary>
        protected VersionControlServer VersionControlServer
        {
            get
            {
                if (m_versionControlServer == null)
                {
                    m_versionControlServer = (VersionControlServer)Tfs.GetService(typeof(VersionControlServer));
                }
                return m_versionControlServer;
            }
        }

        /// <summary>
        /// Returns the name of the build step to be added for this task.
        /// </summary>
        /// <returns>Name of the build step to be added.</returns>
        protected override string GetBuildStepName()
        {
            return "GetPreview";
        }

        /// <summary>
        /// Returns the message of the build step to be added for this task - this is the
        /// string displayed in the Team Build GUI.
        /// </summary>
        /// <returns>Message of the build step to be added.</returns>
        protected override string GetBuildStepMessage()
        {
            return "Getting the list of files to be updated by the Get task...";
        }

        /// <summary>
        /// Execute the task logic.
        /// </summary>
        /// <returns>True. Exceptions thrown on failure.</returns>
        protected override bool ExecuteInternal()
        {
            Workspace workspace = VersionControlServer.GetWorkspace(Workspace, RepositoryConstants.AuthenticatedUser);

            try
            {
                VersionControlServer.Getting += VersionControlServer_Getting;
                workspace.Get(VersionSpec.Latest, GetOptions.Preview);
            }
            finally
            {
                VersionControlServer.Getting -= VersionControlServer_Getting;
            }

            return true;
        }

        /// <summary>
        /// Getting event handler.
        /// </summary>
        void VersionControlServer_Getting(object sender, GettingEventArgs e)
        {
            switch (e.Status)
            {
                case OperationStatus.Deleting:
                    m_deletes.Add(new TaskItem(e.TargetLocalItem));
                    break;

                case OperationStatus.Getting:
                    m_gets.Add(new TaskItem(e.TargetLocalItem));
                    break;

                case OperationStatus.Replacing:
                    m_replaces.Add(new TaskItem(e.TargetLocalItem));
                    break;
            }
        }

        private String m_workspace;
        private VersionControlServer m_versionControlServer;
        private List<ITaskItem> m_gets = new List<ITaskItem>();
        private List<ITaskItem> m_replaces = new List<ITaskItem>();
        private List<ITaskItem> m_deletes = new List<ITaskItem>();
    }
}

To use this task, make sure to run it before the actual Get task. Something like the following should typically do the trick:

<Task Name="BeforeGet">
    <PreviewGet TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
                BuildUri="$(BuildUri)"
                Workspace="$(WorkspaceName)">
        <Output TaskParameter="Deletes" ItemName="Deletes" />
        <Output TaskParameter="Gets" ItemName="Gets" />
        <Output TaskParameter="Replaces" ItemName="Replaces" />
    </PreviewGet>
</Task>

Note that this task should typically only be used when doing incremental gets / incremental builds (See my post here to learn how to do an incremental get without also doing an incremental build), and will only function as advertised (i.e. provide a list of the changed files since the last build) when:

Your build does an incremental get, and
You only use one build machine!

Additionally, if you use this task when retrieving many millions of files, you can imagine it causing your build process to run out of memory... Use it with caution!

The Triumphant Return?

aaronhallberg — Thu, 14 Dec 2006 18:26:00 GMT

Wow - it's been a long time. Sorry for the insanely long delay between posts, loyal reader(s). A lot has happened since I last managed to post something on my blog:

I've been working like crazy, along with the rest of the Team Build team, to get our Continuous Integration solution finished up for the Orcas release (see Brian Harry's blog post here for the full TFS roadmap, or Buck Hodge's post here for more details on the Team Build features in Orcas).
I got hooked on that Ugly Betty show. At first the hourlong format put me off, but now I can't imagine it being any shorter.
Control of the House and Senate shifted to the Democrats.
Britney and Kevin broke up, just days after my wife and I dressed as the two of them for Halloween. Coincidence? Perhaps...
Vista, Office, and the Zune all shipped. One very positive aspect of the Zune launch from my point of view - my favorite radio station, KEXP, was heavily involved and various excellent bands (e.g. Band of Horses) have been featured in ad spots, etc.

In any case, during a conference call the other day, a Team Build user expressed a desire to easily insert build steps into a build from within a csproj file... In previous posts I have laid out custom tasks which, as part of their execution, insert build steps. In this post, I lay out a simpler custom task which inserts arbitrary text as a build step - think of it as a <Message> task in Team Build form.

Here's the code:

using System;
using Microsoft.Build.Framework;
using Microsoft.Build.Utilities;
using Microsoft.TeamFoundation.Client;
using Microsoft.TeamFoundation.Build.Proxy;

namespace CustomTasks
{
    public class BuildStepTask : Task
    {
        /// <summary>
        /// Execute the task logic.
        /// </summary>
        /// <returns>True. Exceptions thrown on failure.</returns>
        public override bool Execute()
        {
            BuildStore.AddBuildStep(BuildUri, Text, Text);
            BuildStore.UpdateBuildStep(BuildUri, Text, DateTime.Now, m_buildStatus);

            return true;
        }

        /// <summary>
        /// The text of the build step.
        /// </summary>
        [Required]
        public String Text
        {
            get
            {
                return m_text;
            }
            set
            {
                m_text = value;
            }
        }

        /// <summary>
        /// The status of the build step. If not specified, BuildStepStatus.Succeeded will be assumed.
        /// </summary>
        public String Status
        {
            get
            {
                return m_buildStatus.ToString();
            }
            set
            {
                // Go ahead and throw an exception if the value is invalid.
                m_buildStatus = (BuildStepStatus)Enum.Parse(typeof(BuildStepStatus), value);
            }
        }

        /// <summary>
        /// The Url of the Team Foundation Server.
        /// </summary>
        [Required]
        public String TeamFoundationServerUrl
        {
            get
            {
                return m_tfsUrl;
            }
            set
            {
                m_tfsUrl = value;
            }
        }

        /// <summary>
        /// The Uri of the Build for which this task is executing.
        /// </summary>
        [Required]
        public String BuildUri
        {
            get
            {
                return m_buildUri;
            }
            set
            {
                m_buildUri = value;
            }
        }

        /// <summary>
        /// Lazy init property that gives access to the TF Server specified by TeamFoundationServerUrl.
        /// </summary>
        protected TeamFoundationServer Tfs
        {
            get
            {
                if (m_tfs == null)
                {
                    m_tfs = TeamFoundationServerFactory.GetServer(TeamFoundationServerUrl);
                }
                return m_tfs;
            }
        }

        /// <summary>
        /// Lazy init property that gives access to the BuildStore service of the TF Server.
        /// </summary>
        protected BuildStore BuildStore
        {
            get
            {
                if (m_buildStore == null)
                {
                    m_buildStore = (BuildStore)Tfs.GetService(typeof(BuildStore));
                }
                return m_buildStore;
            }
        }

        private String m_text;
        private BuildStepStatus m_buildStatus = BuildStepStatus.Succeeded;
        private String m_tfsUrl;
        private String m_buildUri;
        private TeamFoundationServer m_tfs;
        private BuildStore m_buildStore;
    }
}

And here's a snippet from the csproj file I used to test it out:

  <UsingTask TaskName="CustomTasks.BuildStepTask" AssemblyFile="..\TeamBuildTypes\HelloWorld\CustomTasks.dll" />

  <Target Name="AfterCompile" Condition=" '$(BuildUri)' != '' ">
    <BuildStepTask TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
                   BuildUri="$(BuildUri)"
                   Text="Finished compiling $(AssemblyName)" />
  </Target>

Note the condition on the Target to avoid running it outside of a Team Build environment.

Hopefully this post will be the first of many in the months to come.

Team Build API: GetListOfBuilds

aaronhallberg — Fri, 29 Sep 2006 15:36:00 GMT

In part two of my 35 part series, better know a Proxy, I'll be going over the GetListOfBuilds method (of the BuildStore class in the Microsoft.TeamFoundation.Build.Proxy namespace).

public BuildData[] GetListOfBuilds(
	string teamProject,
	string buildType
)

This method can be used to obtain information about all of the builds for a particular build type. It takes two parameters - teamProject, which specifies the team project the build type belongs to; and buildType, which specifies the build type for which builds are retrieved. It returns an array of BuildData objects, which contain various details about the individual builds.

Here is an example custom task (based on the TeamBuildTask base class from an earlier post) that uses the GetListOfBuilds method to generate sequential build numbers.

using System;
using Microsoft.Build.Framework;
using Microsoft.TeamFoundation.Build.Proxy;

namespace MyNamespace
{
    public class SequentialBuildNumberGenerator : TeamBuildTask
    {
        /// <summary>
        /// The build number generated by the task.
        /// </summary>
        [Output]
        public string BuildNumber
        {
            get
            {
                return m_buildNumber;
            }
            set
            {
                m_buildNumber = value;
            }
        }

        /// <summary>
        /// Returns the name of the build step to be added for this task.
        /// </summary>
        /// <returns>Name of the build step to be added.</returns>
        protected override string GetBuildStepName()
        {
            return "SequentialBuildNumberGenerator";
        }

        /// <summary>
        /// Returns the message of the build step to be added for this task - this is the
        /// string displayed in the Team Build GUI.
        /// </summary>
        /// <returns>Message of the build step to be added.</returns>
        protected override string GetBuildStepMessage()
        {
            return "Generating a sequential build number.";
        }

        /// <summary>
        /// Put real task logic in this method.
        /// </summary>
        /// <returns>True if task is successful, otherwise false.</returns>
        protected override bool ExecuteInternal()
        {
            BuildData thisBuild = BuildStore.GetBuildDetails(BuildUri);

            BuildData[] allBuilds = BuildStore.GetListOfBuilds(thisBuild.TeamProject, thisBuild.BuildType);

            if (allBuilds.Length == 1)
            {
                m_buildNumber = "1";
            }
            else
            {
                int maxBuildNumber = 0, curBuildNumber;

                foreach (BuildData build in allBuilds)
                {
                    // All non integral build numbers, including the original number for the current build, will be ignored.
                    if (Int32.TryParse(build.BuildNumber, out curBuildNumber))
                    {
                        maxBuildNumber = Math.Max(maxBuildNumber, curBuildNumber);
                    }
                }

                m_buildNumber = (maxBuildNumber + 1).ToString("D");
            }

            return true;
        }

        private string m_buildNumber;
    }
}

To use this task, you'll need to do something like the following in TfsBuild.proj:

<UsingTask TaskName="SequentialBuildNumberGenerator" AssemblyFile="CustomTasks.dll" />

<Target Name="BuildNumberOverrideTarget">
	<SequentialBuildNumberGenerator TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
		BuildUri="$(BuildUri)">
		<Output TaskParameter="BuildNumber" PropertyName="BuildNumber" />
	</SequentialBuildNumberGenerator>      
</Target>

Determining Whether Tests Passed in Team Build

aaronhallberg — Thu, 21 Sep 2006 20:26:00 GMT

In a forum post a while back, I laid out a method for determining whether tests had passed during a build. More recently, I have linked to this forum post in advising others on similar problems. Unfortunately, as a sharp user pointed out in this same thread, my solution doesn't actually work, since it relies on a property that is not accessible in Team Build v1!

So - to remedy the situation I have written a custom task which can be used to determine whether tests have succeeded or not. This task takes advantage of the GetTestResultsForBuild method of the Microsoft.TeamFoundation.Build.Proxy.BuildStore class.

As always, this task is provided as a sample only; its awesomeness cannot be guaranteed, etc. The task inherits from the TeamBuildTask class I presented in an earlier post.

using System;
using System.Web.Services;
using Microsoft.Build.Framework;
using Microsoft.Build.Utilities;
using Microsoft.TeamFoundation.Client;
using Microsoft.TeamFoundation.Build.Common;
using Microsoft.TeamFoundation.Build.Proxy;

namespace MyNamespace
{
    public class CheckForTestSuccess : TeamBuildTask
    {
        /// <summary>
        /// The ConfigurationToBuild Item Group for the Build.
        /// </summary>
        [Required]
        public ITaskItem[] ConfigurationToBuild
        {
            get
            {
                return m_configurationToBuild;
            }
            set
            {
                m_configurationToBuild = value;
            }
        }

        /// <summary>
        /// An output property which will be true if all test runs succeeded and false otherwise.
        /// </summary>
        [Output]
        public bool TestSuccess
        {
            get
            {
                return m_testSuccess;
            }
            set
            {
                m_testSuccess = value;
            }
        }

        /// <summary>
        /// Returns the name of the build step to be added for this task.
        /// </summary>
        /// <returns>Name of the build step to be added.</returns>
        protected override string GetBuildStepName()
        {
            return "CheckForTestSuccess";
        }

        /// <summary>
        /// Returns the message of the build step to be added for this task - this is the
        /// string displayed in the Team Build GUI.
        /// </summary>
        /// <returns>Message of the build step to be added.</returns>
        protected override string GetBuildStepMessage()
        {
            return "Checking for test success.";
        }

        /// <summary>
        /// Put real task logic in this method.
        /// </summary>
        /// <returns>True if task is successful, otherwise false.</returns>
        protected override bool ExecuteInternal()
        {
            string platform;
            string flavor;
            TestResultData[] testResults;

            m_testSuccess = true;

            foreach (ITaskItem configuration in ConfigurationToBuild)
            {
                platform = configuration.GetMetadata("PlatformToBuild");
                flavor   = configuration.GetMetadata("FlavorToBuild");

                testResults = BuildStore.GetTestResultsForBuild(BuildUri, platform, flavor);

                foreach (TestResultData testResult in testResults)
                {
                    if (!testResult.RunPassed)
                    {
                        m_testSuccess = false;
                        break;
                    }
                }
                if (!m_testSuccess)
                {
                    break;
                }
            }

            return true;
        }

        private ITaskItem[] m_configurationToBuild;
        private bool m_testSuccess;
    }
}

To use this task, you'll need to do something like the following in TfsBuild.proj:

<UsingTask TaskName="CheckForTestSuccess" AssemblyFile="CustomTasks.dll" />

<Target Name="AfterTest">
	<CheckForTestSuccess TeamFoundationServerUrl="$(TeamFoundationServerUrl)" 
		BuildUri="$(BuildUri)" 
		ConfigurationToBuild="@(ConfigurationToBuild)">
		<Output TaskParameter="TestSuccess" PropertyName="TestSuccess" />
	</CheckForTestSuccess>
</Target>

The property TestSuccess would then be 'true' if and only if all test runs succeeded for the build.

Building a Specific Version with Team Build

aaronhallberg — Tue, 19 Sep 2006 17:40:00 GMT

Team Build by default gets the latest version of your sources (or tip) from source control. For the most part, this is probably the behavior you would want and expect. But not always - you might want to reproduce a particular build that got deleted, for example; or you might want to build your latest changest without including changes other users might have checked in.

Unfortunately, getting (and therefore building) a specific version from source control is not supported out of the box in Team Build version 1... The Get task used in Team Build (this can be found in Microsoft.TeamFoundation.Build.targets) looks like this:

<Target Name="CoreGet"
	Condition=" '$(IsDesktopBuild)' != 'true' "
	DependsOnTargets="$(CoreGetDependsOn)" >

	<!-- Get all the latest sources from the given workspace-->	
	<Get Condition=" '$(SkipGet)' != 'true' " 
		Workspace="$(WorkspaceName)" 
		Recursive="$(RecursiveGet)" 
		Force="$(ForceGet)" />
	  
</Target>

The Get task also a Version property that is not used here. It defaults to "T", or the tip version. To get and build a specific version from source control, you will need to set this property.

There are several options here:

You can override the CoreGet target in TfsBuild.proj.
You can modify the CoreGet target in Microsoft.TeamFoundation.Build.targets directly.
You can set the SkipGet property to true and override BeforeGet or AfterGet instead.

Modifying Microsoft.TeamFoundation.Build.targets is not a good idea - this would need to be done on every build machine, could get wiped out during an upgrade or installation repair, etc. Overriding CoreGet is usually not recommended either, since the CoreXX targets will almost certainly be changing in the next release of Team Build. In this case, however, overriding CoreGet (option 1) is essentially indistinguishable from setting SkipGet and overriding BeforeGet / AfterGet (option 3) and is simpler.

So - to override CoreGet in TfsBuild.proj, you will want to do something like the following:

<Target Name="CoreGet"
	  Condition=" '$(IsDesktopBuild)'!='true' "
	  DependsOnTargets="$(CoreGetDependsOn)" >

	<!-- Get all the latest sources from the given workspace-->
	<Get Condition=" '$(SkipGet)'!='true' "
		Workspace="$(WorkspaceName)"
		Recursive="$(RecursiveGet)"
		Force="$(ForceGet)"
		Version="$(VersionToGet)" />
	  
</Target>

At this point, you just need to set the VersionToGet property to whatever version you would like to get. This can be done in all the normal MSBuild ways - via the command line (put a string in your TfsBuild.rsp file similar to /p:VersionToGet=<VersionSpec>), declaratively in a PropertyGroup element, programmatically with a CreateProperty task, or via an environment variable.

To reproduce a particular build, you will typically want to set VersionToGet to a label-based version spec similar to "L<build number>" (unless you have modified your build process to use some other labeling scheme). For example, if you build number is "MyBuild_20060919.1" you could do something like this:

<PropertyGroup>
	<VersionToGet>LMyBuild_20060919.1</VersionToGet>
</PropertyGroup>

Team Build API: GetBuildUri and GetBuildDetails

aaronhallberg — Wed, 13 Sep 2006 20:52:00 GMT

As Buck Hodges recently noted, some Team Build API documentation recently made it up onto MSDN. Unfortunately, most (maybe all? I haven't been through it all) of the topics are skeletons, with no real content. I'll be trying to remedy this by posting fleshed out documentation, sometimes even with examples...

Thus begins my 35 part series - better know a Proxy.

First up - the GetBuildDetails method (of the BuildStore class in the Microsoft.TeamFoundation.Build.Proxy namespace).

public BuildData GetBuildDetails (
	string buildUri
)

This method can be used to obtain information about in-progress or completed builds, including their status, quality, and finish time. It takes a single parameter, buildUri, which is a string containing the full URI of a build - typically something like: "vstfs://Build/Build/09012006_010101_000001". It returns a BuildData object, which contains various details about the build.

Of course, users do not typically know the Uri associated with an individual build, since it is not displayed in any of the standard Team Build GUI. To come up with a meaningful example, therefore, we'll also have to cover the GetBuildUri method.

public string GetBuildUri (
	string teamProject,
	string buildNumber
)

This method can be used to obtain a build's Uri given a Team Project and the build's Number. These can readily be retrieved from the Team Build GUI, though the build number is typically displayed as the build name.

Here is an example console application that takes in a Team Foundation Server URL, a Team Project, and a Build Number and displays the corresponding build's Uri, Status, Quality, and Finish Time.

using System;
using System.Web.Services;
using Microsoft.TeamFoundation.Client;
using Microsoft.TeamFoundation.Build.Proxy;

namespace ConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {
            string tfsUrl = args[0];
            string teamProject = args[1];
            string buildNumber = args[2];

            TeamFoundationServer tfs = TeamFoundationServerFactory.GetServer(tfsUrl);

            BuildStore buildStore = (BuildStore)tfs.GetService(typeof(BuildStore));

            string buildUri = buildStore.GetBuildUri(teamProject, buildNumber);

            BuildData buildData = buildStore.GetBuildDetails(buildUri);

            Console.WriteLine();
            Console.WriteLine("BuildUri     = " + buildData.BuildUri);
            Console.WriteLine("BuildStatus  = " + buildData.BuildStatus);
            Console.WriteLine("BuildQuality = " + buildData.BuildQuality);
            Console.WriteLine("FinishTime   = " + buildData.FinishTime);
        }
    }
}

Of course, any real application along these lines would do some error checking, display a useful message when invalid arguments were supplied, etc.

Team Build and aspnet_compiler.exe

aaronhallberg — Tue, 12 Sep 2006 17:11:00 GMT

It's funny how things come in bunches sometimes... I had never heard of the issue discussed in this blog post as of a couple of days ago, but we have received two queries on the topic in the Team Build forums in the last few days. (Here they are, if you are interested: One and Two.

The issue deals with the compilation of websites, and particularly with *.aspx and *.ashx files (ashx files, by the way, are HTTP handlers). In particular, when these types of files are compiled the resultant files typically contain some bogus text (something like "This is a marker file generated by the precompilation tool, and should not be deleted!"), while all the actual logic ends up in the generated assembly. For example, the command line:

> aspnet_compiler.exe -v /WebApplication1 -p C:\MyProjects\WebApplication1 C:\MyProjects\WebApplication1\PrecompiledWeb

...will compile the web application defined in directory C:\MyProjects\WebApplication1 into the directory C:\MyProjects\WebApplication1\PrecompiledWeb. In addition to using aspnet_compiler.exe directly, MSBuild includes the AspNetCompiler task. The following MSBuild project file has the same result as the example command-line:

<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" >
	<Target Name="Build">
		<AspNetCompiler VirtualPath="/WebApplication1" PhysicalPath="C:\MyProjects\WebApplication1" TargetPath="C:\MyProjects\WebApplication1\PrecompiledWeb" />
	</Target>
</Project>

Because Team Build typically compiles solutions and not projects, an additional complication is introduced with website projects. By default, these projects have the -u option selected for their compilation in their solution property pages. If you open up a solution containing a website project you should see a section that looks something like this:

Project("{Some GUID}") = "WebApplication1", ".\WebApplication1\", "{Some GUID}"
    ProjectSection(WebsiteProperties) = preProject
        Debug.AspNetCompiler.VirtualPath = "/WebApplication1"
        Debug.AspNetCompiler.PhysicalPath = ".\WebApplication1\"
        Debug.AspNetCompiler.TargetPath = "PrecompiledWeb\WebApplication1\"
        Debug.AspNetCompiler.Updateable = "true"
        Debug.AspNetCompiler.ForceOverwrite = "true"
        Debug.AspNetCompiler.FixedNames = "true"
        Debug.AspNetCompiler.Debug = "True"
        VWDPort = "14091"
        DefaultWebSiteLanguage = "Visual C#"
    EndProjectSection
EndProject

Note the VirtualPath, PhysicalPath, and TargetPath lines - these specify options to the AspNetCompiler task that we have already seen in the above example (and correspond to the -v, -p, and targetPath options to aspnet_compiler.exe, respectively). The rest of the lines with AspNetCompiler in them also correspond to AspNetCompiler task properties, and the Updateable (sic) property is the one we care about for this post - it corresponds to the -u option to aspnet_compiler.exe.

With this option turned on, aspnet_compiler.exe keeps markup, including inline code, in all *.aspx and *.ashx files (and possibly others - I'm no expert in these matters) so that they can be modified after the site is deployed. So - if you compile your website projects by using MSBuild to compile the solutions that contain them:

> msbuild.exe C:\MyProjects\WebApplication.sln

...your *.aspx and *.ashx files will be updatable and will not be compiled. Since Team Build typically compiles solutions, builds done through Team Build will run into the same issue.

So - to fix this issue, you can either manually edit your solution file (set the Debug.AspNetCompiler.Updateable value to "false" rather than "true", repeat for other configurations) in notepad, or you can edit it through the GUI by right-clicking on your website project, selecting Property Pages, selecting the MSBuild Options section, and unchecking the "Allow this precompiled site to be updated" box.

Adding Custom Loggers to Team Build

aaronhallberg — Wed, 30 Aug 2006 16:02:00 GMT

Most of the magic in a Team Build is done using either (a) customized tasks, or (b) a customized logger. Well, most of the build machine magic - there's plenty of magic in the client, the Application Tier, and the Data Tier. All right - even on the build machine I suppose plenty of magic happens within MSBuild itself. In any case, we should be able to agree that some of the magic in a Team Build happens using customized tasks and loggers, right? They're responsible for making most of the web service calls that populate the database with information about the build, interacting with source control and work item tracking, keeping track of the errors/warnings encountered during the build, etc.

Yesterday we looked at using tasks to add customized build steps during a build. Today I'd like to show you how to add a customized logger... For more information on MSBuild loggers, check out MSBuild Logging on MSDN.

Step 1. Figure out why you want to add a logger.

I was thinking about this last night - would a Team Build user ever want to add a custom logger? The IDC team, implementers of Team Build 1.0, have a couple of posts on different types of custom loggers:

An XML Logger. This might be useful for diagnostic purposes - it will show you every single event raised by MSBuild during the course of a build. I wouldn't recommend it for large builds, unless you feel like filling up your hard disk!

An errors/warnings logger that creates log files per solution. This could be pretty useful if you are running into tons of errors/warnings in your build and want to separate them out into more managable chunks (by default Team Build creates log files per configuration).

Neither of these seemed seemed particularly compelling to me, though - I could see wanting to use them once or twice, but not all the time. How about this - out of the box TFS supports notifications on build completion or on build quality change. For certain types of builds, though, one might want to send out notifications on build start. Right? Right? Oh fine, it's not the most interesting thing in the world, but it's something...

If you come up with other interesting reasons to write your own loggers, please let me know!

Step 2. You'll want to actually write your custom logger.

I'm not going to post the entire sample this time - just the relevant bit.

public class CustomLogger : ILogger
{

...

    public void Initialize(IEventSource source)
    {
        source.BuildStarted += new BuildStartedEventHandler(HandleBuildStartedEvent);
    }

    public void HandleBuildStartedEvent(Object sender, BuildStartedEventArgs args)
    {
        // Write fancy email sending code here!
    }

    ...
}

Step 3. You'll need to tell MSBuild about your logger, using the /logger command-line switch.

One of the files created for each build type is TfsBuild.rsp. This is an MSBuild response file, and can contain MSBuild.exe command-line switches. Team Build will pass this file to MSBuild.exe whenever a build is started (for the given build type).

So - check out TfsBuild.rsp from source control, add something like the following:

/logger:CustomLogger,CustomLogger.dll

...and check it back in.

Step 4. Make sure that your logger assembly is available during the build.

The easiest thing here is probably to add it to the same directory in source control as the TfsBuild.rsp file you just modified - Team Build will then sync CustomLogger.dll along with TfsBuild.proj, TfsBuild.rsp, and WorkspaceMapping.xml. In this case, you won't need to give a full path to the assembly in the rsp file, and the above example should just work.

Adding BuildSteps to Team Build through a Custom Task

aaronhallberg — Tue, 29 Aug 2006 22:14:00 GMT

Team Build displays Build Steps in the build report form within Visual Studio. By default, build steps are added at various points during the course of a build - while getting sources (in the Get task), compiling solutions / projects, copying files to the drop location, etc. Team Build allows users to insert their own build steps using the publicly accessible BuildStore web service - in particular, the AddBuildStep and UpdateBuildStep methods. The following sample (I make no claims as to the awesomeness or lack thereof of this sample, etc.) TeamBuildTask class illustrates how this can be done:

using System;
using System.Web.Services;
using Microsoft.Build.Framework;
using Microsoft.TeamFoundation.Client;
using Microsoft.TeamFoundation.Build.Common;
using Microsoft.TeamFoundation.Build.Proxy;

/// <summary>
/// Summary description for Class1
/// </summary>
namespace MyNamespace
{
    public abstract class TeamBuildTask : ITask
    {
        /// <summary>
        /// Put real task logic in this method.
        /// </summary>
        /// <returns>True if task is successful, otherwise false.</returns>
        protected abstract bool ExecuteInternal();

        /// <summary>
        /// Returns the name of the build step to be added for this task.
        /// </summary>
        /// <returns>Name of the build step to be added.</returns>
        protected abstract string GetBuildStepName();

        /// <summary>
        /// Returns the message of the build step to be added for this task - this is the
        /// string displayed in the Team Build GUI.
        /// </summary>
        /// <returns>Message of the build step to be added.</returns>
        protected abstract string GetBuildStepMessage();

        /// <summary>
        /// ITask implementation - BuildEngine property.
        /// </summary>
        public IBuildEngine BuildEngine
        {
            get
            {
                return m_buildEngine;
            }
            set
            {
                m_buildEngine = value;
            }
        }

        /// <summary>
        /// ITask implementation - HostObject property.
        /// </summary>
        public ITaskHost HostObject
        {
            get
            {
                return m_hostObject;
            }
            set
            {
                m_hostObject = value;
            }
        }

        /// <summary>
        /// The Url of the Team Foundation Server.
        /// </summary>
        [Required]
        public string TeamFoundationServerUrl
        {
            get
            {
                return m_tfsUrl;
            }
            set
            {
                m_tfsUrl = value;
            }
        }

        /// <summary>
        /// The Uri of the Build for which this task is executing.
        /// </summary>
        [Required]
        public string BuildUri
        {
            get
            {
                return m_buildUri;
            }
            set
            {
                m_buildUri = value;
            }
        }

        /// <summary>
        /// Lazy init property that gives access to the TF Server specified by TeamFoundationServerUrl.
        /// </summary>
        protected TeamFoundationServer Tfs
        {
            get
            {
                if (m_tfs == null)
                {
                    if (String.IsNullOrEmpty(TeamFoundationServerUrl))
                    {
                        // Throw some exception.
                    }
                    m_tfs = TeamFoundationServerFactory.GetServer(TeamFoundationServerUrl);
                }
                return m_tfs;
            }
        }

        /// <summary>
        /// Lazy init property that gives access to the BuildStore service of the TF Server.
        /// </summary>
        protected BuildStore BuildStore
        {
            get
            {
                if (m_buildStore == null)
                {
                    m_buildStore = (BuildStore)Tfs.GetService(typeof(BuildStore));
                }
                return m_buildStore;
            }
        }

        /// <summary>
        /// ITask implementation - Execute method.
        /// </summary>
        /// <returns>
        /// True if the task succeeded, false otherwise.
        /// </returns>
        public bool Execute()
        {
            bool returnValue = false;

            try
            {
                AddBuildStep();
                returnValue = ExecuteInternal();
            }
            catch (Exception e)
            {
                AddExceptionBuildStep(e);
                throw;
            }
            finally
            {
                UpdateBuildStep(returnValue);
            }

            return returnValue;
        }

        private void AddBuildStep()
        {
            BuildStore.AddBuildStep(BuildUri, GetBuildStepName(), GetBuildStepMessage());
        }

private void UpdateBuildStep(bool result)
{

            BuildStepStatus status = result ? BuildStepStatus.Succeeded : BuildStepStatus.Failed;
            BuildStore.UpdateBuildStep(BuildUri, GetBuildStepName(), DateTime.Now, status);
        }

        private void AddExceptionBuildStep(Exception e)
        {
            try
            {
                BuildStore.AddBuildStep(BuildUri, "Exception", e.Message);
                BuildStore.UpdateBuildStep(BuildUri, "Exception", DateTime.Now, BuildStepStatus.Failed);
            }
            catch
            {
                // Eat any exceptions.
            }
        }

        private IBuildEngine m_buildEngine;
        private ITaskHost m_hostObject;
        private string m_tfsUrl;
        private string m_buildUri;
        private TeamFoundationServer m_tfs;
        private BuildStore m_buildStore;
    }
}

To use this base class, just override the ExecuteInternal method - put the actual task logic here. Then override the GetBuildStepName and GetBuildStepMessage methods to specify the Name of the build step (which serves as its ID and should therefore be reasonably unique) and the Message of the build step (which will be the string displayed in the build report form).

The Execute method will add a build step (with the specified Name and Message) when task execution starts, and update the build step with the appropriate status and time when execution completes. If an exception is thrown by the ExecuteInternal method, an exception build step will be added (if possible) by the AddExceptionBuildStep method.

Note the TeamFoundationServerUrl and BuildUri properties. These properties will need to be set for derived tasks to function properly, and can be easily set to the TeamFoundationServerUrl and BuildURI properties available during a Team Build (e.g. within TfsBuild.proj).

<Target Name="BeforeBuild">
	<SomeCustomTask 
		TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
		BuildUri="$(BuildURI)" />
</Target>

Happy building!