TFS project structure makes simple things difficult

My team is currently working on an ASP .NET website. We are one of the first teams in our organization to use TFS2008 for source control. When I joined the project, it had already been active for a few months. Below is a diagram of the basic file structure we are using in TFS:

$/TfsProject/
|
|   /* Contains our in-house class libraries. */
|-- Common/
|   |
|   |-- Extensions/
|   |   |-- Extensions.csproj
|   |
|   |-- Loggers/
|       |-- Loggers.csproj
|
|   /* Contains third-party libraries. */
|-- Library/
|   |
|   |-- EnterpriseLibrary/
|       |
|       |-- v4.1/
|           |-- Microsoft.Practices.EnterpriseLibrary.Common.dll
|
|   /* Contains the website itself. */
|-- Site/
    |
    |-- Packages/
    |   |-- Packages.csproj
    |
    |-- Website.root/
        |
        |-- Website/
            |-- Website.sln
            |
            |-- Website/
            |   |-- Website.csproj
            |   |-- Default.aspx
            |
            |-- WebsiteUnitTests/
            |   |-- WebsiteUnitTests.csproj
            |
            |-- WebsiteWebControls/
            |   |-- WebsiteWebControls.csproj
            |
            |-- Utilities/
                |-- Utilities.csproj

The main website solution (Website.sln) currently contains fifteen projects (including each of the .csproj files displayed in the diagram). Yesterday a decision was made that the projects contained in the Common directory should be moved into their own solution, and we should include them in the Website by referencing the compiled DLLs instead of the projects themselves. Anytime one of the Common projects is updated, all other projects that use it should begin using the latest version with minimal effort.

Is there any easy way to implement this, based on our current hierarchy? I have read the TFS patterns & practices guide, but implementing any its suggestions would require significant changes (as well as updating all of our projects and solutions). Also, our organization is waiting until TFS2010 is released before they enable Team Builds -- so they're u开发者_高级运维navailable to us.

The more "portable" solution would be to have a build specifically for the shared projects/solutions. The last step of those builds is to check in the binaries into a publishing folder (possibly under /libraries). When getting latest for the client projects (those referencing the binaries) you will end up pulling down the latest binaries. You don't lose the ability to branch the client projects and team members are free to map folders as they choose.

I will say as a whole, you should reconsider your folder structure. It doesn't allow for a very flexible branching structure. You appear to be using your TFS repository much like many VSS users historically have: As a versioned file system.

• A solution that may work is to have the projects in Common all output to the same directory ("C:\temp\dlls"), rather than each local /bin folder.

• That directory can then be added to the Web Project solution. All of the references to the DLLS should be made to the common folder pulled from TFS.

• That directory can be added to TFS as a folder. Everyone on the team will have to have the folder mapped locally with the same relative path to the solution file.

• The place where the "minimal effort" piece breaks down is that the files will have to be checked in/out when compiled. The rest of the team would then have to GetLatest. The GetLatest requirement may actually be better, because you don't want changes forced to you while you are in the middle of developing.

You basically end up having a folder with compiled dlls added to the web project solution. That is also the same folder that all the Common dlls are built to. That folder is where all the projects in the web solution reference the Common Dlls. When someon rebuilds, they have to check out the dlls in the folder, build and then check back in. When a developer wants the latest, they call GetLatest on the folder and rebuild their projects.

This actually worked for us in a similiar situation where we had compiled dlls to reference. The difference for us is that the compiled dlls chagned so infrequently, that the whole "GetLatest" paradigm never came into play.