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 用户使用的一样:作为版本化文件系统。