Skip to content

Posts from the ‘TFS’ Category


Git for Visual Studio Developers–Get your .gitignore right and save yourself needless merges

One of the most common issues I am finding with teams moving from Team Foundation Version Control to TFS-Git is that they are including files in their repositories that they shouldn’t. The most common offenders are .suo user settings files, Nuget packages and Azure publish settings.   Luckily, the solution is straightforward.  

1. Ensure you have no pending changes.

2. Close the solution

3. Go into Team Explorer and click Settings image  


4. In the Settings tab select Git Settings image  


5. Open the .gitignore file from GitHub that is specific to Visual Studio projects and copy the contents to the clip board. image
Figure: the .gitignore includes a list of all of the files that you want to avoid committing to your repository 


4. In Settings | Repository Settings, click the Edit link next to ‘/,gitIgnore’ image  



6. Paste the contents of the .gitIngore from GitHub into the .gitignore file and Save it. image  


7, In Team Explorer, navigate to the Changes window. Enter a comment and click Commit. image  


8. Click the Sync link to take you to Unsynched Commits image  


9. Click the Sync button to push your updated .gitIgnore image  


10. If you have included files in your repository that you wish to exclude from the repository but not delete from your local working directory refer to

Remove files from your repository (so that they aren’t tracked), but leave them in the working directory

on my page for

Git: Essential Commands for Visual Studio Developers


60 Second Demo – Configure a CI Build + Setup Build Notifications

Configure Your Build

1. Open the Build Pane


Figure: From Team Explorer choose Builds


2. Create a new build definition


Figure: Click on the New Build Definition link


3. Enter build definition name “AdamS.MembershipSample.CI”
(CI for Continuous Integration)

4. On the Trigger tab choose ‘Continuous Integration’


5. On the Source Settings tab remove any unwanted Source Control folders

Figure: Remove any items that do not apply to your project (sometimes items from other solutions will appear in this list – remove them)


6. On the Process tab, ensure that the solution is being built


7. Save the Build

Configure Build Notifications

1. Run the Visual Studio Build Notification application.

From C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\BuildNotificationApp.exe


2. Select the build


Figure: Select the Build that you just created and click OK

Start a Build

Figure: Go to Team Explorer | Builds. Right click on the Build and choose Queue New Build



Figure: When the build is complete, you will get a green or red icon indicating the status.


TFS-Git: My 60 second tutorial

I got asked for a 60 second intro to using TFS-Git.

1. Go to your personal TFS (e.g.


2. Create a new Team Project


Figure: Click on New under Recent projects  & teams

Figure: Enter the name of the Team Project (E.g. FireBootCamp)
Select Git as the version control system.
Select Create project


3. Clone your Repository locally

Figure: In Visual Studio, open Team Explorer and click Select Team Projects

Figure: Select the team foundation server to connect to, select the team project and then click Connect

Figure: Right click on the Repository and select Clone

Figure: Enter the path to the local repository and click the Clone button


4. Add your MVC project to the Repo

Figure: Create the MVC Project

Figure: Right click on the Solution file and click Commit

Figure: Enter a comment and click Commit and Sync


Adding a Testing Column to Your TFS 2012 Task Board

The default Agile TFS template ships with three states: New, Active and Closed.

A common question that I am asked is how to add an extra stage to the TFS taskboard.

While this is not trivial in TFS 2012, it’s really not that hard once you know how, and is being made easier in newer versions of TFS.


Figure: We will demonstrate adding a ‘Testing’ column.

Step 1: Ensure that you are an administrator of the Team Project you are updating

Step 2: Download the Team Foundation Server 2012 Power Tools

– In Visual Studio select Tools, and then Extensions and Updates


Figure: Select Online from the left menu, enter Team Foundation 2012 in the search field, click the Download button on Microsoft Visual Studio Team Foundation Server 2012 Power Tools

Step 3: Export the Task Work Item Type

To add a new column to the task board, we need to add that status to the work item type definition.


Figure: From the Tools menu select, Process Editor, then Work Item Types and then Open WIT from Server


Figure: Expand the correct Team Project and select the Task work item type.

Step 4: Add the Testing state to the Task WIT


Figure: Select the Workflow tab. Open the toolbox and drag a State component onto the design surface. Right click on the new State, select Properties and set the Name property to Testing


Figure: Select the Transition Link component from the toolbox. Now click on the Active state and drag your mouse to the Testing state.


Figure: A transition will have been added from Active to Testing.


Figure: Right click on the Transition and choose Open Details. Go to the Reasons tab and Edit the reason value. Suggested test: ‘Ready for Testing’. You can click on the chevrons to expand the transition to be able to more clearly see the assigned properties.

Additional actions and Fields can also be specified but that is beyond the scope of this post.


Figure: Repeat the process above to add transitions from Testing to Complete (with a reason of ‘Testing Complete’) and from Testing back to Active (with a reason of ‘Failed Testing’).


Figure: Save the template to a known location on your hard drive so that it can be imported in the next step. E.g. c:\Temp\TeamProjectName_Task.wit

Step 5: Import the saved WIT


Figure: From the Tools menu select Process Editor, then Work Item Types and then Import WIT.


Figure: Browse to the location of the saved file, select the Team Project you wish to import the WIT into and click OK.


Figure: When you edit a task, the Testing status is now available. It is not yet however added to the board.

Step 6: Export the Process Template Config

This is the part that I always forget to do. After you have edited the Work Item Type, you still need to update the process template to include the State on the Task Board.


Figure: Open a command prompt, change to the Visual Studio IDE Folder and execute the following command

witadmin exportcommonprocessconfig /collection:CollectionURL /p:ProjectName /f:”DirectoryPath\CommonConfiguration.xml”
for our instance the command required was
witadmin exportcommonprocessconfig /collection:http://ourserver:8080/tfs/CollectionName /p:ProjectSparrow /f:”c:\Temp\CommonConfiguration.xml”

Step 7: Edit the Process Template Config


Figure: Edit the exported file. Find the section for TaskWorkItems and add the line highlighted above.
<State type=”InProgress” value=”Testing” />
Save the file.

Step 8: Import the Process Template Config


Figure: Execute the following command

witadmin importcommonprocessconfig /collection:CollectionURL /p:ProjectName /f:”DirectoryPath\CommonConfiguration.xml”
for our instance the command required was
witadmin importcommonprocessconfig /collection:http://ourserver:8080/tfs/CollectionName /p:ProjectSparrow /f:”c:\Temp\CommonConfiguration.xml”



Figure: View your task board and you will have your new column!


Create a WebDeploy Package on Team Foundation Service

I love continuous deployment to Windows Azure from Team Foundation Service!

Often though we need the flexibility of building and working directly with the WebDeploy package.

2013 02 11 a
Figure: To create the package, edit the build process template and add “/p:DeployOnBuild=true” to the MSBuild Arguments to have a deployment package created (as you would with on-premise TFS).

2013 02 11 b
Figure: The package is now available in the Drops folder under source control.

2013 02 11 c
Figure: Once you have the package it can be imported directly into IIS (providing Web Deploy 3.0 is installed).


Gated Checkins Mask Dysfunction

I had a conversation today with a lead developer who was working with a team who couldn’t get the hang of not checking in bad code. To resolve the issue, he implemented Gated Checkins. He asked me to check out some the code and I was happy to, right up until I had to do a few checkins. The following are my subsequent thoughts on the matter.

Gated checkins are used to stop developers from checking in bad code and breaking the build.
This does not contribute to high functioning teams, and instead masks, or even creates dysfunction.

To illustrate lets look at a couple of examples.

In the retro the team decides to turn gated checkins on because Jonny and Sue keep breaking the build.
The build doesn’t get broken any more, because Jonny and Sue now have to fix their code before they check it in.
This doesn’t mean that Jonny and Sue are writing better code, it just means that they are not checking in code that breaks the build.
Gated checkins will not improve their skill level, change their attitude or improve the quality of their code.
The development ninjas on the team are proud of their code, and check in several times per day.
Because the gated checkin takes 10 minutes their workflow is impacted.
They resent Jonny and Sue for having to work this way.
Gated Checkins mask the dysfunction on the team, and introduce impediments to the high performers.
Example – Gated Checkins mask dysfunction

In the retro the team discusses the fact that the build is often broken.
After a round table discussion about becoming better programmers and building better quality software, the team decides to the following guidelines:
1. The team will all run build notifications so that everyone knows when, and by whom the build is broken.
2. If someone needs help with solving a problem, they are going to feel good about asking for help early, and learning something new in the answer.
3. If someone is asked for help, they will gladly share their knowledge to ensure that the quality of the project is maintained ,and the team help each other to become better developers.
4. Before checking in, the devs will compile and run all tests. **
5. If someone checks in and does break the build, they will call out to all members of the team that the build is broken so that no-one gets latest. They will fix the build IMMEDIATELY, and then call out again when it is fixed.
(Some teams have a rule that if you break the build three times you have to shout coffee / lunch).
6. The team agrees that you don’t go home if the build isn’t green.
If it comes to the end of the day and you are not sure your code will not break the build – do not checkin. Create a shelveset and resolve the issue properly the next day.
If you have checked in, the build is broken, and you cannot fix it before going home, you must email all devs on the team, and the product owner with an explanation.
7. The status of the build is reviewed in every daily scrum. Edit: Gerard correctly pointed out that this is bad Scrum.
Example – The whole team should be constantly aware and invested in the status of the build, the quality of the software and in encouraging each other to better developers.

** I actually don’t follow this rule when working on small teams of awesome devs, who write code against tests and checkin frequently.

Instead I encourage the process to be
– checkin 4-5 times a day
– write lots of tests
– if the tests that you are working against pass- checkin and let the build server do a full compile and run all the tests
– if you have broken the build, call it out, fix it immediately and then call it out again.
This is the most productive way for small teams of awesome developers to produce great code… and it’s fun !