Shared DLL's in Team Foundation Server

Question

This may have been asked before but i was not able to address my needs in all previous posts (I've been searching it for couple of hours). All posts are so specific to its special needs. (I've been writing projects for couple of years but a newbie to TFS)

My Need Is: I have one common helper project under default collection. (simple helper class and functions which helps me to avoid rewriting everything)

I am trying to use this helper project in every tfs project under different collections.

What is the best scenario to use?

• Default Collection -- HelperProj

• Collection 1 -- Project 1 -- Project 2

• Collection 2 -- Project 3 -- Project 4

Thanks in advance Onur

Answer 1

My advice would be to use a single project in a single collection unless you have a compelling reason not to.

The reason is that although TFS looks in many ways like one large file-system, there are some things that don't work very well across project and collection boundaries. In my experience putting code into different projects/collections only works cleanly if there isn't (and never will be) a dependency between the lumps of code, so you can work on a single project/collection in isolation.

Our company started off with a TFS project for each "real" project, but we constantly ran up against problems due to this until we reorganised our entire codebase into one collection containing 3 projects, for Documents, Assets, and Code (three distinct areas with no interdependencies)

Within a project you can still organise the code into folders so IMO there really isn't much point in using different projects and collections unless you have very different access/security requirements for the different codebases (which is unlikely if they have no dependencies).

The other approach is to use the 3 collections you describe, but eliminate the "live" dependencies between them by pre-building the libraries in DefaultCollection to provide a shared repository of binaries that you can link to from the code in the other collections. This could also help with versioning, where the library code could be updated but the binary not merged into one of your other collections immediately, allowing the teams that work on the other collections to pull in updates to the library code only when it suits them. This can help stop problems being caused by changes for team A being immediately used by team B.

Answer 2

Here is a link that may help you with your needs. Take a look at the work-space mapping and branching features to achieve what you need.

Code Sharing in Team Foundation Server

Organizing Your Server with Team Project Collections