In my department we are developing several smaller AddOns for some unified communication server. For versioning and distributed development we use a Team Foundation Server 2012.

But: there is only one large TFS solution for all of our applications and libraries:

• Main Solution
  • Applications
    
    • App 1
    • App 2
    • App 3
  • Externals
  • Libraries
    
    • Lib 1
    • Lib 2
  • Tools

The "Application" path contains all main applications. Those are not depending on each other, but they depend on the Libraries and Externals projects.

The "Externals" path contains some external DLLs referenced in our Applications and Libraries.

The Libraries path contains commonly used libs (UI templates, Helper classes, etc.). They do not depend on each other and they are referenced in the Libraries and the Tools projects.

The Tools path contains some helper programs like setup helpers, update web services, etc.

Now, there's some major points why I'd like to change this structure:

• We can't use server builds.
• It's uncomfortable to manage TFS scrum management with sprints, impediments, etc. with a solution structure like that.
• Every developer always has access to all projects in the solution.
• A complete build lasts too long if one accidentally hits [F6] in Visual Studio...

What would you change in this solution? How would you break those projects into smaller Solutions, how should those solutions be structured.

My first approach would be, to create one TFS project for each Application, Library and Tool. But how can I ensure that e.g. App 2 always contains the newest version of Lib 1? Do I have to monitor changes on Lib 1 and update App 2 manually as soon as the Lib changes? Or can I somehow force Visual Studio to always use the newest version of an external project somehow?