Asp.net TFS项目结构使简单的事情变得困难

我的团队目前正在开发一个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

）目前包含十五个项目（包括图表中显示的每个

.csproj

文件）。昨天，我们决定将

Common

目录中包含的项目移动到它们自己的解决方案中，我们应该通过引用编译的DLL而不是项目本身将它们包含在网站中。只要更新了一个

通用

项目，所有使用该项目的其他项目都应该开始使用最新版本

基于我们当前的层次结构，有没有简单的方法来实现这一点？我已经阅读了指南，但实施其任何建议都需要进行重大更改（以及更新我们的所有项目和解决方案）。此外，我们的组织正在等待TFS2010发布后才能启用团队构建，因此我们无法使用它们。

• 一个可行的解决办法是 共同的项目都输出到 同一目录（“C:\temp\dlls”）， 而不是每个本地/bin文件夹

• 然后可以将该目录添加到 Web项目解决方案。所有的 应参考DLL 到从TFS中提取的公用文件夹

• 该目录可以作为 文件夹。队里的每个人都会 必须映射文件夹 局部具有相同的相对路径 到解决方案文件

• “最小努力”的地方 这篇文章的重点是文件 必须在以下时间签入/签出 编译。团队的其他成员将 那你就得知道最新消息。最新消息 要求实际上可能更好， 因为你不想强制改变 当你在中间时 发展中

基本上，您会在web项目解决方案中添加一个包含已编译DLL的文件夹。这也是所有公共DLL构建到的文件夹。该文件夹是web解决方案中所有项目引用公共DLL的位置。当someon重建时，他们必须签出文件夹中的DLL，构建，然后重新签入。当开发人员需要最新版本时，他们会调用文件夹上的GetLatest并重建他们的项目

这实际上在我们编译DLL以供参考的类似情况下对我们有效。对我们来说，不同之处在于编译后的DLL很少发生变化，以至于整个“GetLatest”范式从未发挥作用

更“可移植”的解决方案是专门针对共享项目/解决方案进行构建。这些构建的最后一步是将二进制文件检入发布文件夹（可能在/libraries下）。当获取客户机项目（那些引用二进制文件的项目）的最新版本时，您将得到最新的二进制文件。您不会失去分支客户机项目的能力，团队成员可以根据自己的选择自由映射文件夹

---

我会说，作为一个整体，你应该重新考虑你的文件夹结构。它不允许非常灵活的分支结构。您似乎正在使用TFS存储库，这与许多VSS用户以往的做法非常相似：将其作为一个版本化的文件系统。

同意这两点。如果没有其他内容，请将Common+Library+Site移动到单个父项下。否则，如果不创建一个全新的团队项目，您将永远无法对代码进行分支。我在过去曾提出过分支，但大家一致认为这只会使事情进一步复杂化。分支实际上应该是一个团队和个人的选择，但我理解。对于那些有兴趣这样做的人来说，可以做一些非常小的事情来让分支变得非常容易。团队成员不会受到个人生产力分支的影响。