TFS 2010 File/Project Structure

Question

I am currently working with a source tree that has one sln file housing all the WebApps, WinServices, WebServices, Console Apps and Common libraries (Business entities, custom controls etc).

The file structure for this is very flat, as in

+--Solution Folder
 +----Solution File
 +------WebApp1
 +------WcfService1
 +------WinService1
 +------CommonEntities
 +------WebControls1
 +------ThirdPartyAssemblies

I have begun work to create separate solutions for each web app, wcf service etc. In doing this I am able to see the common projects across these solutions.

MY Question to you guys is how do i structure my file system within TFS so i can use the common projects across the board?

I am more than happy to follow the Single TFS Project approach defining areas per site/service for work items and reporting, but i am less keen on branching the common libraries for each project. That said how have you guys overcome these problems?

I understand that people also suggest having the common projects in one solution and then referencing the compiled binaries in other solutions. I'm not really keen on this approach either. To be fair i will take the lesser of two evils if these are the only options but am eager to see how other people have tackled it.

Answer 1

The recommendations in M.Radwan's answer for Structuring the projects don't take into account CI (Continuous Integration) and gated builds. I have an issue with Microsoft recommending things this way. CI and gated builds are triggered currently by the workspace mappings. So solution files should NOT be up at the top under Main. For instance if you have all the solution files up at the solution folder level and if you have separate gated builds set up for WebApp1, WcfService1, WinService1, Common entities, etc. They would all need to have the Main Solution Folder mapped and to be efficient the not needed folders cloaked (extra work that is a pain to be maintained) and when a developer checked in code to any of these folders, lets say WebApp1, they would be presented with a dialog to choose which gated build to run. This dialog would have all of these gated builds present since they all map the same structure, and a dev may choose WinService1 since its available and their code couldn't possibly fail that build since none of the code in WebApp1 is in that build. So potentially code that doesn't compile just got past the gated build system.

Reasons its not good for CI, because if you have CI set and you change one file in any of the sub folders, it will trigger CI builds for every build set up with Main mapped to it. What you should do is put each solution file in it's own directory with it's code. So in his example MyApp1's solution file should be in the MyApp1 folder. This was you can have very small and contained builds that are only triggered by it's own code.

Answer 2

I can't exactly feel your point so I will try to open the door for you, have you look on Multiple Solution Approach?

More info:

Chapter 3 – Structuring Projects and Solutions in Source Control

For the source control structure there are different approaches

Have you look on Server-Side Structure?

$MyTeamProject1
     /Main                                                              Can contain solution (.sln) files    
            /Source
                        /MyApp1                                         Contains MyApp1.sln file
                                    /Source                             Contain folder for all source
                                                /ClassLibrary1          Contains ClassLibrary1.csproj
                                                /MyApp1Web              Contains Default.aspx
                                    /UnitTests                          Container folder for unit tests
                                                /ClassLibrary1Tests     Contains test project and code
                                                /MyApp1WebTests         Contains test project and code
                        /SharedBinaries                                 Shared binaries e.g. libraries
                        /SharedSource                                   Shared source code           
            /Docs                                                       Contains product documentation
            /Tests                                                      Container for tests
                        /FunctionalTests
                        /PerformanceTests
                        /SecurityTests /

More info:

Chapter 4 – Structuring Projects and Solutions in Team Foundation Source Control