Question

Our team is looking at using Team Foundation Server v.11 (2012) to manage our projects. We currently do our project management in spread sheets. Our team develops software for internal clients only and there is a lot of dll sharing between projects. We are also using SVN for our source code version control.

We have Solutions for different parts of our applications: Common Library, Application Libraries (business rules, etc), Intranet Website, Internet Website, Windows Forms. Here is what our SVN structure looks like

SVN
    -CommonLibrary (VS Solution)
        -Source
            -CommonLibrary.Core (VS Project)
            -CommonLibrary.Security (VS Project)
            -CommonLibrary.Web (VS Project)
    -OurCompanyLibrary (VS Solution)
        -Libraries (Projects within this solution reference these)
            -CommonLibrary.Core.dll
            -CommonLibrary.Security.dll
        -Source
            -OurCompanyLibrary.Application1 (VS Project)
            -...
            -OurCompanyLibrary.ApplicationN (VS Project)
    -OurCompanyIntranet (VS Solution) (MVC framework)
        -Libraries (Projects within this solution reference these)
            -CommonLibrary.Core.dll
            -CommonLibrary.Security.dll
            -CommonLibrary.Web.dll
            -OurCompanyLibrary.Application1.dll
        -Source
            -OurCompanyIntranet.Application1 (VS Class Library Project)
            -...
            -OurCompanyIntranet.ApplicationN (VS Class Library Project)
            OurCompanyIntranet.UI (VS Web Project)
    -OurCompanyInternet (VS Solution) (MVC framework)
        -Libraries (Projects within this solution reference these)
            -CommonLibrary.Core.dll
            -CommonLibrary.Security.dll
            -CommonLibrary.Web.dll
            -OurCompanyLibrary.Application1.dll
        -Source
            -OurCompanyInternet.Application1 (VS Class Library Project)
            -...
            -OurCompanyInternet.ApplicationN (VS Class Library Project)
            -OurCompanyInternet.UI (VS Web Project)

The reason for splitting the code up into multiple solutions is because we can reuse the application libraries in different situations (Intranet apps, Internet apps, Winform apps). Also, the intranet and internet solutions contain multiple applications. This is our current structure. I’m not sure this is the best organizational structure, but it works for us.

The problem with switching to TFS is that one Team Project can’t have parts in multiple VS solutions. For example, we would set up a TFS Team Project for Application1 so we could have a product backlog for that application. Application1 requires changes to OurCompanyLibrary, OurCompanyIntranet and OurCompanyInternet to complete the application but, using TFS, there would only be one VS Solution for Application1.

Here is an example of how we develop an application. All of the domain model and business rules our stored in the OurCompanyLibrary VS Solution. When we develop an application, call it Application1, we first start creating the domain model and business rules in the OurCompanyLibrary.Application1 VS project under OurCompanyLibrary VS Solution. Once the domain model is developed, we move over to program the UI side of things in the OurCompanyIntranet and OurCompanyInternet VS Solutions. These solutions are a MVC style website. OurCompanyIntranet contains a VS Web Project OurCompanyIntranet.UI that contains all of the views (.aspx files), css, javasciprt, etc. OurCompanyIntranet also contains all of the models and controllers separated by application (OurCompanyIntranet.Application1 in this case). Organizing this in TFS becomes a problem, because we want a Team Project for Application1, but that application can span multiple solutions and we don’t want to have duplicate code everywhere by adding the same OurCompanyIntranet and OurCompanyInternet VS Solutions to source control.

How would you organize this in TFS? Is there another way we should organize our code structure that would make more sense? Any articles or websites out there that would lead us in the right direction would greatly help.

Answer 1

First, don’t use multiple Team Project, this is a huge mistake that everybody make at the beginning. For the size of your team and what you develop: one Team Project is what you need.

You use two Team Projects when there are two teams of completely different people, working on a completely different project, with a completely different methodology/process.

With one Team Project you can still:

• Have many branches (related or not).
• Have the administration of Source Control at the tiniest level you need
• Split your project into sub categories (functional, technical, whatever you need) using the Area Path (which is a node tree) of Work Item. This way you can have one big product backlog or dedicated ones.
• Overall reports on your whole project or on specific area (still using Area Path, but in Reporting Services)
• Trust me on that, it’s the best way to go and many many people (including me the first time) make the mistake to use multiple Team Project and have to paid the price thereafter. What you need is a good Source Control hierarchical structure and a good Area Path tree.

Concerning Solutions:

Having one solution per main component of your project is not a bad thing, developers can work on a dedicated subset of the project, to maximize the productivity and reduce the coupling between components.

But you still can have one global solution that reference all your projects and that will be use whenever you need to make changes that impact all your project. Having a global solution is also an easy way to build your whole project painlessly.

The issue here is about cross component references, if one component you develop (e.g. Application1) needs another component you develop (e.g. OurCompanyLibrary) then it creates a dependency between both and Application1 must reference “built assemblies” of OurCompanyLibrary.

Which implies either:

1. You must create a location somewhere in your source control to store the built assemblies of all the components that will be referenced by others. Maintain a Build Cycle to release everything respecting the right order.

2. Take advantage of the new standard which is Nuget and setup an in-house Nuget server (very easy to do) and build your own Nuget packages for the components that will be referenced by others.

3. The easiest way to go is including all your dependencies developed in-house in the solution to make sure they are built when needed. It’s easy to do but your Application1 project will include most of your VS Projects. I don’t say it a good or bad way to go, it’s your call. Sometime the easy way is the best one.

Each way has its own pros/cons, and only you can decide which one is the best to go.