代码之家 › 专栏 › 技术社区 › Justin Rusbatch

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

tfs2008 project-management tfs asp.net

2

Justin Rusbatch · 技术社区 · 16 年前

我的团队目前正在开发一个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 普通的 项目更新后,所有使用它的其他项目都应该以最小的工作量开始使用最新版本。

基于我们当前的层次结构,有没有简单的方法来实现这一点?我读过这本书 TFS patterns & practices

2 回复 | 直到 16 年前

1

2

Ryan Cromwell 16 年前

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

我会说,作为一个整体,你应该重新考虑你的文件夹结构。它不允许非常灵活的分支结构。您似乎正在使用TFS存储库,就像许多VSS用户以前使用的一样:作为一个版本化的文件系统。

2

1

Jeremy Samuel 16 年前

一个可行的解决办法是共同的项目都输出到而不是每个本地/bin文件夹。
然后可以将该目录添加到 Web项目解决方案。所有的应参考DLL
该目录可以作为文件夹。队里的每个人都会必须映射文件夹到解决方案文件。
“最小努力”的地方这篇文章的重点是文件必须在以下时间签入/签出那你就得知道最新消息。最新消息要求实际上可能更好, 当你在中间时

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