TFS Project with Multiple Visual Studio Solutions -

our team looking @ using team foundation server v.11 (2012) manage our projects. our project management in spread sheets. our team develops software internal clients , there lot of dll sharing between projects. using svn our source code version control.

we have solutions different parts of our applications: common library, application libraries (business rules, etc), intranet website, internet website, windows forms. here 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 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 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 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 splitting code multiple solutions because can reuse application libraries in different situations (intranet apps, internet apps, winform apps). also, intranet , internet solutions contain multiple applications. our current structure. i'm not sure best organizational structure, works us.

the problem switching tfs 1 team project can't have parts in multiple vs solutions. example, set tfs team project application1 have product backlog application. application1 requires changes ourcompanylibrary, ourcompanyintranet , ourcompanyinternet complete application but, using tfs, there 1 vs solution application1.

here example of how develop application. of domain model , business rules our stored in ourcompanylibrary vs solution. when develop application, call application1, first start creating domain model , business rules in ourcompanylibrary.application1 vs project under ourcompanylibrary vs solution. once domain model developed, move on program ui side of things in ourcompanyintranet , ourcompanyinternet vs solutions. these solutions mvc style website. ourcompanyintranet contains vs web project ourcompanyintranet.ui contains of views (.aspx files), css, javasciprt, etc. ourcompanyintranet contains of models , controllers separated application (ourcompanyintranet.application1 in case). organizing in tfs becomes problem, because want team project application1, application can span multiple solutions , don't want have duplicate code everywhere adding same ourcompanyintranet , ourcompanyinternet vs solutions source control.

how organize in tfs? there way should organize our code structure make more sense? articles or websites out there lead in right direction help.

first, don't use multiple team project, huge mistake make @ beginning. size of team , develop: 1 team project need.

you use 2 team projects when there 2 teams of different people, working on different project, different methodology/process.

with 1 team project can still:

• have many branches (related or not).
• have administration of source control @ tiniest level need
• split project sub categories (functional, technical, whatever need) using area path (which node tree) of work item. way can have 1 big product backlog or dedicated ones.
• overall reports on whole project or on specific area (still using area path, in reporting services)
• trust me on that, it's best way go , many many people (including me first time) make mistake use multiple team project , have paid price thereafter. need source control hierarchical structure , area path tree.

concerning solutions:

having 1 solution per main component of project not bad thing, developers can work on dedicated subset of project, maximize productivity , reduce coupling between components.

but still can have 1 global solution reference projects , use whenever need make changes impact project. having global solution easy way build whole project painlessly.

the issue here about cross component references, if 1 component develop (e.g. application1) needs component develop (e.g. ourcompanylibrary) creates dependency between both , application1 must reference "built assemblies" of ourcompanylibrary.

which implies either:

1. you must create location somewhere in source control store built assemblies of components referenced others. maintain build cycle release respecting right order.

2. take advantage of new standard nuget , setup in-house nuget server (very easy do) , build own nuget packages components referenced others.

3. the easiest way go including dependencies developed in-house in solution make sure built when needed. it's easy application1 project include of vs projects. don't or bad way go, it's call. sometime easy way best one.

each way has own pros/cons, , can decide 1 best go.