TFS Tutorial: TFS for Automating Build, Test, and Deployment for .NET Projects

Using Microsoft TFS 2015 Update-3 for .NET (Build, Test and Deploy): TFS Tutorial

TFS is more widely used for .NET development using Visual Studio .NET IDE. With TFS 2015 Update 3, one can connect to any Team Foundation Server Git repo, using an SSH key.

Team Foundation Server (TFS) is an ALM product from Microsoft which provides the capabilities for an end-to-end development and testing using Work Item Management, Project Planning (Waterfall or Scrum), Version Control, Build/Release (Deploy) and Testing capabilities.

NOTE: This TFS tutorial has many images so allow it to load properly. 

Also read => TFS for JAVA Projects with Eclipse in DevOps

Using Microsoft TFS 2015 Update 3 for .NET (Build, Test and Deploy)


TFS is tailored for Microsoft Visual Studio and Eclipse on all platforms, however, it can also be used as a back-end to several IDEs (Integrated Development Environments).

We will now take a look at how Team Foundation Server (TFS) will be used to Build, Test and Deploy .NET Web Applications which is traditionally the strength of the tool.


Typically to perform the steps mentioned in the tutorial you will need a Build Server, where Builds will be performed, and Deployment machines or environments where, applications will be deployed to IIS, with agents installed and running. Please refer to my earlier tutorial to know how to install agents.

Setup a C# Application

Assuming TASK work items are created in TFS and is assigned to developer’s to work on the same. I have always noticed that Traceability is very important from the point of view of tracking any work across the software lifecycle.

Before adding a .NET application to TFS source control repository, ensure whether a Collection and Team Project exists or not.

A Collection is created by the TFS Administrator. It consists of a group of Team Projects in any service organization, where projects for multiple customers are being executed. You can create individual collections for each customer projects in TFS.

Once a collection is created you can create multiple team projects within it. A single team project consists of all work items, source code, test artifacts, metrics for reports etc., Team project can be created using various inbuilt process templates like Scrum, Agile, CMMI etc.

Team Project

Team Project 1


Team foundation control

team project setting



Launch TFS Web interface using the URL http://<ServerName>:port/tfs and you can see the project created.


Click on the project and you will get on to the Team Dashboard

(Note: Click on any image for enlarged view)

Team Dashboard

Now we have a collection and a team project created. Let’s launch Visual Studio.NET and create a new C# Web application and share the project to TFS source control repository. This is the first step towards establishing Continuous Integration (CI) practice.

1) Launch Visual Studio.NET and set TFS as the default source control repository. Go to Tools => Options => Source Control. Then click OK.

Source Control

2) Go to View => Team Explorer and connect to TFS server using the iconicon

Team Explorer

3) Create a C# ASP.NET Web project

Web project

Web Application

4) Since we are creating a web application, Select the Web Forms template

Web Forms template

Click OK to create the project.

5) The project created can be viewed in Solution Explorer. .NET uses the concept of .sln file or solution to contain all the projects. Once you open the solution all the associated projects will also open. We need to add the solution to the TFS source control repository

The project

6) Modify the file Default.aspx as shown, Save it and then add the whole solution to the TFS source control repository

Modify the file Default

Select the Design view and you will be able to see the entire page

Design view

7) Add the solution to TFS source control. Right click on the solution and select ‘Add solution to Source Control’

Add solution to Source Control

8) Select the Team Project created earlier and then click OK

Select the Team Project

9) The solution is not yet checked-in to the TFS. In the Team Explorer click on the source control explorer and you can see the solution added to be checked in.

source control explorer

10) Check-in changes. Go to Team Explorer => Pending Changes

Enter a comment and drag-drop a TASK work item to ensure traceability. Click on the Check-in button.

Check-in button

check-in Confirmation

successfully check in

11) To test the website running locally, Click on the Firefox icon in Visual Studio.NET. Remember it is not yet deployed to IIS on any particular environment.

click on the Firefox icon

welcome to MS world

Creating Build Definition with Code Analysis

A build definition consists of a series of Tasks which is executed during an automated build process. Examples of the tasks can consist of running a Visual Studio Build, MS Build, executing PowerShell or Shell scripts etc.

1) To create a Build Definition, login to TFS web interface and go to the Builds TAB. Click on + to create a build definition. Start with EMPTY definition and then click Next.

create a Build Definition

Select the Team Project and click on Create

Team Project and click on Create

Click on Edit, which is found next to the Empty definition

Click on Edit

Save the build definition as something like ‘Main Build’

Save the build definition

Since Sonarqube will be used for Code analysis, hence add the 2 Sonar steps ‘SonarQube Scanner for MSBuild – Begin Analysis’ and the ‘SonarQube Scanner for MSBuild – End Analysis’ tasks.

Add the Begin Analysis step before any MS Build or Visual Studio Build. This step fetches details from Sonarqube server to configure the analysis.

Add End Analysis step later on.

Add End Analysis

The steps added will look like the following with MS Build step in between.

Start to define the details of Sonarqube server. Define Endpoint where the Sonarqube server and authentication details are added. Click on ‘Manage’ to add the Sonarqube server details.

Click on ‘New Service Endpoint => Generic’

New Service Endpoint

Add new generic connection

Now go back to the main Build Definition screen and select the endpoint which was just created.

Completed configuration for Begin analysis, looks as shown below

Completed configuration

Select the solution. In the Advanced => Additional Settings enter the following and save the Build Definition

/d:sonar.scm.enabled=true /d:sonar.scm.provider=tfvc /d:sonar.tfvc.username=niranjan /d:sonar.tfvc.password.secured=<password>

Additional Settings

SonarQube – End Analysis. Finish the analysis and then upload the results to the SonarQube project.


Add a step to Publish Artifacts to the server. The artifacts will be stored in a drop folder in the server and will be used during deployment.

Publish Artifacts

2) Install the agent on the Build and Deployment machine. You can refer to my previous tutorial to know how to install the agent. Now assuming that the agent is installed, ensure whether the agent is running or not.

Install the agent

3) Ensure the SonarQube SCM TFVC plugin is downloaded from here. and copied to the SonarQube installation\extensions\plugins directory. This plugin ensures that the source code is taken from the TFS source control repository and is made available to SonarQube for code analysis.


4) After the plugin is downloaded and copied, Launch the sonar server

launch the sonar server

5) Initiate a Build to check if the steps work fine. Open the Build Definition and click on ‘Queue Build’

Queue Build

Build Successful. All the steps ran fine.

Build Successful

Click on the Build number, in this case, it is Build 217 and go to Artifacts tab to look at the drop folder created at the server level.

build1 217

Note: In the next section the release process shows how any of changes can be reflected throughout the deployment process. For this ensure that the project artifacts are copied through the COPY step in the build definition after compilation step or manually copy the project artifact directory to the C:\inetpub\wwwroot directory. This has to be done only once.

wwwroot directory

Creating Release for Deployment

In the previous section, we saw about Build, followed by code analysis using SonarQube. We will now create a Release to deploy the artifacts from the ‘drop’ folder to IIS.

With the creation of Release, the entire Continuous Integration and Continuous Delivery is automated without any manual intervention.

Go to Release hub and Create a Release Definition.

Release hub

Start with Empty definition and click OK.

Empty definition

Save the Release definition and rename the Default Environment to QA. Based on the projects, additional environments like Staging Pre-Prod etc. can also be added and deployment would be automated to the entire environments one after the other.

Save the Release definition

Link the Build definition to Release definition so as the deployment is automated. Click on ‘Link to a build definition’. Select the build definition created earlier.

Link to a build definition

Click on Link

Enable the Deployment Condition to initiate the deployment immediately after Release creation

Deployment Condition

Deployment Conditions

Also, enable the Trigger for deployment after the build is successful. In the Release definition, go to the Trigger tab and enable ‘Continuous Deployment’, select the build definition.

Later Save the Release Definition.

Release Definition

Back in Environments tab of the release definition add the tasks to deploy the artifacts to the IIS server.

Add a task to copy files from ‘drop’ folder created during the build process to IIS wwwrootdirectory.

copy files

copy files1

Source folder – Browse and select the Webapplication1 project in the drop folder


Target folder should be the inetpub\wwwroot directory – C:\inetpub\wwwroot\WebApplication1

Executing Release for Deployment

In the release hub, create a release to start the deployment

create a release

Select the last stable build and Click on Create to Start the Deployment.

create to start the deployment

Deployment is successful to QA environment

qa environment1

Run inetmgr which is the IIS manager, where you can manage all the web sites/applications installed to IIS. Browse to the web application deployed.


MS world

To conclude once you initiate the Build, the deployment will also get completed to all the environments defined, as the Release is linked to the build definition.


In this TFS tutorial, we have now seen how Microsoft ALM platform can be used for automating Build, Test, and Deployment for .NET applications. TFS plays a major role here.

Hence in today's world, AUTOMATION is the key for successful and faster delivery to stay ahead.

Recommended Reading

4 thoughts on “TFS Tutorial: TFS for Automating Build, Test, and Deployment for .NET Projects”

  1. I am beginner to .Net Framework. I am obliged for this informative post, I have got many new points and has cleared my doubts. It also helped me understand this topic in more detailed way.

  2. Under the section: Setup A C# Application
    I get a 404 page for the link: “More on creating collections can be found @ Manage team project collections in Team Foundation Server”

    In Creating Build Definition With Code Analysis
    Your reference: “2) Install the agent on the Build and Deployment machine. You can refer to my previous tutorial…”
    A link would be good there, I cannot immediately find that tutorial.

  3. How to Use TFS build automation for other than .NET applications Ie Java, Python etc..and also how do we integrate TFS deploying build in Azure instance?


Leave a Comment