How to handle shared projects in team foundation server source control structure

Question

After having read http://stackoverflow.com/questions/381020/team-foundation-server-source-control-structure which I have followed a few questions come to mind that I am wondering if anyone can comment on.

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.

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?

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)?

Answer 1

So you are essentially referring to what is commonly known as 'Dependency Replication'. Make use of Team Build and replicate your dependencies. There is a tool called 'Dependency Replicator' which will let you chain builds together.

So for example, your utilities class may not change much. But when it does, you need to ensure that: A) It builds on the server B) All dependent projects build as well.

Dependency replicator lets you specify (in XML) how assemblies depend on each other, and which 'build' to run when a dependency gets updated.

Answer 2

What we have done is creating a public \common share on the TFS server which contains subfolders corresponding to each major shared project. E.g.:

\\common  
    \sharedproject1
        \v1.0.0
        ...
        \vN.0.0
    ...
    \sharedprojectN

Each of our non-shared projects reference specific shared assemblies in \**common*\*sharedprojectN**\v**M.m.n.**

We first run automated builds of shared projects when needed.
Then changing the build quality to a specific value (e.g. "Ready For Reference") indicates that the output of the build needs to be automatically copied to one of these shared versions.

We can then run automated builds for projects using the output of these shared projects.
We use other build quality statuses (e.g. "Ready for System Integration") to indicate that a build of a main application is ready for deployment to a specific environment (e.g. test).
This triggers the packaging of a project output into a specific release folder on our public \release share.

Finally we use automated deployment tools to install a given release onto the appropriate servers in a given target environment.