I'm setting up a [Team Foundation Service](https://tfspreview.com/) for me and a friend. We'll be using it to create a few hobby projects. 

I've set it up with a single Team Project, and the source control is currently structured as so

$\Projects\CommonLib

$\Projects\Project1

$\Projects\Project2

Where Project1 is a game, Project2 is a win8 app and commonlib is our common, reusable code which will be referenced by both Projec1 and Project2. Each project will consist of a solution containing multiple projects. 

CommonLib needs to be distributed to the two projects. My initial idea was to check the CommonLib binaries into a source control folder and branch it out to the two other projects, deploying it using some sort of custom Team Build process.

There's a problem, though. It's rather tedious to work like this, especially now in the early stages of development. We want to be able to add code to CommonLib at a rapid basis and whilst the process described above is fine when the codebase has matured and won't be modified frequently, it will be a hastle to perform all those steps every time something is added there (build -> deploy -> merge). 

On the other end of the scale, we could create a development solution for e.g. Project1 which also contains the CommonLib projects. However, this means that we might cause problems for Project2 if we cause breaking changes by mistake. This can be managed better with the branch+merge strategy described above

So my question is, am I missing any options which might enable us to retain the control whilst still being able to keep the development process' complexity at a minimum? I'm sure this is a common problem.