Add files to the server

Adding a file to version control is often automatic when you use Solution Explorer and your project is under version control. However, in some cases, you have to take some extra steps to add the project to version control.

You can simultaneously create a new team project and add it to version control so that you and your team can immediately enjoy all the benefits of version control beginning from the first line of code you write.

In Solution Explorer, select the solution, open its context menu, and then choose Check In.

In Team Explorer, the Pending Changes page appears.

Are there any Detected changes shown in the Excluded Changes section?

No: Skip to the next step.

Yes: Choose the Detected changes link. The Promote Candidate Changes dialog box appears. The files in listed in this dialog box are not referenced by any code projects in your solution. If your team will need these files, make sure they are selected and then choose Promote to move them into the Included Changes section of the Pending Changes page. For more information, see Check in your work to the team's codebase.

Many teams develop code that depends on binaries that are not built by the solution in which they manage their code. Typically these binaries are part of a library that the team has licensed from a third party.

Sometimes these binaries come from another team in the same company. For example, Team A depends on binaries produced by Team B, and each team must for some reason work in different team project collections. As a result, Team B delivers binaries to Team A, which then checks them into version control.

Tip

If your dev machines and build servers can access the Internet, then NuGet may make it easier for your team to manage your dependencies and keep your binaries up to date. Even if you decide to use NuGet, you should probably still add the binaries to version control so that you can reproduce and build historical versions of your code.

The folder and workspace structure you should use to store your third-party binaries depends on the way your solutions depend on these libraries.

If you place your third-party binaries in the same parent folder that contains your solution folders, then all your code projects in all solutions can reference the libraries with the same relative path.

For example, a team uses this folder structure:

Every code project can then reference the libraries folder with the following relative path: ../../Lib

If, later in your project, your team needs to isolate separate efforts that require different versions of the binaries, you can branch the library folder along with your solution folder.

For example, Version 1 an app leverages Version 1 of a library. As some developers on the Data Access team work on the next version, they leverage Version 2. But the other teams are not yet ready to upgrade. You can use branches to manage this kind of situation.

Some companies must manage more complicated dependencies on third-party libraries. For example, multiple team projects contain solutions with different dependencies on a common set of libraries. In cases like this, you can store your third-party libraries in a dedicated team project. Contributors to the various team projects map in the folders that contain the libraries they need.

For example, FabrikamFiber puts the following team project, branch, and folder structure in place:

Raisa sets up her dev machine with two workspaces for two different efforts, each of which map in the libraries she needs:

By default certain types of files (for example, .dll files) are ignored by version control. As a result:

When you add ignored files to folders that are mapped in a local workspace, they do not appear in the Pending Changes page in Team Explorer.

When you try to add ignored files using the Add to Source Control dialog box (for example by dragging them into Source Control Explorer), they automatically appear in the Excluded items tab.

You can configure which kinds of files are ignored by placing text file called .tfignore in the folder where you want rules to apply. The effects of the .tfignore file are recursive. However, you can create .tfignore files in sub-folders to override the effects of a .tfignore file in a parent folder.

######################################
# Ignore .cpp files in the ProjA sub-folder and all its subfolders
ProjA\*.cpp
#
# Ignore .txt files in this folder
\*.txt
#
# Ignore .xml files in this folder and all its sub-folders
*.xml
#
# Ignore all files in the Temp sub-folder
\Temp
#
# Do not ignore .dll files in this folder nor in any of its sub-folders
!*.dll