TFS Project with Multiple Visual Studio Solutions

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 i

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.

Answer 2

As you have predicted it:-

OurCompanyLibrary would be a VS Solution.

OurCompanyLibrary.Application1 ... OurCompanyLibrary.ApplicationN would be VS Projects within that solution.

OurCompanyLibrary.ApplicationX.dlls would be references in the OurCompanyIntranet and OurCompanyInternet VS Solutions.

I'm not sure I understand your problem.

An Application VS Project in OurCompanyLibrary would be separately buildable producing its own dll that could then be referenced in the other two solutions. If the problem is having all of the Applications under one VS Team Project (OurCompanyLibrary) then the answer would be to create a separate VS Team Project for each Application - OurCompanyLibrary1 for Application1, OurCompanyLibrary2 for Application2, etc. The development of each Application is then totally self-contained and separate from the others.

If the problem is that you want different portions of the source in different solutions then that is achieved by adding the project to a solution. This does mean that all of those solutions have all of the source code though. We have something similar where I work:- We have a solution that has 2 projects - our common business logic layer and our common data access layer. Each of our other solutions has those projects included. This means we can edit the source code from any solution.

I don't know if any of this will help you, but good luck with it!

Answer 3

If this is an application that in running in produciton I would make minimal changes to the folder/solution structure. In TFS in your build definition you can select multiple projects or you can also put multiple solution in the build script like in the below example

How to build 2 solutions from a single TFS team build definition

Answer 4

If you want to have a centralized reporting for the whole codebase, you should explore the possibility to use one TeamProject to host everything.
In order to then distinguish between the different components/parts you can employ separate Areas within this TeamProject.
Check out this very interesting article, especially the Pros/Cons section.