TFS 2010 Folder Structure Recommendations?

Apologies in advance for the long post.  I’m hoping someone can help me get my head around properly designing a TFS folder structure.   We’re a special needs school and we create and maintain a number applications that are used internally by staff primarily for data collection and reporting.  Many of our Visual Studio 2010 solutions reuse common projects.  All solutions use project references where possible and file references in the case of 3rd party libraries where we don’t have the source code.  Up until a couple of weeks ago, our dev team consist of one guy; me.  Source control consisted of zipping projects and using assembly name and version as a file naming convention.  Implementing a real source control system has been on my to do list forever but is something I simply didn’t have the resources, time, or urgent need to do on in a one man shop.

We’ve added a second dev and have been focusing on a TFS 2010 implementation.  We’ve spent the past week+ sifting through the best practices guides including the CodePlex patterns and practices guide, reading countless blogs and StackOverflow posts about recommended folder layouts but there seems to be no simple answer or recommendations about how we should organize our folder structure.  

Most of our VS Solutions use many of the same projects such as those listed in “Common Projects” below. Here’s an example of how our Visual Studio Solutions are laid out.

Common Projects (each of these projects is self-contained in its own folder.):

SplashScreen.csproj
ApplicationUpdater.csproj
TraceLogger.csproj
Win32.csproj
SpellCheckProvider.csproj
IEPDatabaseDAL.csproj
IEPDatabaseEnumGen.csproj


Third Party Assemblies:

DevComponents.DotNetBar2.dll
DevComponents.DotNetBar.Schedule.dll
DeployLX.Licensing.v5.dll
HiQPdf.dll

      
Solutions:

GraphBuilder.sln
          GraphBuilder.csproj
          SplashScreen.csproj (project reference)
          ApplicationUpdater.csproj (project reference)
          TraceLogger.csproj (project reference)
          Win32.csproj (project reference)
          SpellCheckProvider.csproj (project reference)
          DevComponents.DotNetBar2.dll (file reference)
          DeployLX.Licensing.v5.dll (file reference)
          HiQPdf.dll (file reference)

IEPBuilder.sln
          IEPBuilder.csproj
          IEPDatabaseDAL.csproj (project reference)
          IEPDatabaseEnumGen.csproj (project reference)
          SplashScreen.csproj (project reference)
          ApplicationUpdater.csproj (project reference)
          TraceLogger.csproj (project reference)
          Win32.csproj (project reference)
          SpellCheckProvider.csproj (project reference)
          DevComponents.DotNetBar2.dll (file reference)
          DeployLX.Licensing.v5.dll (file reference)
          HiQPdf.dll (file reference)

StepSheetBuilder.sln
          StepSheetBuilder.csproj
          IEPDatabaseDAL.csproj (project reference)
          IEPDatabaseEnumGen.csproj (project reference)
          SplashScreen.csproj (project reference)
          ApplicationUpdater.csproj (project reference)
          TraceLogger.csproj (project reference)
          Win32.csproj (project reference)
          SpellCheckProvider.csproj (project reference)
          DevComponents.DotNetBar2.dll (file reference)
          DeployLX.Licensing.v5.dll (file reference)
          HiQPdf.dll (file reference)

      …

How would we structure our TFS folders to allow solutions to easily use common project references such as those above?  There seems to be many recommendations to include all solutions under a single TFS Team Project.  Does this mean our TFS structure might look like this:

\\MyTfsServer\My Team Projects
          Main
                    CommonProjects
                              SplashScreen
                                        SplashScreen.sln
                                        Source
                                                  SplashScreen.csproj
                                                  Sourcecodefile1.cs
                                                  Sourcecodefile2.cs
                                                  …

                              ApplicationUpdater
                                        ApplicationUpdater.sln
                                        Source
                                                  ApplicationUpdater.csproj
                                                  Sourcecodefile10.cs
                                                  Sourcecodefile20.cs
                                                  …
                    …

                    ThirdParty
                              DevComponents.DotNetBar2
                                        Binaries
                                                  DevComponents.DotNetBar2 v11.2
                                                            DevComponents.DotNetBar2.dll

                                                  DevComponents.DotNetBar2 v12.0
                                                            DevComponents.DotNetBar2.dll

                              DeployLX.Licensing
                                        Binaries
                                                  DeployLX.Licensing.v4 r9876
                                                            DeployLX.Licensing.v4.dll

                                                  DeployLX.Licensing.v5 r2468
                                                            DeployLX.Licensing.v5.dll

                                                  DeployLX.Licensing.v5 r5858
                                                            DeployLX.Licensing.v5.dll

                     Applications
                              GraphBuilder
                                        GraphBuilder.sln (Solution includes project references to projects in CommonProjects
                                        folder and file references to assemblies in ThirdParty folder
                                       
                                        Source
                                                  GraphBuilder.csproj
                                                  MainForm.cs
                                                  MainForm.Designer.cs                                        
                                                  MainForm.resx
                                                  Sourcecodefile123.cs
                                                  Sourcecodefile456.cs
                                                  …

                              IEPBuilder
                                        IEPBuilder.sln  (Solution includes project references to projects in CommonProjects
                                        folder and file references to assemblies in ThirdParty folder
                                       
                                        Source
                                                  IEPBuilder.csproj
                                                  MainForm.cs
                                                  MainForm.Designer.cs                                        
                                                  MainForm.resx
                                                  Sourcecodefile789.cs
                                                  SourcecodefileABC.cs
                                                  …

Are we in the right ball park here? If not, can someone recommend how we might set up our folder structure?

Thanks -- Steve
SteveVAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

SteveVAuthor Commented:
Anyone?
0
Ryan McCauleyData and Analytics ManagerCommented:
The only difference between what you're recommending and what I do is that I include a "Development" folder in each project for main trunk development, and then I can branch into another folder if I need to get a version of something ready for release while not halting development on the trunk. This may not apply to you, but here's what it looks like for me:

$
 - Projectname
   - Development (SLN  file goes here)
     - Sub project 1
     - Sub project 2
   - v1.0
     - Sub project 1
     - Sub project 2

I know you can just label a release and move on, but I like having easy access to the code that was associated with a particular release, and if I need to do some debugging or patch a build when main development is full of half-implemented features, it just makes it really easy (and I don't have to mess with fetching a previous version mapped to a different folder, then what do I do with code changes?).

Other than that, I think your layout is great and looks remarkably similar the one I use without any issues.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
SteveVAuthor Commented:
Sorry for the delay in marking this as the excepted answer.  For some unknown reason I stopped getting notification emails from EE and assumed the question had gone unanswered.  The only issue with the layout in my original post is that there's no way to isolate the "Common Components" projects such that source code changes won't impact the solutions that consume them.  Ultimately, we chose to include the "Common Components" projects in the "Main" tree.  The huge down side is that if we want to branch an application, we branch the entire "Main" tree and cloak the folders we don't need.  This is a major PITA but is the only way we could figure out how to isolate code changes in the common components.  

It really would be helpful if MS were to provide some realistic scenarios along with guidance on how to best structure folders based on those scenarios.  There's a pretty big need for this kind of guidance based on the huge number of times the "TFS 2010 Folder Structure Recommendations" question gets asked.

Thanks for the help -- Steve
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Version Control

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.