TFS 2008 和通用库文件夹结构

Question

TFS 2008 和通用库

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

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

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

---

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

目前，每个项目都有包含在项目中的 dll。以邮件模块为例，许多项目都需要邮件功能。通用模块非常稳定并且大部分是静态的。

但是，如果邮件模块发生变化怎么办。似乎有更好的方法，而不是检查每个项目并更新 dll。是否可以在任何时候调用“获取最新”时允许 TFS 获取最新的邮件模块？显式或隐式。

Answer 1

除非您确实需要库的源代码在其他解决方案中可用，否则我的建议是在项目中包含库的二进制文件，这些项目将使用它们，而在 TFS 中两者之间没有任何明确的链接。库构建的自定义标签有助于轻松返回和重建任何选择的共享库版本。

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

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

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

另一种选择是将公共组件的 DLL 发布到共享库的每个构建上的已知位置，并且单个构建甚至通过复制任务从该公共位置（网络共享）获取可用的任何版本。这很简单，可能会导致通用组件的版本控制出现问题，但在简单的情况下应该可以很好地工作。