How to structure shared projects

Question

Visual studio warns about storing projects in directories that are not sub-folders of the solution:

The project that you are attempting to add to source control may cause other source control users to have difficulty opening this solution or getting newer versions of it. To avoid this problem, add the project from a location below the binding root of the other source controlled projects in the solution.

How do shared projects fit into this constraint? E.G. Given

$\BranchName\Project1Name\Project1.sln

$\BranchName\Project2Name\Project2.sln

Where can I put

MyCompany.DataLayer.proj?

Answer 1

After some research the option boils down to basically two options:

1. Reference the code from a shared location
2. Branch the shared code

Shared Location:

With this approach, you map the source from a shared location such as another team project into the workspace on your development computer. This creates a configuration that unifies the shared source from the shared location with your project code on your development computer.

The advantage of this approach is that any changes to the shared source are picked up every time you retrieve the latest version of the source into your workspace. For example consider a team project named Common that contains the shared source. To reference the code from this location, you map both team projects to a common path location on your development computer.

Branching

With this approach, you branch the shared code from the common team project into your team project. This also creates a configuration that unifies the source from the shared location and your project.

The difference with this approach is that the shared source changes are picked up as part of a merge process between the branches. This makes the decision to pick up changes in the shared source much more explicit. You decide when to perform a merge to pick up latest changes.

Further Info for Winforms.
Further Info for ASP.NET.

With a shared location you can't shouldn't use a project reference which means you lose out on the advantages of such references over file references. I have yet to try, thoeretically one could branch to a subfolder location of $\BranchName\Project1Name\Project1.sln and have the ability to create project references safely.

A third option, somewhat glossed over on MSDN is to put all sln files into the root folder of the branch. Then store projects in folders below said root.

This error message is displayed to let people know that solution files use relative paths which can cause problems.
E.G.

<ProjectReference Include="..\..\Applications\DL\MyDL.csproj">

For example, if another developer were to map a solution to a different physical location on their hard drive:

"..\..\..\Applications\DL\MyDL.csproj"

...then the build will be broken on their machine. Personally, I say its easier to implement a best practice that every developer maps to the same physical location:

C:\TFS and none of this stuff should present a concern.