How to organize projects in Team Foundation Server

Question

We are looking for some feedback on setting up our solutions in TFS. We are now using a safe source, and it is painful. Fortunately, we finally move on to TFS. We have a collection of projects, and I'm looking for the "best" way to set them up.

The kernel is a server solution and a client solution that form the basis for our other applications. The server has several web services and several libraries, and the client solution has several libraries and several client applications. The client interacts with the server.

There are also individual application solutions that are based on this structure. Several DLLs from the framework solutions are required in separate applications. These DLL links often arise, and versions sometimes go out of sync. Appendix 1 uses the library library DLL from the Framework client project, etc.

How would you install these solutions in TFS to minimize your problems? How could you automate some of them when building wireframe solutions? The result I'm looking for is to simplify applications 1, 2, and 3 that receive updated versions of DLL files from Client and Server Framework solutions, and that they have the same version, where possible, with release schedules for the structure and individual applications.

My first thought is to have one team project with an area for the framework and each mobile application. In the scope of the framework there is a client and server subarea with their subzones. Then at the same level as the structure, each application will exist. I'm not sure how much this will work, and how I can get other applications to automatically get the latest DLLs.

• Framework
• - Server
• --- WS Server
• --- Lib server
• --- DataAccess Server
• - Customer
• --- WS Client
• --- Lib client
• --- Client DataAccess
• Attachment 1
• Appendix 2
• Appendix 3

Edit 20091020:
After a conversation with the Prime Minister on the framework and one of the applications, these were his thoughts on how we should state our source code. It makes sense to me and seems logical. It seems that he will support the development branches for each application and their releases are quite isolated, but all together in one project, where it is easy to attach the requirements for applications to the changes that are necessary within the framework, etc.

Thoughts on this are laid out? What advantages / disadvantages do 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 suggest that you have a “releasing” stable version of the Framework that the entire application depends on. I would create a project structure as follows.

  .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 switch from Source Safe, you will create the main branch in the Team project. Then branch the development branch for all development work and the release branch to support the source version for the current version. (this will help you copy corrections or reproduce any problems in the current production version).

All links in applications to the framework should be indicated from the last release branch. This can be controlled by getting the appropriate folder when creating assemblies for individual applications.

Answer 2

Microsoft has a Visual Studio Team Foundation Server branch and join guide that you can use to select your preferred structure.