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

时间:2010-01-16 16:13:01

标签: asp.net tfs project-management tfs2008

我的团队目前正在开发一个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 - 因此我们无法使用它们。

2 个答案:

答案 0 :(得分:2)

更“便携”的解决方案是专门为共享项目/解决方案构建。这些构建的最后一步是将二进制文件签入到发布文件夹(可能在/ libraries下)。在获取客户端项目(引用二进制文件的最新版本)的最新信息时,最终会删除最新的二进制文件。您不会失去分支客户端项目的能力,团队成员可以自由选择映射文件夹。

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

答案 1 :(得分:1)

  • 可能有效的解决方案 Common中的项目全部输出到 同一目录(“C:\ temp \ dlls”), 而不是每个本地/ bin文件夹。

  • 然后可以添加该目录 Web项目解决方案。全部 应该提到DLLS 从TFS拉出的公共文件夹。

  • 该目录可以添加到TFS中 一个文件夹。团队中的每个人都会 必须映射文件夹 本地具有相同的相对路径 到解决方案文件。

  • “最小努力”的地方 片断是文件 必须在入住/退房时办理入住/退房手续 编译。团队的其他成员会 然后得到GetLatest。 GetLatest 要求可能实际上更好, 因为你不想强迫改变 当你在中间的时候 显影

您基本上最终会将一个已编译dll的文件夹添加到Web项目解决方案中。这也是所有Common dll构建的文件夹。该文件夹是Web解决方案中的所有项目都引用Common Dlls的位置。当有人重建时,他们必须检查文件夹中的dll,构建然后重新检入。当开发人员需要最新版本时,他们会在文件夹上调用GetLatest并重建他们的项目。

这实际上对我们来说在一个类似的情况下我们已经编译了dll来引用。我们的不同之处在于,编译后的dll很少被抄袭,整个“GetLatest”范例从未发挥过作用。

相关问题