Question

Looking for some feedback on setting up our solutions in TFS. Right now we are using source safe and it is painful. Fortunately we are finally going to TFS. We have a collection of projects and I am looking for the “best” way to set these up.

The core is a server solution and a client solution that make up the framework for our other applications. The server has a collection of a couple web services and some libraries and the client solution has several libraries and a couple client applications. The client interacts with the server.

There are also individual application solutions that are built on this framework. Several of the DLLs from the framework solutions are required in the individual applications. These DLL references get hosed up often and the versions sometimes get out of sync. Application 1 relies on library DLL from the Framework client project, etc.

How would you set these solutions up in TFS to minimize your problems? How would you automate some of this on builds of the framework solutions? The result I am looking for is simplifying the Applications 1, 2, and 3 getting updated versions of the DLL files from the framework Client & Server solutions and that they have the same version where possible with release schedules of the framework and the individual applications.

My first thought is to have one team project with an area for the framework and each mobile app. The framework area would have a client and server sub-area with their sub-areas. Then at the same level as the framework each application would exist. I am not sure how well this would work and how I could enforce the other applications automatically getting the most recent framework DLLs.

• Framework
• — Server
• — Server WS
• — Server Lib
• — Server DataAccess
• — Client
• — Client WS
• — Client Lib
• — Client DataAccess
• Application 1
• Application 2
• Application 3

Edit 20091020:
After talking with the PM for the framework and one of the applications this was his thoughts on how we should lay out our source code. This makes sense to me and does seem logical. It seems like it would keep the development branches for each application and their releases pretty isolated yet all together in the same project where it is easy to link requirements for Applications back to changes that are needed in the framework, etc.

Thoughts on this lay out? Any advantages / disadvantages you see?

        Framework  
           .Server  
              .Trunk  
              .Branches  
              .Releases  
           .Client
              .Trunk
              .Branches
              .Releases
        Application 1
           .Trunk
           .Branches
           .Releases
        Application 2
           .Trunk
           .Branches
           .Releases
        Application 3
           .Trunk
           .Branches
           .Releases

Answer 1

I would assume that you have a “release” stable version of the Framework on which all the application depend. I would create the project structure like this.

.Development
    .Framework
       .version
    .Application 1
       .version
    .Application 2
         version
.Main
   .Framework
   .Application 1
   .Application 2

.Release
   .Framework version xxx
   .Application 1 version xxx
   .Application 2 version xxx

So, when you move from Source Safe, you will create a branch Main in the Team project. Then branch out development branch for all development work and a release branch to maintain a version of source code for the current release. (this will help you to code hotfixes or reproduce any problem in the current production release).

All reference in Applications to the framework should be pointed from the latest release branch. This can be managed by getting appropriate folder when creating builds for individual applications.