Gautam Goenka (MSFT)

Continuous Integration with Assembly Version task

Thanks.

Passing custom properties to each individual solutions in Team Build

Though one of my earlier blogs is titled "Building .NET 1.1 application using Team Build", the principal used in that blog can easily be generalized to pass any custom property to each solution/project file while building using Team Build.

Say you want to sign each assembly built by a key. One option is to open each project and set the SignAssembly and AssemblyOriginatorKeyFile properties to appropriate value. This is quite a work if there are more than handful of projects. Moreover, this will not work if want the signing to be there only for Team Build and not when developer builds on her desktop.  (Or, may be you want to use two different keys.)

There is another option to do this easily in Team Build - change the AdditionalPropertiesForBuildTarget mentioned in the above blog to the following - 

<AdditionalPropertiesForBuildTarget>

SignAssembly=true;AssemblyOriginatorKeyFile=Z:\sign\mykey.snk

</AdditionalPropertiesForBuildTarget>

This will do the trick!

Thanks,

Gautam

Writing a custom MSBuild Logger for Team Build

While building using Team Build, the build process creates one log file (for compilation and code analysis errors and warnings) per platform-flavor for all solutions.  However, few weeks back, while talking to a customer about Team Build, a new requirement came up. The customer wanted to have one log file per platform-flavor per solution. In his scenario, they had not ran code analysis before and turning that on was resulting in lots of errors/warnings all across the team project.  He wanted to separate the warnings out into different log files per solution as the owners were different.

He asked me if this could be done. Well yes, anything for the customer!!!

Attached is the code for custom MSBuild logger that -

1. Listens to build error and warning events and creates one log file per solution per platform-flavor. This is different from the standard Team Build logger, which creates one log per platform-flavor for all solutions.
2. Each log file contains all the compilation and code analysis errors/warnings in that solution. 
3. The log files created are copied to the drop location along with the other log files created by standard Team Build logger.

Building .NET 1.1 application using Team Build

One of the FAQs in Team Foundation forums have been on "how to build .NET 1.1 application using Team Build".   My colleague Nagaraju put up this blog to give out detailed steps for this. Apart from this, there were various other solutions on how to build .NET 1.1 using MSBuild (and hence in turn by Team Build) from different folks like one by Jomo.

All this solutions were essentially a hack... they mostly worked but lacked elegance.  The developers wanted better solution.  Considering the increasing demand for better support for building .NET 1.1 using MSBuild, the MSBuild team came up with project called MSBee or MSBuild Everett (code name for VS 2003) Environment.  The Beta 2 of MSBee is available here.

The MSBee could be used with Team Build also.  To do so, you need to do the following -

1. Install MSBee and other required components on the Build Machine. (Refer MSBee ReadMe)
2. Upgrade the solutions that you want to build to Visual Studio 2005 format using the wizard or the /upgrade command line switch.  (If you want to still use VS 2003, you can backup the solutions and upgrade.)
3. Modify the TFSBuild.proj file as mentioned below.

The modification required in TFSBuild.proj are -

a) Download and checkin the attached BuildingFx11inTB.targets alongside TFSBuild.proj. (I am trying attachment to a blog for the first time... hopefully it will work!)

b) Add an import statement to TFSBuild.proj file after import of Microsoft.TeamFoundation.Build.targets file.  The import statement would look like -

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

c) Add following property to point to the 1.1 targets file -

<PropertyGroup> <AdditionalPropertiesForBuildTarget>CustomAfterMicrosoftCommonTargets=$(ProgramFiles)\MSBuild\MSBee\MSBuildExtras.Fx1_1.CSharp.targets</AdditionalPropertiesForBuildTarget> </PropertyGroup>

And thats all. The steps a) and b) are required because the current version of the targets file did not provide easy way to pass additional properties while compiling individual project files. We are considering fixing this for next release to simplify this.

Note that the above solutions assume that all your projects are in C#. Instead, if all the projects are in VB, change the MSBuildExtras.Fx1_1.CSharp.targets in the property defination above to MSBuildExtras.Fx1_1.VisualBasic.targets. In case you have mix of C# and VB, use the workaround suggested in section 4.2.2 of "MSBee ReadMe.doc"

Thanks!

Using AssemblyInfo task with Team Build

Fixed a bug in the snippet as pointed out by Peter from Microsoft Consulting Service. I was earlier using ItemGroup to get all AssemblyInfoFiles which gets executed before any target (and hence before Get task). So, the items in AssemblyInfoFiles may be outdated. The right approach is to use CreateItem task inside AfterGet target.

Neil Enns of MSBuild team has put up a task to automatically update assembly info (like assembly version) of Visual Studio projects as part build process here.

The task can easily be extended to work with Team Build. The sample TFSBuild.proj file that works is below.  The changes made by me are underlined.

Note -

1. The import statement should come second.
2. I installed AssemblyInfoTask in GAC.  If you have installed it in Application Data folder, you will need to change the import statement accordingly.
3. This assumes that you are changing all AssemblyInfo.cs files to same version.  If that is not the case, have multiple AssemblyInfoSpec property and repeat the tasks for each property.

Thanks,

Gautam

<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="DesktopBuild"
         xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <!-- TO EDIT BUILD TYPE DEFINITION

  To edit the build type, you will need to edit this file which was generated
  by the Create New Build Type wizard.  This file is under source control and
  needs to be checked out before making any changes.

  The file is available at -
      $/{TeamProjectName}/TeamBuildTypes/{BuildTypeName}
  where you will need to replace TeamProjectName and BuildTypeName with your
  Team Project and Build Type name that you created

  Checkout the file
    1. Open Source Control Explorer by selecting View -> Other Windows -> Source Control Explorer
    2. Ensure that your current workspace has a mapping for the $/{TeamProjectName}/TeamBuildTypes folder and 
       that you have done a "Get Latest Version" on that folder
    3. Browse through the folders to {TeamProjectName}->TeamBuildTypes->{BuildTypeName} folder
    4. From the list of files available in this folder, right click on TfsBuild.Proj. Select 'Check Out For Edit...'


  Make the required changes to the file and save

  Checkin the file
    1. Right click on the TfsBuild.Proj file selected in Step 3 above and select 'Checkin Pending Changes'
    2. Use the pending checkin dialog to save your changes to the source control

  Once the file is checked in with the modifications, all future builds using
  this build type will use the modified settings
  -->
  <!-- Do not edit this -->
  <Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v8.0\TeamBuild\Microsoft.TeamFoundation.Build.targets" />
  <Import Project="$(MSBuildExtensionsPath)\Microsoft\AssemblyInfoTask\Microsoft.VersionNumber.Targets"/>
  <ProjectExtensions>
    <!--  DESCRIPTION
     The description is associated with a build type. Edit the value for making changes.
    -->
    <Description>
    </Description>
    <!--  BUILD MACHINE
     Name of the machine which will be used to build the solutions selected.
    -->
    <BuildMachine>gautamg-lt</BuildMachine>
  </ProjectExtensions>
  <PropertyGroup>
    <!--  TEAM PROJECT
     The team project which will be built using this build type.
    -->
    <TeamProject>GautamG0102</TeamProject>
    <!--  BUILD DIRECTORY
     The directory on the build machine that will be used to build the
     selected solutions. The directory must be a local path on the build
     machine (e.g. c:\build).
    -->
    <BuildDirectoryPath>D:\BuildLocation</BuildDirectoryPath>
    <!--  DROP LOCATION
      The location to drop (copy) the built binaries and the log files after
     the build is complete. This location has to be a valid UNC path of the
     form \\Server\Share. The build machine service account and application
     tier account need to have read write permission on this share.
    -->
    <DropLocation>\\gautamg-lt\drops</DropLocation>
    <!--  TESTING
     Set this flag to enable/disable running tests as a post build step.
    -->
    <RunTest>false</RunTest>
    <!--  WorkItemFieldValues
      Add/edit key value pairs to set values for fields in the work item created
      during the build process. Please make sure the field names are valid 
      for the work item type being used.
    -->
    <WorkItemFieldValues>Symptom=build break;Steps To Reproduce=Start the build using Team Build</WorkItemFieldValues>
    <!--  CODE ANALYSIS
       To change CodeAnalysis behavior edit this value. Valid values for this
       can be Default,Always or Never.

     Default - To perform code analysis as per the individual project settings
     Always  - To always perform code analysis irrespective of project settings
     Never   - To never perform code analysis irrespective of project settings
     -->
    <RunCodeAnalysis>Never</RunCodeAnalysis>
    <!--  UPDATE ASSOCIATED WORK ITEMS
     Set this flag to enable/disable updating associated workitems on a successful build
    -->
    <UpdateAssociatedWorkItems>true</UpdateAssociatedWorkItems>
    <!-- Title for the work item created on build failure -->
    <WorkItemTitle>Build failure in build:</WorkItemTitle>
    <!-- Description for the work item created on build failure -->
    <DescriptionText>This work item was created by Team Build on a build failure.</DescriptionText>
    <!-- Text pointing to log file location on build failure -->
    <BuildlogText>The build log file is at:</BuildlogText>
    <!-- Text pointing to error/warnings file location on build failure -->
    <ErrorWarningLogText>The errors/warnings log file is at:</ErrorWarningLogText>
  </PropertyGroup>
  <PropertyGroup>
    <!-- Assembly version properties. Add others here -->
    <AssemblyMajorVersion>9</AssemblyMajorVersion>
    <AssemblyFileMajorVersion>9</AssemblyFileMajorVersion>

    <!-- TF.exe -->
    <TF>&quot;$(TeamBuildRefPath)\..\tf.exe&quot;</TF>

    <!-- AssemblyInfo file spec -->
    <AssemblyInfoSpec>AssemblyInfo.cs</AssemblyInfoSpec>
  </PropertyGroup>

  <!-- Set this to non-existent file to force rebuild. -->
  <ItemGroup>
    <IntermediateAssembly Include="$(SolutionRoot)\foobar.dll"/>
  </ItemGroup>

  <ItemGroup>
    <!--  SOLUTIONS
     The path of the solutions to build. To add/delete solutions, edit this
     value. For example, to add a solution MySolution.sln, add following line -
         <SolutionToBuild Include="$(SolutionRoot)\path\MySolution.sln" />

     To change the order in which the solutions are build, modify the order in
     which the solutions appear below.
    -->
    <SolutionToBuild Include="$(SolutionRoot)\ConsoleApplication4.sln" />
  </ItemGroup>
  <ItemGroup>
    <!--  CONFIGURATIONS
     The list of configurations to build. To add/delete configurations, edit
     this value. For example, to add a new configuration, add following lines -
         <ConfigurationToBuild Include="Debug|x86">
             <FlavorToBuild>Debug</FlavorToBuild>
             <PlatformToBuild>x86</PlatformToBuild>
         </ConfigurationToBuild>

     The Include attribute value should be unique for each ConfigurationToBuild node.
    -->
    <ConfigurationToBuild Include="Release|Any CPU">
      <FlavorToBuild>Release</FlavorToBuild>
      <PlatformToBuild>Any CPU</PlatformToBuild>
    </ConfigurationToBuild>
  </ItemGroup>
  <ItemGroup>
    <!--  TEST ARGUMENTS
     If the RunTest is set to true then the following test arguments will be
     used to run tests.

     To add/delete new testlist or to choose a metadata file (.vsmdi) file, edit this value.
     For e.g. to run BVT1 and BVT2 type tests mentioned in the Helloworld.vsmdi file, add the following -

     <MetaDataFile Include="$(SolutionRoot)\HelloWorld\HelloWorld.vsmdi">
         <TestList>BVT1;BVT2</TestList>
     </MetaDataFile>

     Where BVT1 and BVT2 are valid test types defined in the HelloWorld.vsmdi file.
     MetaDataFile - Full path to test metadata file.
     TestList - The test list in the selected metadata file to run.

     Please note that you need to specify the vsmdi file relative to $(SolutionRoot)
    -->
    <MetaDataFile Include=" ">
      <TestList> </TestList>
    </MetaDataFile>
  </ItemGroup>
  <ItemGroup>
    <!--  ADDITIONAL REFERENCE PATH
     The list of additional reference paths to use while resolving references.
     For example,
         <AdditionalReferencePath Include="C:\MyFolder\" />
         <AdditionalReferencePath Include="C:\MyFolder2\" />
    -->
  </ItemGroup>

  <Target Name="AfterGet" Condition="'$(IsDesktopBuild)'!='true'">
    <!-- Set the AssemblyInfoFiles items dynamically -->
    <CreateItem Include="$(SolutionRoot)\**\$(AssemblyInfoSpec)">
      <Output ItemName="AssemblyInfoFiles" TaskParameter="Include" />
    </CreateItem>

    <Exec WorkingDirectory="$(SolutionRoot)"
          Command="$(TF) checkout /recursive $(AssemblyInfoSpec)"/>
  </Target>

  <Target Name="AfterCompile" Condition="'$(IsDesktopBuild)'!='true'">
    <Exec WorkingDirectory="$(SolutionRoot)"
          Command="$(TF) checkin /comment:&quot;Auto-Build: Version Update&quot; /noprompt /override:&quot;Auto-Build: Version Update&quot; /recursive $(AssemblyInfoSpec)"/>
  </Target>

  <!-- In case of Build failure, the AfterCompile target is not executed. Undo the changes -->
  <Target Name="BeforeOnBuildBreak" Condition="'$(IsDesktopBuild)'!='true'">
    <Exec WorkingDirectory="$(SolutionRoot)"
          Command="$(TF) undo /noprompt /recursive $(AssemblyInfoSpec)"/>
  </Target>
</Project>

Who requested this build?

In certain scenarios you may want to take different actions based on user who have requested the build (or may simply want to report that in log file).  Though the Team Build stores the name of the user who has requested the build (and this is shown in the UI), the value is not passed to the build process.

However, do not get dishearten.  There is a workaround - use the task code given below to get the RequestedBy value.

Steps to use -

/**===========================================================================
 * File: GetRequestedBy.cs
 * ----------------------------------------------------------------------------
 *
 * This file is part of the Microsoft Visual Studio Team System Samples.
 *
 * Copyright(C)  2004  Microsoft Corporation. All rights reserved.
 *
 * THIS CODE AND INFORMATION ARE PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND,
 * WHETHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED
 * WARRANTIES OF MERCHANTABILITY AND/OR FITNESS FOR A PARTICULAR PURPOSE.
 * ============================================================================
 */

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


namespace Microsoft.TeamFoundation.Build.Samples
{
    /// <summary>
    /// This task will update the build number and Drop location on the server
    /// Inputs are the Tfs name, build Uri, build number, and drop location.
    /// errors are reported as message and get logged.
    /// </summary>
    public class GetRequestedBy: Task
    {
        [Required]
        public string TeamFoundationServerUrl
        {
            set
            {
                m_tfsUrl = value;
            }

            get
            {
                return m_tfsUrl;
            }
        }

        [Required]
        public string BuildUri
        {
            set
            {
                m_buildUri= value;
            }

            get
            {
                return m_buildUri;
            }
        }

        [Output]
        public string RequestedBy
        {
            set
            {
                m_requestedBy = value;
            }

            get
            {
                return m_requestedBy;
            }
        }

        override public bool Execute()
        {
            // Output parameters - can be helpful in debugging
            string message = string.Format(CultureInfo.InvariantCulture,
                "GetRequestedBy TeamFoundationServerUrl={0}, BuildUri={1}",
                TeamFoundationServerUrl, BuildUri);

            Log.LogMessage(MessageImportance.Normal, message);

            try
            {
                TeamFoundationServer tfs = TeamFoundationServerFactory.GetServer(m_tfsUrl);
                BuildStore buildStore = (BuildStore)tfs.GetService(typeof(BuildStore));
                RequestedBy = buildStore.GetBuildDetails(m_buildUri).RequestedBy;
            }
            catch (Exception ex)
            {
                // log the error
                Log.LogError(ex.Message);
                return false;
            }

            return true;
        }

        private string m_tfsUrl;
        private string m_buildUri;
        private string m_requestedBy;
    }
}

How to find if build is in progress?

In v1, we do not exposed an option in the UI or otherwise to check whether the build machine is free or not.  If the build machine is not free and you fire a build, you get an error back, which is fine.  However, if you want to queue builds or pick one of the machines that is free, you need a way to check whether the build machine is free or not.

You can do this using the code below.

1. Copy/paste the code below in a file called CheckBuildMachine.cs
2. Compile the file using following command -

   csc /r:%SystemDrive%\Windows\assembly\GAC_32\Microsoft.TeamFoundation.Build.Common\8.0.0.0__b03f5f7f11d50a3a\Microsoft.TeamFoundation.Build.Common.dll CheckBuildMachine.cs

3. Run -
   CheckBuildMachine <your team project> <your build machine>
   to check whether the build machine is free or not.

The build machine is tied to one Team Foundation Server and can do one build per team project at a time. Multiple builds of different team project can be done simultaneously.

You can also use the zip file attached to download the complete solution and build it in VS.

Thanks,

Gautam

/**===========================================================================
 * File: CheckBuildMachine.cs
 * ----------------------------------------------------------------------------
 *
 * This file is part of the Microsoft Visual Studio Team System Samples.
 *
 * Copyright(C)  2004  Microsoft Corporation. All rights reserved.
 *
 * THIS CODE AND INFORMATION ARE PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND,
 * WHETHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED
 * WARRANTIES OF MERCHANTABILITY AND/OR FITNESS FOR A PARTICULAR PURPOSE.
 * ============================================================================
 */

using System;
using System.Diagnostics;
using Microsoft.TeamFoundation.Build.Common;

namespace Microsoft.TeamFoundation.Build.Samples
{
    class CheckBuildMachine
    {
        static void Main(string[] args)
        {
            if (args.Length == 1 && AskingForHelp(args[0]))
            {
                ShowUsage(0);
            }

            if (args.Length < 2 || args.Length > 3)
            {
                Console.Error.WriteLine("Invalid arguments.");
                ShowUsage(1);
            }

            teamProject = args[0];
            machine = args[1];
            if (args.Length == 3)
            {
                if (!int.TryParse(args[2], out port))
                {
                    Console.Error.WriteLine("Invalid port: {0}", args[2]);
                    ShowUsage(1);
                }
            }

            CheckMachine();
        }

        private static void CheckMachine()
        {
            Debug.Assert(machine != null);
            string uri = string.Format(BuildAgentUri, machine, port, typeof(IBuildAgent).FullName);

            try
            {
                IBuildAgent agent = (IBuildAgent)Activator.GetObject(typeof(IBuildAgent), uri);
                if (agent.IsBuildInProgress(teamProject))
                {
                    Console.WriteLine("The machine {0} not free.", machine);
                }
                else
                {
                    Console.WriteLine("The machine {0} is free.", machine);
                }
            }
            catch (Exception ex)
            {
                Console.Error.WriteLine("Unable to reach machine {0}. {1}", machine, ex.Message);
            }
        }

        private static bool AskingForHelp(string arg)
        {
            if (StringComparer.OrdinalIgnoreCase.Equals(arg, "/?") ||
                StringComparer.OrdinalIgnoreCase.Equals(arg, "-?") ||
                StringComparer.OrdinalIgnoreCase.Equals(arg, "/h") ||
                StringComparer.OrdinalIgnoreCase.Equals(arg, "-h"))
                return true;

            return false;
        }

        private static void ShowUsage(int exitCode)
        {
            Console.WriteLine("Usage:");
            Console.WriteLine("\tCheckBuildMachine.exe <team project> <build machine> [<port>]");
            Console.WriteLine("\tThe default value of port is 9191.");
            Console.WriteLine("Example:");
            Console.WriteLine("\tCheckBuildMachine.exe MyProject MyBuildMachine");

            Environment.Exit(exitCode);
        }

        private static string teamProject;
        private static string machine;
        private static int port = 9191; // default port

        private const string BuildAgentUri = "tcp://{0}:{1}/{2}";
    }
}

Setting different drop location with same build type

There was this question in Team Foundation forums -

We have developers at two different sites.   Is it possible to have a single team build type that we can run on build machines at each site using a drop location local to the site?

In Team Build, there is an option to override Build Directory but there is no option to override Drop Location.  However, one can override the Drop Location by using Build Directory to distinguish between two sites.

For example, the current entry in TFSBuild.proj looks like -

<DropLocation>\\GAUTAMG6\drops</DropLocation>

Remove that line and add -

<DropLocation Condition=" '$(BuildDirectoryPath)'=='D:\MySite2' ">\\MySite2Server\drops</DropLocation>

The the site 1 should pass D:\MySite1 as build directory in the UI (or command line) and site 2 should pass D:\MySite2.

The complete forums thread is here.  (There is a known issue here in Beta 3.  Please refer the thread for the workaround.)

Happy Building!!!
Gautam

My list of interesting stuff at PDC2005

My laundry list of product/technology/features that I liked at PDC (based mostly on keynotes):

Product/Technology:

1. Visual Studio Team System and Team Foundation Server (hey, it is my product :)) - This will give IBM Rational run for their bucks.
2. Windows Presentation Foundation (a.k.a. Avalon) and XAML - The next generation mind-blowing UI
3. Expression suite (Acryllic, Sparkle and Quartz) - The new super cool designer!
4. Linq - Native syntax for database query built into the language!!!
5. WinFS - The new relational file system for Windows.

Windows Vista Features:

1. Quick search based on WinFS is everywhere even in Start menu where it can filter the "All Programs" list.
2. Hovering mouse over minimized window in task bar (or ALT+TAB action) gives the live preview of the window.
3. Sidebar and gadgets - For Microsoft employees, this is the old "Sideshow"
4. There will be "Parental Control" on the PC so you can set permission what you kids can and cannot do.
5. The super fetch cache and auto-defragmentation features for better performance. One can even add a USB drive to your laptop to increase the cache memory!

Office Features:

1. The new result oriented UI a.k.a Ribbons!
2. There is live preview of formatting changes (like font) as you select it. There is no need to apply the change to check it out.
3. Excel: The data in cells can be graphically visualized in various ways inside the cell.  For example, one can add a bar graph to bunch of cells inside the cell itself.
4. Outlook: Preview pane for attachment inside Outlook. No need to double click on the attachments!!!
5. Outlook: RSS reader built in Outlook
6. Sharepoint: Built in RSS feed feature and in conjunction with the above, ability to have all documents offline in Outlook

Obviously, there were lots and lots of other interesting stuff.

First blog is tough

First blog is tough to write. So I think; it took me 6 months after creating the id to come up with this first blog.  Do not let your ignorance compel you into thinking this as procrastination. I have list of 1001 valid excuses! (One of which is I could not blog because the dog wagged his tail! [:)])

Even though I have been lazy in writing, I have been reading lot of blogs – of my team mates – Abhinaba Basu, John Lawrence; of my other esteemed colleagues – Somasegar, Don Box and other folks like – Crabby Lady.  Every time I read a boring blog (check your browser it is taking you to wrong link), I felt good about not writing. On the other hand, an interesting blog (yeah, now your browser is working fine) use to make my resolution to blog stronger.  I must have read enough interesting ones…

One of the tough parts of first blog is introduction; especially for an introvert person like me it is no easy task.  It would have been good if I had a page like www.gautamgoenka.com where I could redirect for introduction.  No one would have bothered to check it and I would have got away with it. Er, may be I should have still done this…

Anyways, here is the trivia; I am Gautam Goenka, working as a development lead at Microsoft India Development Center, Hyderabad, India.  Presently I am working on a cool release - Visual Studio Team System, more specifically Team Build component of Team Foundation Server.  I have been in Microsoft for over 5 years and in previous incarnations have worked on products like Visual J# and Outlook Connector for IBM Lotus Domino.

I am very excited to be part of Team Foundation Server team.  It is great to see the product shaping along nicely.  We have been using it internally for several months now and with each refresh of new bits, I can clearly see that the product is much more robust, reliable and with new user-friendly features.  More on these in coming blogs…

Now that I have written the first blog, I assume subsequent ones will not be this tough.  Let us hope Newton’s law of inertia will work in my favor!