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.