Dll dependencies on a Visual Studio 2010 solution and TFS

Question

How can I make a solution in visual studio so that the .dll dependencies that reside in some other directory totally different from where the solution itself is affected by "get latest".

What I've tried is creating a Dependencies solution folder within the solution itself and added the dlls to it, that way they belong to the solution even though they don't belong to the directory structure of the solution.

So for example the .sln file is in:

D:\tfs\repository\main\SolutionA\solution.sln

and the dlls are in:

d:\tfs\repository\main\SolutionX\Dependencies\Binaries

What I really want to achieve is to have a foolproof way to build the solution, including the following scenario:

1- Have a brand new installation of windows, visual studio, etc.
2- open visual studio
3- find solution.sln on TFS, double click on it so that visual studio gets every project and files in the solution, and opens the solution 4- successfully build

What happens when I try the Dependencies solution folder approach and repeat the scenario above, it will get all the projects within the solution, opens it, but the dependencies solution contents won't be pulled from TFS (although Visual Studio shows them on Solution explorer), which I think is flawed.

Some suggestions that don't involve creating pre/post build scripts are appreciated.

Answer 1

When you attempt to open a solution for the first time using the TFS Source Control Explorer, you may find that not all of your dependencies will be retrieved - the squiggly line may be highlighting some of your missing References.

One work around is to...

SOLUTION SETUP

1. Checkout all of your source code from TFS (i.e. Main and all of the sub-directories)
2. Open your solution in Visual Studio (i.e. MyApplication.sln)
3. In the solution explorer, create a New Solution Folder called ThirdPartyDll, and then add the appropriate assembly references (i.e. Assembly1.dll, Assembly2.dll,...)
4. Check-in your solution to TFS

SAMPLE FILE STRUCTURE

• Main
  • MyApplication.sln
  • Source
    • MyProjectA
      • MyProjectA.csproj
    • MyProjectB
      • MyProjectB.csproj
  • Dependencies
    • Assembly1.dll
    • Assembly2.dll

Answer 2

You've run into a limitation of the "Open from Source Control" functionality. If you added the solution to source control from Visual Studio you should have seen the following message:

"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."

Open from Source Control will create a workspace mapping for the solutions root directory (D:\tfs\repository\main\SolutionA) but not a separate one for the SolutionX folder which is a peer to SolutionA. On the "new" machine you will need to manually create a workspace mapping to d:\tfs\repository\main in order to get both the SolutionA and SolutionX folder.

Answer 3

Create a solution folder and add the dependencies to it, that way when VS gets latest for the solution it will download these files. A bit brittle as people will need to maintain that folder but it works.

Alternatively create a nuget package and use restore packages on build. It will require a couple of extra steps when you create a new developer box (your nuget package repo will need to be added) but it will work for all projects going forward and is less brittle than the solution folder method.