Click here to Skip to main content
13,258,055 members (75,596 online)
Click here to Skip to main content
Add your own
alternative version

Tagged as


4 bookmarked
Posted 9 Nov 2013

Team Foundation Server Best Practices (1 of 3)

, 9 Nov 2013
Rate this:
Please Sign up or sign in to vote.
Some best practices to help some minor learning curves and also a refresher for those of us that have been using it for years.

TFS Best Practices Articles

  1. What should be checked in
  2. The right way to check in
  3. Things to watch out for 


Recently, I have been on a few projects with developers that were not as experienced in using Visual Studio with Microsoft’s Team Foundation Server, so I thought it was prudent to put together some best practices to help them over some minor learning curves and also as a refresher for those of us that have been using it for years.

What Should Be Checked In?

This may seem obvious but there are some things that you may not think of checking in that you should:

Solution/Project Files

Your *.sln and *.csproj (and others) contain the list of every file that is in your solution/project. If you just check in a folder of files on your screen, it may look fine but when someone else goes to get your code, they won’t see these files.

Nuget Packages

If you are not familiar with NuGet packages, it’s well worth your time to look it up. This was more of an issue with previous versions of Visual Studio but since they are not visible in the solution explorer and contain binary files (*.dlls), inexperienced developers may ignore them not realizing that these should be checked in.


Most projects that I deal with have some sort of scripts associated with them. Things like scripting the setup of a new local environment (for new developers or getting a clean slate for existing ones) or deployment scripts (for upgrading an existing database schema to work with the latest version of your code).

  • PowerShell
  • Batch Files
  • SQL
  • etc.


Even though I like to keep documentation in a CMS like SharePoint, it’s also very helpful to check it in with the rest of your code. I most often do this when merging code into another branch because it’s nice to keep the doc that goes with a particular version tied to it in source control.

  • Deployment Instructions
  • Technical Specifications

There are plenty of other things to make sure you have checked in but these are the big ones that I often see missed by old and new developers alike.

Look for the next part in this series “The Right Way to Check In”.


This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


About the Author

JJ Bussert
United States United States
No Biography provided

You may also be interested in...


Comments and Discussions

SuggestionTeam Foundation Server Best Practices (full article) Pin
rhythmdivine2-Mar-15 0:07
memberrhythmdivine2-Mar-15 0:07 
GeneralMy vote of 3 Pin
Kannan Karthikeyan28-Mar-14 5:20
memberKannan Karthikeyan28-Mar-14 5:20 
GeneralManaging Documentation Pin
Klaus Luedenscheidt9-Nov-13 18:24
memberKlaus Luedenscheidt9-Nov-13 18:24 
As the TFS provides a Sharepoint server by default i prefer to use the project sharepoint portal i can create while setting up a team project to manage the documentation of my projects. It's always better than using the source code repository because the rrepository is optimized to manage source files and not binary files. For the same reason you should avoid to check in binaries. Nuget p0ackages or static binaries as third party dll's which doesn't change often are exceptions.


General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

Permalink | Advertise | Privacy | Terms of Use | Mobile
Web04 | 2.8.171114.1 | Last Updated 9 Nov 2013
Article Copyright 2013 by JJ Bussert
Everything else Copyright © CodeProject, 1999-2017
Layout: fixed | fluid