An Overview of Team Build in VSTS

Posted by: Subodh Sohoni , on 3/7/2008, in Category VSTS & TFS (Azure DevOps)
Views: 34172
Abstract: In this article we will study Team Build which is the way to create and execute a build. We will also study the engine behind Team Build called MSBuild .
An Overview of Team Build in VSTS
 
Many developers think of build as compilation process which happens when you click F5 in the visual studio. These developers are thinking about the compilation of code which they have created. But in a team environment, there are many other developers who are writing code and one has to compile code created by all. One of the reasons such a compilation or “The build” is required, is to check the effects of code written in one module on the other modules. For example, if a class library contains a class which has a method, which returns an integer whereas the client module of that class library may have a method call for the same method which assumes string as the return type will be incompatible to each other. To find that all the created code integrates and works with each other, we need to build it together.
In Visual Studio Team System, Microsoft has provided a wizard to create such a build. In this article we will study Team Build which is the way to create and execute such a build. We will also study the engine behind Team Build called MSBuild.
Team Build
With team build we can create a team build type which encapsulate a script to be executed during the build. Team build also provides certain configuration properties which will be used during execution. We start with creating a new team build type through the team explorer. It starts a wizard in which we provide following information
When we complete the wizard, it creates a TfsBuild.proj file which is an XML file of configuration. That file is used by MSBuild to execute the build. We can now execute the build any time.
If we need to customize the build, we can open the script file (TfsBuild.proj) and edit the parameter to be passed to MSBuild.
Team Build does not have any in-built scheduler and so it does not provide scheduled builds out of the box. However, it does have a command line tool to start team-builds. Any scheduler like the Windows Task Scheduler can be easily setup to use this command line Team Build utility to start builds at predetermined time. The Task Scheduler can be setup using a simple batch file or manually using the Add Scheduled task wizard that comes with Windows.
Since the scheduler will use the command line TfsBuild.exe utility, you'll need to start the scheduler on either any one of the TFS clients or on a Build Machine.
To open Scheduled Tasks on Windows XP or Windows 2003, click Start > All Programs, > Accessories > System Tools > Scheduled Tasks and then Add Scheduled Task. Then choose the TfsBuild.exe (ProgramFiles\Microsoft Visual Studio 8\Common7\IDE\TfsBuild.exe) as the executable and set the schedule and the account information under which you want to run the TfsBuild. At the last page ensure that the "Open advanced properties..." is checked before you hit finish...
In the dialog that opens enter the arguments in the Run text box so that it’s like...
"d:\Program Files\Microsoft Visual Studio 8\Common7\IDE\TfsBuild.exe" start <TfsServer> <Team Project> <Build Type name>
We can also do it by creating a batch file and running the batch file through a scheduler.
Let us now see the structure of the MSBuild script. It is a hierarchy of XML sections and tags.
The MSBuild Project File is an XML file that tells MSBuild what needs to be built, as well as how to build it. The file is divided into four main sections:
•        Items
•        Properties
•        Tasks
•        Targets
Items define what you want to compile. They are grouped into collections, which can then be used by Tasks. These collections are called ItemGroup. For example Listing 1 shows the collection which enumerates files to be included in the build.
<ItemGroup>  
       <FilesToCompile Include=”\sub\**\*.cs” />
       <FilesToCompile Include=”*util.cs” Exclude=”hiddenutil.cs”/>
       <FilesToCompile Include=”app.cs;foo.cs”/>
</ItemGroup>
Listing 1
Properties are scalar values that help configure the build. Properties are also grouped into PropertyGroup collections.
MSBuild defines some reserved properties and they are listed in the table below:
Table 1: Reserved properties
MSBuildProjectDirectory
Folder in which the project is stored
MSBuildProjectFile
Filename of the project file
MSBuildProjectExtension
File extension of the project file
MSBuildProjectFullPath
Full pathname of the project file
MSBuildProjectName
Name of the project file without extension
MSBuildProjectDefaultTargets
List of targets specified in project’s DefaultTargets attribute
MSBuildBinPath
Folder in which msbuild.exe is stored
 
 
Listing 2 shows the definition and use of the property in a PropertyGroup.
<PropertyGroup>
       <OutputDir>bin\debug</OutputDir>
       <OutputAssembly>
              $(OutputDir)\$(MSBuildProjectName).exe
       </OutputAssembly>
       <Optimize>false</Optimize>
</PropertyGroup>
Listing 2
In this listing, to create output path of the assembly, we are internally using a property defined earlier that is “OutputDir” as well as a standard property “MSBuildProjectName”. The way to use a property has a special syntax of $(Property Name).
Tasks are executable code that MSBuild uses to perform the build. Tasks are written in managed code, and can be shared and used across different projects. MSBuild ships with several tasks, and you can also create your own custom tasks.
A task is just a class that implements a particular interface (ITask) with task attributes corresponding to public properties on the task class. The file that maps these built-in tasks to the assemblies they are contained in is Microsoft.Common.Tasks in the .NET framework directory. An excerpt from this file is shown in Listing 3.
<Project xmlns=
       ”http://schemas.microsoft.com/developer/msbuild/2003”>
       ...
       <UsingTask TaskName=”Csc” AssemblyName=”Microsoft.Build.Tasks,
              Version=2.0.0.0,
              Culture=neutral,
       PublicKeyToken=b03f5f7f11d50a3a”/>
       ...
       <UsingTask TaskName=”MakeDir” AssemblyName=”Microsoft.Build.Tasks,
              Version=2.0.0.0,
              Culture=neutral,
       PublicKeyToken=b03f5f7f11d50a3a”/>
       ...
</Project>
Listing 3
Targets are used to group tasks together in a certain order and expose sections of the project file as entry points into the build process. Targets are somewhat similar to functions of programming languages. Similar to functions they are declared at one place and contain executable lines. They are called by the script as needed. As in the case of functions, one target can invoke other targets. It is possible to create a separate .target file to contain individual or grouped targets to improve reusability.
The following code example shows a Target element that executes the Csc task.
<Target Name="Compile" DependsOnTarget="Resources" >
    <Csc Sources="@(CSFile)"
          TargetType="library"
          Resources="@(CompiledResources)"
          EmitDebugInformation="$(includeDebugInformation)"
          References="@(Reference)"
          DebugType="$(debuggingType)" >
        <Output TaskParameter="OutputAssembly"
                  ItemName="FinalAssemblyName" />
    </Csc>
</Target>
 
The following example shows a project file that compiles a Visual C# application and logs a message containing the output file name.
<Project DefaultTargets = "Compile"
    xmlns="http://schemas.microsoft.com/developer/msbuild/2003" >
 
    <!-- Set the application name as a property -->
    <PropertyGroup>
        <appname>HelloWorldCS</appname>
    </PropertyGroup>
 
    <!-- Specify the inputs by type and file name -->
    <ItemGroup>
        <CSFile Include = "consolehwcs1.cs"/>
    </ItemGroup>
 
    <Target Name = "Compile">
        <!-- Run the Visual C# compilation using input files of type CSFile -->
        <CSC
            Sources = "@(CSFile)"
            OutputAssembly = "$(appname).exe">
            <!-- Set the OutputAssembly attribute of the CSC task
            to the name of the executable file that is created -->
            <Output
                TaskParameter = "OutputAssembly"
                ItemName = "EXEFile" />
        </CSC>
        <!-- Log the file name of the output file -->
        <Message Text="The output file is @(EXEFile)"/>
    </Target>
</Project>
In this example, we have defined a target named “Compile”. This target encapsulates a task “CSC” which is one of the built in tasks. It also uses another built in task named “Message”. These tasks in turn use a property named appname and an item named CSFile. The “Compile” target is called by msbuild as it is given as the default target of the project.
Conclusion
Team build is a GUI tools in VSTS to create a compiled version of the application. It uses msbuild technology to execute certain tasks in a specific order. Configuration of build is provided through a .proj file which is an XML file having certain schema. In this article we studied the team build wizard as well as the structure of the msbuild configuration file.
 I hope this article was useful and I thank you for viewing it. If you liked the article, please subscribe to my RSS feed over here.

This article has been editorially reviewed by Suprotim Agarwal.

Absolutely Awesome Book on C# and .NET

C# and .NET have been around for a very long time, but their constant growth means there’s always more to learn.

We at DotNetCurry are very excited to announce the The Absolutely Awesome Book on C# and .NET. This is a 500 pages concise technical eBook available in PDF, ePub (iPad), and Mobi (Kindle).

Organized around concepts, this eBook aims to provide a concise, yet solid foundation in C# and .NET, covering C# 6.0, C# 7.0 and .NET Core, with chapters on .NET Standard and the upcoming C# 8.0 too. Use these concepts to deepen your existing knowledge of C# and .NET, to have a solid grasp of the latest in C# and .NET OR to crack your next .NET Interview.

Click here to Explore the Table of Contents or Download Sample Chapters!

What Others Are Reading!
Was this article worth reading? Share it with fellow developers too. Thanks!
Share on LinkedIn
Share on Google+

Author
Subodh is a consultant and corporate trainer. He has overall 28+ years of experience. His specialization is Application Lifecycle Management and Team Foundation Server. He is Microsoft MVP – VS ALM, MCSD – ALM and MCT. He has conducted more than 300 corporate trainings and consulting assignments. He is also a Professional SCRUM Master. He guides teams to become Agile and implement SCRUM. Subodh is authorized by Microsoft to do ALM Assessments on behalf of Microsoft. Follow him on twitter @subodhsohoni


Page copy protected against web site content infringement 	by Copyscape




Feedback - Leave us some adulation, criticism and everything in between!
Comment posted by Terry Rooks on Thursday, May 1, 2008 2:47 PM
VSTS 2008 does have scheduling and continuous integration builds.   We use them here to run 24 builds.  Additinoally, we have on build that builds continuously based on code changes and is limited to not build more often than every 30 minutes.   Good article for those that are using VSTS2005
Comment posted by Subodh Sohoni on Friday, May 9, 2008 7:25 AM
Thanks Terry for your comments. I have written a small article on the same site for build in TFS 2008 (http://www.dotnetcurry.com/ShowArticle.aspx?ID=139). Your comments on that will be very valuable to me in view of your experience of the builds that you are running.

Categories

JOIN OUR COMMUNITY

POPULAR ARTICLES

C# .NET BOOK

C# Book for Building Concepts and Interviews

Tags

JQUERY COOKBOOK

jQuery CookBook