asp.net - TFS项目结构让简单的事情变得困难

Question

我的团队目前正在开发 ASP .NET 网站。我们是组织中最早使用 TFS2008 进行源代码控制的团队之一。当我加入这个项目时，它已经活跃了几个月了。下面是我们在 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

主网站解决方案 (Website.sln) 当前包含 15 个项目(包括图中显示的每个 .csproj 文件)。昨天我们决定将 Common 目录中包含的项目移至它们自己的解决方案中，并且我们应通过引用已编译的 DLL 而不是项目本身将它们包含在网站中。每当更新其中一个 Common 项目时，使用该项目的所有其他项目都应该毫不费力地开始使用最新版本。

根据我们当前的层次结构，有没有简单的方法可以实现这一点？我已阅读TFS patterns & practices指南，但实现其中的任何建议都需要进行重大更改(以及更新我们所有的项目和解决方案)。此外，我们的组织正在等待 TFS2010 发布后才能启用 Team Builds，因此我们无法使用它们。

Answer 1

更“可移植”的解决方案是专门针对共享项目/解决方案进行构建。这些构建的最后一步是将二进制文件 checkin 发布文件夹(可能在/libraries 下)。当获取最新的客户端项目(那些引用二进制文件的项目)时，您最终将拉取最新的二进制文件。您不会失去对客户端项目进行分支的能力，并且团队成员可以自由映射他们选择的文件夹。

我想说，总的来说，你应该重新考虑你的文件夹结构。它不允许非常灵活的分支结构。您似乎正在使用 TFS 存储库，就像许多 VSS 用户历史上使用的那样:作为版本化文件系统。