• Jim Lamb's post on creating a custom workflow activity for TFS Build 2010. 
• Patrick Carnahan's posts on customizing build information (part 1, part 2), and an Introduction to Windows Workflow 4.0.
• Adam Root's workaround for a Beta 2 bug where 9.0 test projects end up with a bogus reference to the 4.0 framework and fail with a BadImageFormatException.
• Jason Prickett's posts on new build deletion options, displaying custom build information in Visual Studio, and modifying the default display of build information in Visual Studio.

There should be lots more good stuff coming on all these blogs, and on my own, over the next weeks and months. 

There are four ways (that I know of, at least) to author a custom WF activity - using the WF Designer / XML Editor and composing your custom activity in XAML; composing your custom activity in code; writing a custom CodeActivity; or writing a custom NativeActivity.  This list is more or lest organized by degree of difficulty, and more or less by preference as well. 

The first two approaches involve building a new activity up from existing activities - when possible, this is a good strategy, since it has several advantages over writing custom code to do your work:

1. Composed activities obviously re-use code to a high degree, which is always a good idea - why reinvent the wheel if you don't have to?
2. Composed activities are by their nature cancellable by the workflow runtime, meaning that builds running your custom activity will be easy to stop cleanly.
3. Composed activities can participate in workflow tracking, meaning that their internal progress can be easily tracked as they execute.  (If you don't want their progress to be tracked when running in a build, you can turn this behavior off using Microsoft.TeamFoundation.Build.Workflow.Tracking.ActivityTrackingAttribute.)
4. It's comparatively easy, at least once you get the hang of it.

I'll be tackling these approaches in this post, and the CodeActivity and NativeActivity approaches in a subsequent post.  The activity I'll be writing takes in a server path to a script file and a Workspace object (along with a couple of other optional parameters), executes the script, and returns the exit code.  The assumption, then, is that this activity will be used in a build process at some point after the workspace for the build has been set up and after that workspace has been synched.  Note that a big difference between MSBuild and WF is that WF can hand actual objects around between activities, as opposed to MSBuild which basically just hands strings around. 

To write my activity, I created a new WF ActivityLibrary project, added references to Microsoft.TeamFoundation.Build.Client, Microsoft.TeamFoundation.Build.Common, Microsoft.TeamFoundation.Build.Workflow, Microsoft.TeamFoundation.VersionControl.Client, and Microsoft.TeamFoundation.VersionControl.Common.  I then added the various arguments I wanted my activity to have using the Arguments flyout in the WF designer, dragged and dropped a Sequence activity and the two TFS Build activities I needed, set the appropriate properties, etc.  Here's what it looks like in the Beta 1 WF Designer:

And here's the XAML:

<p:Activity mc:Ignorable="" x:Class="ActivityLibrary1.InvokeScript" xmlns="http://schemas.microsoft.com/netfx/2009/xaml/activities/design" xmlns:__InvokeScript="clr-namespace:ActivityLibrary1;" xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:mtbwa="clr-namespace:Microsoft.TeamFoundation.Build.Workflow.Activities;assembly=Microsoft.TeamFoundation.Build.Workflow" xmlns:mtvc="clr-namespace:Microsoft.TeamFoundation.VersionControl.Client;assembly=Microsoft.TeamFoundation.VersionControl.Client" xmlns:p="http://schemas.microsoft.com/netfx/2009/xaml/activities" xmlns:sad="clr-namespace:System.Activities.Debugger;assembly=System.Activities" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
  <x:Members>
    <x:Property Name="Arguments" Type="p:InArgument(x:String)" />
    <x:Property Name="Script" Type="p:InArgument(x:String)" />
    <x:Property Name="WorkingDirectory" Type="p:InArgument(x:String)" />
    <x:Property Name="Workspace" Type="p:InArgument(mtvc:Workspace)" />
    <x:Property Name="ExitCode" Type="p:OutArgument(x:Int32)" />
  </x:Members>
  <p:Sequence DisplayName="Invoke Script From Source Control">
    <p:Sequence.Variables>
      <p:Variable x:TypeArguments="x:String" Name="localScriptPath" />
    </p:Sequence.Variables>
    <mtbwa:ConvertWorkspaceItem DisplayName="Convert Server Path to Local Path" Input="[Script]" Result="[localScriptPath]" Workspace="[Workspace]" />
    <mtbwa:InvokeProcess Arguments="[String.Format(&quot;/c &quot;&quot;{0}&quot;&quot; {1}&quot;, localScriptPath, Arguments)]" DisplayName="Invoke the Script" FileName="[&quot;cmd.exe&quot;]" Result="[ExitCode]" WorkingDirectory="[WorkingDirectory]">
      <mtbwa:InvokeProcess.BeforeExecute>
        <p:ActivityAction x:TypeArguments="x:String">
          <p:ActivityAction.Argument>
            <p:Variable x:TypeArguments="x:String" Name="commandLine" />
          </p:ActivityAction.Argument>
          <mtbwa:WriteBuildMessage Message="[commandLine]" />
        </p:ActivityAction>
      </mtbwa:InvokeProcess.BeforeExecute>
      <mtbwa:InvokeProcess.ErrorDataReceived>
        <p:ActivityAction x:TypeArguments="x:String">
          <p:ActivityAction.Argument>
            <p:Variable x:TypeArguments="x:String" Name="errorData" />
          </p:ActivityAction.Argument>
          <mtbwa:WriteBuildError Message="[errorData]" />
        </p:ActivityAction>
      </mtbwa:InvokeProcess.ErrorDataReceived>
      <mtbwa:InvokeProcess.OutputDataReceived>
        <p:ActivityAction x:TypeArguments="x:String">
          <p:ActivityAction.Argument>
            <p:Variable x:TypeArguments="x:String" Name="outputData" />
          </p:ActivityAction.Argument>
          <mtbwa:WriteBuildMessage Importance="Normal" Message="[outputData]" />
        </p:ActivityAction>
      </mtbwa:InvokeProcess.OutputDataReceived>
    </mtbwa:InvokeProcess>
  </p:Sequence>
</p:Activity>

You might notice that the various ActivityActions in the XAML (which handle writing the command-line and standard output to the build activity log as messages, and standard error as errors) are not present in the designer - we didn't get around to implementing a custom designer for the InvokeProcess activity for Beta 1, so for this activity I had to "drop to XAML" and edit the XML directly.  Normally this shouldn't be required - for the most part you should be able to fully author your custom activities in the WF Designer.  When my activity library project is built, this XAML will be compiled into an activity named InvokeScript (the name comes from the x:Class attribute on the root).

As mentioned above, activities can be composed either in xaml or in code.  To write a composed activity in code, you'll derive from System.Activities.Activity, or System.Activities.Activity<T>, add whatever arguments and so forth you need, and then override the CreateBody method to return your composed implementation.  Here's a second version of my InvokeScript activity, written in C# code:

using System;
using System.Activities;
using System.Activities.Statements;
using System.ComponentModel;
using Microsoft.TeamFoundation.Build.Workflow.Activities;
using Microsoft.TeamFoundation.VersionControl.Client;

namespace ActivityLibrary1
{
    public sealed class InvokeScript2 : Activity<Int32>
    {
        [Browsable(true)]
        [DefaultValue(null)]
        public InArgument<String> Arguments { get; set; }

        [Browsable(true)]
        [DefaultValue(null)]
        public InArgument<String> Script { get; set; }

        [Browsable(true)]
        [DefaultValue(null)]
        public InArgument<String> WorkingDirectory { get; set; }

        [Browsable(true)]
        [DefaultValue(null)]
        public InArgument<Workspace> Workspace { get; set; }

        protected override WorkflowElement CreateBody()
        {
            Variable<String> localScriptPath = new Variable<String>();
            Variable<String> commandLine = new Variable<String>();
            Variable<String> outputData = new Variable<String>();
            Variable<String> errorData = new Variable<String>();

            return new Sequence
            {
                Variables = 
                {
                    localScriptPath
                },
                Activities =
                {
                    new ConvertWorkspaceItem
                    {
                        Input = new InArgument<String>(env => this.Script.Get(env)),
                        Workspace = new InArgument<Workspace>(env => this.Workspace.Get(env)),
                        Result = localScriptPath
                    },
                    new InvokeProcess
                    {
                        FileName = new InArgument<String>(env => "cmd.exe"),
                        Arguments = new InArgument<String>(env => String.Format("/c \"{0}\" {1}", localScriptPath.Get(env), Arguments.Get(env))),
                        WorkingDirectory = new InArgument<String>(env => this.WorkingDirectory.Get(env)),
                        Result = new OutArgument<int>(env => this.Result.Get(env)),
                        BeforeExecute = new ActivityAction<String>
                        {
                            Argument = commandLine,
                            Handler = new WriteBuildMessage
                            {
                                Message = commandLine
                            },
                        },
                        OutputDataReceived = new ActivityAction<String>
                        {
                            Argument = outputData,
                            Handler = new WriteBuildMessage
                            {
                                Message = outputData
                            },
                        },
                        ErrorDataReceived = new ActivityAction<String>
                        {
                            Argument = errorData,
                            Handler = new WriteBuildError
                            {
                                Message = errorData
                            },
                        },
                    },
                },
            };
        }
    }
}

The primary difference between this version and the XAML version is that here I've elevated the single output argument (ExitCode) to the return value of the activity - hence it derives from Activity<Int32>.  The metaphor for activities is methods and functions - when you have a single output, the standard practice is to elevate it to the return value rather than using an OutArgument (but this is not, so far as I know, possible when writing an activity in XAML). 

A hotfix is finally available that will address the remaining parts of the problem - it can be downloaded here.  Note that this hotfix assumes that you have already installed SP1 on your build machine, so make sure to install SP1 and then the hotfix if you are currently running TFS Build 2008 RTM bits.  After this hotfix is applied you should, by default, never see another project-to-project reference build step - I've heard reports from some customers of this reducing their total number of build steps from over 3000 to under 200, so in some cases this can have a dramatic effect on build time (each of those build steps corresponds to a server call made during the build).

The short answer is that this is not really supported in Team Build 2008 (or 2005, for that matter), since by the time your solutions are getting built we have essentially ceded control to MSBuild.  There are three potential methods (that I could think of) for doing this sort of thing:

1. You could specify the individual projects, rather than the solution that contains them, in the SolutionToBuild item group in your TfsBuild.proj file and then just use the Before/AfterCompileSolution targets to execute your custom logic.  This is only appropriate if your solutions are simple containers for your projects - in particular, if you don't have build order logic and/or project-to-project references in your solution that you would need to re-implement in your TfsBuild.proj file.
2. You could use a custom MSBuild "traversal" project in place of your solution, and insert your custom logic into this traversal project before/after the individual projects are compiled.  The simplest thing here would be to start with the the project that MSBuild generates from your solution - in MSBuild 3.5 this project will be written to disk as a *.sln.cache file if you build your solution from the command-line.  The disadvantage to this approach is that you then have two files to maintain in parallel - your solution and your custom traversal project.  One possible workaround here would be to write a custom MSBuild task to generate this traversal project automatically as part of the build.  If anybody is adventurous enough to attempt this task and generous enough to share, please let me know and I'd be happy to post your efforts in a follow up. 
3. Finally, you could put the before/after compile logic into the individual projects themselves, either directly or via in imported *.targets file.  Individual .NET projects have their own Before/AfterBuild extensibility targets that could be utilized for this purpose. 

This last option strikes me as the best one when including simplicity in the calculation...  The targets file would look something like this:

<?xml version="1.0" encoding="utf-8"?>
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

  <!-- Only execute this custom logic when the project is building under Team Build. -->
  <Target Name="AfterBuild" Condition=" '$(TeamBuildConstants)' == '_TEAM_BUILD_' ">
    <!-- Put your custom logic here. -->
  </Target>
  
</Project>

You would then check this targets file in alongside your TfsBuild.proj file and import it into your individual projects after the import of Microsoft.Common.targets using a relative path.  For example, the end of a *.csproj file might look like:

  <Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
  <Import Project="..\..\TeamBuildTypes\SomeDefinition\AfterCompileProject.targets"/>
</Project>

  <Target Name="AfterCompile">
    <Message Text="%(CompilationOutputs.Solution) built %(Identity) for %(Platform)|%(Configuration)." /> 
  </Target>

...might produce the following output:

  C:\BuildLocation\TeamProject\Definition\Sources\Foo.sln built C:\BuildLocation\TeamProject\Definition\Binaries\x86\Debug\Foo.exe for x86|Debug.
  C:\BuildLocation\TeamProject\Definition\Sources\Bar.sln built C:\BuildLocation\TeamProject\Definition\Binaries\x86\Debug\Bar.exe for x86|Debug.
  C:\BuildLocation\TeamProject\Definition\Sources\Foo.sln built C:\BuildLocation\TeamProject\Definition\Binaries\x86\Release\Foo.exe for x86|Release.
  C:\BuildLocation\TeamProject\Definition\Sources\Bar.sln built C:\BuildLocation\TeamProject\Definition\Binaries\x86\Release\Bar.exe for x86|Release.

Of course, producing that output is not particularly exciting.  It is easy to imagine lots of other cool things that can be done with this information, however, including copying all build outputs to the drop location without putting them in the default build location (where they all end up in a single folder).  I'm sure users of Team Build will come up with lots of other creative uses for this item group as well.

<?xml version="1.0" encoding="utf-8"?>
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="3.5">
  <Target Name="EndToEndIteration">
    <Exec Command="SomeScript.cmd" />
  </Target>
</Project>

Of course, most of the Team Build goodness comes from executing the standard targets while having our logger attached, so this approach will not generate a lot of information - no build steps will show up in the build report within VS, it won't keep track of errors/warnings, no data will be pushed to the warehouse (and thus reporting across builds will not work), and so forth.

If you can abstract your custom build script down to the compilation portion, and let the standard build process handle the Get, the Label, etc. you'll be in better shape.  To do this, just override the BeforeCompile target and execute your custom script there, leaving the rest of the TfsBuild.proj file (especially the import of Microsoft.TeamFoundation.Build.targets) alone.

I started responding to the forum post, and then figured it would make a good blog post instead.  (Of course, I've posted a link to this post in the forums...)

So - to modify the default behavior and associate changesets and work items only since the last successful build, you'll need to do three things:

1. Skip the default logic to associate changesets and work items.  This is pretty simple - just set the SkipGetChangesetsAndUpdateWorkItems property to true.
2. Write a custom task to find the last successful build and return its label.
3. Call this custom task and then call the GenCheckinNotesUpdateWorkItems task with its output.

Lucky for you, I've already written the custom task (or at least a simple version of it).  Here is the source for it:

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

namespace BlogProjects
{
    public class GetLastSuccessfulBuildLabel : ITask
    {
        #region Properties

        [Required]
        public String BuildDefinitionName
        {
            get
            {
                return m_buildDefinitionName;
            }
            set
            {
                m_buildDefinitionName = value;
            }
        }

        [Output]
        public String LastSuccessfulBuildLabel
        {
            get
            {
                return m_lastSuccessfulBuildLabel;
            }
        }

        [Required]
        public String TeamFoundationServerUrl
        {
            get
            {
                return m_teamFoundationServerUrl;
            }
            set
            {
                m_teamFoundationServerUrl = value;
            }
        }

        [Required]
        public String TeamProject
        {
            get
            {
                return m_teamProject;
            }
            set
            {
                m_teamProject = value;
            }
        }

        #endregion

        #region ITask Members

        public bool Execute()
        {
            TeamFoundationServer tfs = TeamFoundationServerFactory.GetServer(TeamFoundationServerUrl);
            IBuildServer buildServer = (IBuildServer)tfs.GetService(typeof(IBuildServer));

            IBuildDetailSpec spec = buildServer.CreateBuildDetailSpec(TeamProject, BuildDefinitionName);
            spec.MaxBuildsPerDefinition = 1;
            spec.Status = BuildStatus.Succeeded;
            spec.QueryOrder = BuildQueryOrder.FinishTimeDescending;

            IBuildQueryResult queryResult = buildServer.QueryBuilds(spec);

            if (queryResult.Builds.Length > 0)
            {
                m_lastSuccessfulBuildLabel = queryResult.Builds[0].LabelName;
            }

            return true;
        }

        public IBuildEngine BuildEngine
        {
            get
            {
                return m_buildEngine;
            }
            set
            {
                m_buildEngine = value;
            }
        }

        public ITaskHost HostObject
        {
            get
            {
                return m_taskHost;
            }
            set
            {
                m_taskHost = value;
            }
        }

        #endregion

        #region Private Members

        private IBuildEngine m_buildEngine;
        private ITaskHost m_taskHost;
        private String m_teamFoundationServerUrl;
        private String m_buildDefinitionName;
        private String m_teamProject;
        private String m_lastSuccessfulBuildLabel;

        #endregion
    }
}

Note the fancy querying that is possible with an IBuildDetailSpec - pretty cool... 

Calling the custom task should be similarly simple.  Something like the following should do the trick:

  <Target Name="BeforeGetChangesetsAndUpdateWorkItems">

    <GetLastSuccessfulBuildLabel TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
                                 TeamProject="$(TeamProject)" 
                                 BuildDefinitionName="$(BuildDefinitionName)">
      <Output TaskParameter="LastSuccessfulBuildLabel" PropertyName="LastSuccessfulBuildLabel" />
    </GetLastSuccessfulBuildLabel>

    <GenCheckinNotesUpdateWorkItems TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
                                    BuildUri="$(BuildUri)"
                                    BuildNumber="$(BuildNumber)"
                                    CurrentLabel="$(LabelName)@$(LabelScope)"
                                    LastLabel="$(LastSuccessfulBuildLabel)"
                                    UpdateWorkItems="$(UpdateAssociatedWorkItems)"
                                    ContinueOnError="true" />

  </Target>

Hope this helps!

UPDATE: My original post had a typo - the property SkipGetChangesetsAndUpdateWorkItems was missing its And.  My apologies to anyone who banged their head against the wall trying to figure out why it wasn't working!

To attach a single name/value pair to a build, you would do something like this:

        TeamFoundationServer tfs = TeamFoundationServerFactory.GetServer(tfsUrl);
        IBuildServer buildServer = (IBuildServer)tfs.GetService(typeof(IBuildServer));
        IBuildDetail buildDetail = buildServer.GetBuild(buildUri);

        IBuildInformationNode node = buildDetail.Information.CreateNode();

        node.Type = "MyCompany.Custom";
        node.Fields["key"] = "value";

        buildDetail.Information.Save();

To retrieve the same name/value pair from the build, you would do something like this:

        TeamFoundationServer tfs = TeamFoundationServerFactory.GetServer(tfsUrl);
        IBuildServer buildServer = (IBuildServer)tfs.GetService(typeof(IBuildServer));
        IBuildDetail buildDetail = buildServer.GetBuild(buildUri);

        List<IBuildInformationNode> nodes = buildDetail.Information.GetNodesByType("MyCompany.Custom");

        if (nodes.Count > 0)
        {
            foreach (IBuildInformationNode node in nodes)
            {
                String value = node["key"];

                // Do something...
            }
        }

Note that the information node storage is hierarchical, so you can get a lot fancier than this if you want/need to!  Note that full documentation of the Orcas TFS Build Object Model can be found here.

Make sure to follow the instructions for viewing it after downloading:

Method 1

1. Double-click the .chm file.
2. In the Open File-Security Warning dialog box, clear the Always ask before opening this file check box.
3. Click Open.

1. Right-click the CHM file, and then click Properties.
2. Click Unblock.
3. Double-click the .chm file to open the file.

I'm yanking the Beta 2 documentation now that this has been posted...

Other folks at the booth will include my fellow Visual Studio North Carolina folks Ed Hintz (a man of many hats, including Dev Lead for the Version Control Client and Team System Web Access teams and Power Tools guru), and Chris Rathjen (tester extraordinaire on the Admin & Ops team).

Hope to see lots of you there!