TFS 2008和Common库文件夹结构

时间:2010-03-09 18:06:52

标签: tfs

TFS 2008和通用库

我创建了一个名为“公共图书馆”的团队项目,该项目将托管整个TFS中众多不同团队项目中使用的代码。为了论证,假设我们在“Common Library”Team Projects,MailProject和LoggingProject下有2个不同的Librarys。整个TFS的其他项目将通过分支而不是实际的源代码使用这些项目的二进制表示。

为此Team Project设置文件夹结构的最佳方法是什么?我是否将项目添加到“公共库”并简单地“包含”bin / release文件夹作为项目的一部分?

我见过一些人创建单独“Deploy”文件夹的例子。我认为这与bin / release文件夹是同义的吗?


我们不希望其他解决方案中提供源代码。

目前,每个项目都包含在项目中的dll。使用邮件模块作为示例,许多项目需要能够邮寄。通用模块非常稳定,大部分是静态的。

但是,如果邮件模块发生了变化,该怎么办?似乎有一种更好的方法,而不是检查每个项目并更新dll。是否有可能在每次调用“获取最新信息”时允许TFS获取最新的邮件模块?无论是明示还是暗示。

1 个答案:

答案 0 :(得分:0)

除非你真的要求在其他解决方案中提供库的源代码,否则我的建议是在项目中包含库的二进制文件,这些库将使用它们并不真正在TFS中的两者之间有任何明确的链接。库构建的自定义标签可以帮助您轻松返回和重建任何选定版本的共享库。

如果共享库需要不同版本的不同版本,那么显而易见的解决方案是为需要为特定项目定制的每个版本的库创建一个单独的分支。

TFS没有类似于SVN的“外部”的概念 - 因此,如果您在项目中包含来自共享库的分支而不是分支该项目,则很难正确地传播更改。

我想你也可以在构建中使用Get task并从另一个版本中获取最新版本的DDL到当前项目中,但验证是否可以指向另一个项目的Workspace(我还没有厌倦它)和MSDN在这里有点模糊)。您可能需要为共享项目设置单独的工作区。

另一种替代方法是将公共组件的DLL发布到共享库的每个构建上的已知位置,并且对于单个构建,即使通过复制任务也可以从该公共位置(网络共享)获得可用的任何版本。这很简单,可能会导致公共组件版本化出现问题,但在简单的情况下应该可以正常工作。