Connect to a Project in TFS Visual Studio

On the Team Explorer, Click on the icon highlighted in the screen-shot below and then click on Manage Connections. Select “Connect to a Project” from the Menu.

Manage Connections is also available under the Team menu in Visual Studio.

If your Team Foundation Server is not already added then click on the “Add TFS Server” link and you’ll need to enter the TFS URL and click on Add.

You may need to enter your credentials in the pop-up window. The list below shows the Test Project, select it and click on Connect.

Finally you can map the TFS Server path to your Workspace Project i.e. Physical folder on your machine as shown below:

Build Web Application with TFS

The msbuild capability of TFS 2015 or 2017 agent helps build a Web Application using MSBuild Arguments. The Visual Studio Build task is required to pass the msbuild arguments along with the path of the solution file to build.

Fill the msbuild arguments with:

/p:DeployOnBuild=true /p:PublishProfile=<PublishProfileName>

Make sure the Publish profile is checked-in. It is an xml file which is used to save the Publish settings for a Project which includes the Path to Publish and the Deployment mode which can be Debug/Release. This file is found under the Profiles folder of the Project. Also, make sure in your Build Publish Profile, the option Precompile during publishing is checked.


You can also use the following MSBuild arguments to Publish the Web Application build into the directory as specified in the publishUrl argument as below:

/p:DeployOnBuild=True /p:DeployDefaultTarget=WebPublish /p:WebPublishMethod=FileSystem /p:DeleteExistingFiles=True /p:publishUrl=$(build.artifactstagingdirectory)\Deployment\$(BuildConfiguration)

The artifactstagingdirectory is the “a” folder on the Agent for the Project Collection Id under which the Project is built. This is where the files are copied after the Project is built from the Source “s” folder.

BuildConfiguration variable under the General Tab contains Debug/Release.

e.g. C:\TFSAgent\agent\_work\<Id>\a\bin\Deployment\Release\

If the MSBuild arguments are not specified, the artifacts folder will not contain only the code files and not the build files. Save the Build definition and queue the build to view the results.

I’ve written another post on Creating Build Definition here. Another way that might work for you is a post about Publishing WebAPI or MVC application here.

Change Password for TFS Build Service Account

The TFS Agent for 2015 or 2017 versions is a Windows Server machine that hosts the Service that allows to run Build and Release definitions for your code as part of the DevOps Process. It can run as a Windows Service and can be found by the name VSO Agent in the Services Snap-in. It uses a domain account to run the Windows Service which can be seen under the LogOn properties of the Service.

It runs VSOAgent.exe behind the scenes which is kept in the Agent folder configured for that TFS Agent e.g.


If at any point you require to change the Windows Service account details that was configured earlier due to may be a password change, the following command may help you.

Please note that Password should not be changed from the Services Snap-in as it may cause the Agent Service to break.

  1. Open Command Prompt in Administrator mode.
  2. CD to the directory e.g. as mentioned above C:\TFSAgent\agent\ . Make sure you’re one level above the folder where the VSOAgent.exe is placed else it’ll give error.
  3. Run the following command: .\Agent\VSOAgent.exe /ChangePassword
  4. Fill in the new Credentials as Prompted.
  5. Restart the Service VSO Agent from the Services Snap-in.

The Agent should now be running with the new Service account.

Release Management with TFS

Release Management is a service in VSTS Azure pipelines and TFS on-premise and an essential element of DevOps that helps you continuously deliver software. We can fully automate the testing and delivery of your software in multiple environments all the way to production, or set up semi-automated processes with approvals and on-demand deployments.

CI Build

Release definition defines the end-to-end release process for an application to be deployed across various environments.

You define the release process using environments, and restrict deployments into or out of an environment using approvals. You define the automation in each environment using phases and tasks. You use variables to generalize your automation and triggers to control when the deployments should be kicked off automatically.

You can create a deployment model on the basis of how you manually deliver the builds using build definition for different environments.

The below Release Definition shows different steps using PowerShell scripts that are modeled basis the manual process created for deployment.

Release definition


Creating a Release definition

Configure your environment:

  • Give the environment a meaningful name by clicking into the Default Environment name provided and enter one of your own e.g. DEV, QA, PRODUCTION.
  • Click on the ellipsis next to the environment name and select Deployment conditions…



Deployment Conditions


This is where we set up how we want our deployment to be triggered. It is here that we define what triggers the deployment of our release.

  • No automated deployment– deployment of the build artifacts will need to be undertaken manually with no automation
  • After release creation– this will deploy the build artifacts to the specified environment every time a new release is created i.e. Continuous Delivery.
  • After successful deployment on another environment– this will deploy the build artefacts to an environment after they have been deployed to another environment e.g. after every successful deployment to the STAGING environment deploy the build artefacts immediately to the QA environment

Use the first option if you are deploying to a production environment i.e. make the deployments to your production environment a manual exercise. Use the second option if you are deploying to a development testing environment as part of a Continuous Delivery pipeline. Use the last option if you want to push your deployments between different testing environments.


You may setup Approvals before the deployment to a particular environment using the Approvals Tab.



Configure a Queue and set demands

The demands may be System defined like “DotNetFramework” or you can set yourself like selecting Agent name.



General Tab



After configuring your environment, the next step would be to add task(s) which will be invoked when we want to deploy our build artifacts to the specified environment. The deployment task is the action that we want to happen when we invoke a deployment e.g. running a PowerShell script to start/stop App Pool, running database scripts, deploy the build on to a Virtual Machine or Azure instance.

Create Release

Create Release and select the build for which you would like to create a release in Dev environment and click on Create as shown below:


The successful build selected above will trigger the Automated Deployments based on the selections made for each environment.

Create build definition with TFS 2015 or newer

What is build definition?

A build definition is a representation of the automation process that you want to run to build and test your application. The automation process is defined as a collection of tasks. VSTS and TFS have a number of tasks to build and test your application. A build definition describes the details of what your build is supposed to do, and when it’s supposed to do it.

Build and Release are two of the DevOps services in VSTS and TFS that help you manage continuous integration and delivery of your applications.

Visual Studio Team Services (VSTS) and Team Foundation Server (TFS) provide a highly customizable continuous integration (CI) process to automatically build your Web, Mobile or Desktop application whenever your team pushes or checks in code. You can also Schedule builds on a specific date or time, recurring builds or manually queue a build.

You can add build tasks for .Net, Java, Node, Android, C++, xcode applications. Similarly, there are tasks to run tests using a number of testing frameworks and services. You can also run command line, PowerShell or shell scripts in your automation pipeline.

A basic build definition consists of 3 steps or build tasks which can be used with the Visual Studio template (this template requires Visual Studio be installed on the build agent):

  1. Visual Studio Build: This step builds the solution in the $(build.sourcesdirectory). This is the Source directory with the letter “s” under the Agent’s work folder. TFS gets all the files under this directory and builds the application under the bin folder. Provide the path to the solution that requires to be built. In case you need to build a web application, fill the msbuild arguments with: /p:DeployOnBuild=true /p:PublishProfile=<name of Publish profile>. Make sure the Publish profile is checked-in.BuildStep1
  2. Copy Files: This step copies the files from the source directory described above to the Artifacts Staging directory $(build.artifactstagindirectory) with the letter “a” under the Agent’s work folder. The Files Published for the Web Application can be found under bin\$(BuildConfiguration)\Publish folder.BuildStep3
  3. Publish Build Artifacts: This step Publishes the artifacts in step 2 to the Shared folder for which Network share path requires to be provided. Appropriate permissions are required on the folder to the same user that is running the Build Agent Service on the Agent machine. You can Publish the files copied in step 2 from the Publish folder above to the Network share path for continuous delivery pipeline. BuildStep4
Repository Tab

This tab lets you specify the Mappings under the Source “s” folder on the Agent machine as to how it should manage the downloaded source files locally. You can map each Server paths with a local path e.g. one Server path may be mapped to Application files and other Server path may contain PowerShell scripts which may need to be run in a different build task.

General Tab

This tab specifies some of the required demands that are defined as capabilities on the Agent machine like:

  • msbuild
  • visualstudio
  • vstest etc.

You can specify additional demands like choosing a specific agent by adding a demand as “Agent.Name”.

The Build Number format specifies the name of the folder under which queued build will be placed.

Variables Tab

This tab holds some predefined system variables and link to the entire list of it. You can also add your own variables which can be used in the build definition.

Triggers Tab

Specify whether to schedule the build, build with each check-in or with gated check-ins.

Retention Tab

Lets you specify the duration until which you’d like to keep the queued build.

History Tab

Shows the log of any changes made to the Build definition by which users and when.

Configure TFS 2015 Agent

What is TFS Agent?

An Agent is an installable software that runs one build or deployment job at a time.  At least one Agent is required to build or deploy your code. More agents are required as people and code grows.

Agent types:

There are two types of Agent:

  • Microsoft-hosted agents: These are run in Azure pipelines on Microsoft virtual machines which are discarded after one use.
  • Self-hosted agents: These can run in Azure pipelines or TFS on-premise.

Agents can be installed on Windows, Linux or MacOS machines. Linux Docker containers can also be used.

Agent pools:

These are used to organise agents based on Project collections and Projects, so that agents don’t have to be managed individually.

  • An OS that supports VS 2013 or higher
  • VS 2013 or 2015 (For information on issues faced with VS latest versions. Check this article)
  • PowerShell 3 or higher

This tells us what the agent can do. Capabilities are name-value pairs that are either automatically discovered by the agent software, in which case they are called system capabilities, or those that you define, in which case they are called user capabilities. While queueing a build these can be set as demands in the General tab to identify suitable agents.

These capabilities are recognised by the registry information which can be found under HKLM on Windows machines.

Some of the generally required capabilities are:

  • msbuild
  • visualstudio
  • vstest
  • Microsoft SDKs
  • PowerShell

Additional software can be installed on an Agent as required by the code to be built e.g. a software that packages your code after build in an MSI and can be invoked by a build task in your build definition through batch file or PowerShell command.

Additional Tip:

Restart the Agent service after installing additional software for the capability to show up.

Download and configure the Agent:

  1. Login as Agent Pool Administrator.
  2. Navigate to the Agent Pool tab: http://{your_server}:8080/tfs/_admin/_AgentPool
  3. Click on Download Agent. Unzip the package under C:\Agent.
  4. Run “ConfigureAgent.cmd” as administrator and respond to the prompts.
  5. Stick to the defaults initially to install the agent in the Default pool if you’re not really familiar with the environment.
  6. Install the Agent as a service. Make sure the Agent is running under Services.msc with the provided domain credentials. The credentials should have required permissions e.g. on the Drop folder where the code will be Published using the Build definition.
  7. The C:\Agent\Agent\VsoAgent.exe is found under Services snap-in as VSO Agent.

If you need to change the credentials later the following command can be used:

C:\Agent\Agent\VsoAgent.exe /ChangeWindowsServiceAccount

The TFS on-premise agent cannot be upgraded unless the TFS version is upgraded. The Agent version which is used which is shipped along with TFS.

The list of configured Agents can be found under:



Unconfigure Agent:

Start cmd as Administrator.

Go to the Agent folder C:\Agent\Agent and Run the command –

.\agent\vsoagent.exe /unconfigure


Comments are welcome for improvements!

Setup Unit Testing with TFS 2015

Create unit test project in solution

To get started with Unit Testing your Project along with the DevOps Process, we need to add Unit Test Project in your solution. E.g. if we have a web application, add the Unit Test Project the following way:

  1.  Right-click solution
  2. Add New Project
  3. Select Unit Test Project as shown below

Any Unit Testing framework like MSTest or NUnit can be used to create unit test cases.


Add Unit Test Cases

Following the convention of adding Unit test cases, add a class with same name of the class whose functionality requires to be unit tested with “Test” as suffix in the name.

Below is an example of dummy test-cases. The class name can be changed accordingly.

E.g. for a class named “Upload.cs”, add a unit test class named “UploadTest.cs”.


The test cases can be tested by:

  1. Right-click inside a method to run that single test case.
  2. Right-click inside the class outside all methods to run all test cases.
  3. View the results in the test explorer.


We have AAA pattern to write Unit Test cases:

  1. Arrange all the necessary preconditions and inputs.
  2. Act on the object or method under test.
  3. Assert that the expected results have occurred.


Build definition with test step

Create a build definition with the following tasks for your environment.

e.g. To test your Dev environment build add the following build tasks. Please note the configuration may change as per requirements:

  1. Visual Studio Build to build the solutionBuildStep1
  2. Visual Studio Test to run the test casesBuildStep2
  3. Copy Files from Source directory to artifacts staging directoryBuildStep3
  4. Publish Build artifacts from artifacts staging directory to deployment folder / shared location. Only the selected files from the Publish folder are copied to the shared path in this case.BuildStep4

Agent capabilities for unit testing

The General tab in the build definition shows the Demands for the build steps that we’ve added. The same capabilities should exist on the agent that’ll be used to build and run the test steps.


  1. Msbuild is used to build the project.
  2. Visualstudio is for other tools that might be required during the build.
  3. vstest is used to run test cases.

Agent.Name is a manually added demand that searches for the Agent by name.


As per the above screen-shot, the build definition is looking for agent by name “Agent-xxxxx”. This Agent has Visual Studio 2013 installed and some of the capabilities which are automatically discovered.

If any of the Unit Test cases fail during the Build, the build will fail and the remaining steps will not be executed.

Issues faced

Visual Studio 2017 is not supported with TFS 2015 Update 4:

The format of Visual Studio folders under Program Files (x86) and registry settings have changed from Visual Studio 2017 onwards and are automatically discovered as capabilities on the Agent by TFS 2015. Even manually adding such capabilities is not recognized by the TFS Server Build.

Hence, selecting Latest Visual Studio in the drop-down for the Build tasks Visual Studio Build and Visual Studio Test does not work and gives the following errors:

  1. Visual Studio Build:

Visual studio version… not found. 

2. Visual Studio Test:

Unable to determine the location of vstest.console.exe 

To solve these issues:

  1. Use the supported Visual Studio versions 2013 or 2015 on the Build Agents for which the capabilities are automatically discovered while configuring the Agent.
  2. TFS may need to be upgraded to 2017 version.


Note: Using a custom build task vstestv2 might work in this scenario using npm install, if the agent version can be upgraded. Current Agent version shipped with the on premise TFS 2015 does not support uploading the custom build task to support the latest test framework. On premise Agent version cannot be upgraded unless TFS is upgraded.

Comments are welcome for improvement!