TFS 2010 - how should VS solutions with shared libraries be mapped into "team projects"?

Question

I'm new to TFS (and branch/merge style source control). I've been reading through the TFS Branching Guide for 2010, but I'm having a bit of a disconnect with how my solutions should be mapped to the source control. I think my main problem is how to understand th best placement of class libraries shared between solutions.

Our environment is line-of-business with about a dozen separate web applications and about half a dozen class libraries shared between the web applications. Our solutions generally consist of one of the web applications, it's unit testing project, the supporting class library projects, and any third-party assembly references.

So two representative solutions would look like:

SOLUTION A
-- WebApp11 Project
-- WebApp11UnitTests Project
-- ClassLib11 Project
-- ClassLib22 Project
-- ClassLib33 Project
-- bin\*.dll

SOLUTION B
-- WebApp22 Project
-- WebApp22UnitTests Project
-- ClassLib11 Project
-- ClassLib22 Project
-- ClassLib44 Project
-- ClassLib55 Project
-- bin\*.dll

How should these be structured in TFS?

Do we create a Team Project for each Solution, such that ClassLib11, for example, would belong to both TEAM SOLUTION A and TEAM SOLUTION B?

I'm thinking yes, so that each Team Project consists of everything required to roll out into production.

What if we use a couple different solution files, such as having one large solution file that has every web application and every class library? Where does that solution fit in?

Answer 1

We keep all of our production applications (we have a suite of applications that have significant overlap) in a single TFS Project. This allows all of them to be governed by the same rules since they are, potentially, all being modified by different people all the time but a single person will sometimes/often have scenarios where they are interested in many different applications together.