After some research, the option comes down to two options:
- Link to a code from a shared location
- Inclusion of common code
General location:
With this approach, you map the source to a common location, such as another team project in the workspace on your development computer. This creates a configuration that combines a common source from a shared location with the project code on your development computer.
The advantage of this approach is that any changes to the shared source are retrieved each time you retrieve the latest version of the source into the workspace. For example, consider a team project called General, which contains a common source. A link to the code from this location, you map both team projects to a common location on your development computer.
Branching
With this approach, you transfer the common code from the general project team to the project of your team. It also creates a configuration that combines the source from a common location and your project.
The difference with this approach is that the general source changes are taken as part of the merge process between branches. This makes the decision to pick up changes in a common source much more explicit. You decide when to merge to pick up the latest changes.
Additional information for Winforms.
Additional information for ASP.NET.
In a general location, you can not help using a project link, which means that you are losing the advantages of such links over file links. I still have to try, thoeretically one could navigate to the location of the subfolder $\BranchName\Project1Name\Project1.sln and be able to safely create project links.
The third option, somewhat obscured by MSDN, is to put all the sln files in the root folder of the branch. Then save the projects in folders below the specified root.
This error message is displayed to let people know that solution files use relative paths that can cause problems.
For instance.
<ProjectReference Include="..\..\Applications\DL\MyDL.csproj">
For example, if another developer had to map the solution to a different physical location on his hard drive:
"..\..\..\Applications\DL\MyDL.csproj"
... then the assembly will be broken on their machine. Personally, I say that it’s easier to implement the best practice that each developer maps to the same physical location:
C:\TFS , and none of these materials should be troubling.