title: How to handle shared projects in team foundation server source control structure
body: <p>After having read <a href="https://stackoverflow.com/questions/381020/team-foundation-server-source-control-structure">Team Foundation Server Source Control Structure</a> which I have followed a few questions come to mind that I am wondering if anyone can comment on.</p>
  
  <p>I have a few components that make up a project I am working on. I have a smartclient, a webservice, a proxy for the webservice that the smartclient uses, a daemon and a common utilities library that is used in both the smartclient and the webservice.
  Each of the components are related to the same work project.</p>
  
  <p>I have structured my source tree so that each of the components is independent - in other words each component (smartclient, webservice, daemon, proxy, common utilities) has its own trunk and its own solution file as I want to be able to release each component independently. For components that are used by other components, such as in the case of the smartclient using the proxy and the common utilities, I have created releases that are handled like any other 3rd party library (binaries referenced instead of projects). Can anyone confirm that this is somewhat a best-practice and if not how should this be done otherwise?</p>
  
  <p>I have been building releases of my components using tfs build and am wondering where I should put the releases if anywhere other than in the build output directory where all the tfs builds reside. Should I perhaps check them (e.g. proxy release assemblies to be used by the smartclient) into TFS along with any other 3rd party libraries and then branch the release assemblies where they are to be used (e.g. branch proxy release dlls to the smartclient lib directory)?</p>