Question

I have a question about Workspaces on TFS. Currently, I am using TFS 2008 (though I will soon be migrating to TFS 2010), and I have two workspaces:

• Workspace1
• Workspace2

Workspace1 and Workspace2 each contain different applications, which have different purposes, different user-bases, different developers that work on them, etc. And so, it was decided that these two applications should reside in their own workspaces, in order to support separate build management, seperate permissions, etc. However, some poor planing in the past has created a dependency on Workspace2 from within Workspace1. In order for the application inside Workspace1 to compile, it needs to reference some assemblies inside Workspace 2. So, it looks like this today:

• Workspace1
  • References to Workspace1 Assemblies AND Workspace2 Assemblies
• Workspace2
  • References to Workspace2 Assemblies

Now, I would like to see if there is a “best” way to try to accomplish the following:

• Have each workspace contain everything that the code inside of it
  needs in order to compile and run.
• Have the applications in both workspaces both reference the shared
  assemblies from a central place.

I know these two goals conflict with one another, but I am having a hard time deciding what to do about it. Perhaps my whole problem is that I’m using workspaces wrong. Or, perhaps I’m using them correctly, and there’s no real answer to this problem. I don’t know.

So, my question is really threefold:

1. Did this make sense to anyone else?
2. What am I doing wrong that is leading me into this situation?
3. If you were in this situation, what would you do about it?

Answer 1

1. Pull the common code out into its own project
2. Automated builds of this new project will deploy the resulting assemblies into a folder on a file share
3. Both of the existing projects will reference the common code from the share

Binaries are not source, and should not be checked into source control (IMHO).