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

Question

After having read 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

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\vM.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.