如何在团队基础服务器源代码控制结构中处理共享项目

Question

在阅读了Team Foundation Server Source Control Structure 之后，我想到了一些问题，我想知道是否有人可以发表评论。

我有几个组成我正在从事的项目的组件。我有一个智能客户端、一个网络服务、一个智能客户端使用的网络服务代理、一个守护进程和一个在智能客户端和网络服务中都使用的通用实用程序库。 每个组件都与同一个工作项目相关。

我已经构建了我的源代码树，以便每个组件都是独立的 - 换句话说，每个组件（智能客户端、Web 服务、守护程序、代理、常用实用程序）都有自己的主干和自己的解决方案文件，因为我希望能够独立发布每个组件。对于其他组件使用的组件，例如在 smartclient 使用代理和通用实用程序的情况下，我创建了像任何其他 3rd 方库一样处理的版本（引用二进制文件而不是项目）。任何人都可以确认这在某种程度上是一个最佳实践，如果不是，应该如何做？

我一直在使用 tfs build 构建我的组件的版本，我想知道如果除了所有 tf​​s 构建所在的构建输出目录之外的任何地方，我应该将这些版本放在哪里。我是否应该将它们（例如，智能客户端使用的代理发布程序集）与任何其他 3rd 方库一起检查到 TFS 中，然后将发布程序集分支到要使用它们的位置（例如，将代理发布 dll 分支到智能客户端 lib 目录） ?

Answer 1

我们所做的是在 TFS 服务器上创建一个公共 \common 共享，其中包含与每个主要共享项目对应的子文件夹。例如：

\\常见的 \共享项目1 \v1.0.0 ... \vN.0.0 ... \sharedprojectN

我们的每个非共享项目在\common\sharedprojectN\vM.m.n.中引用特定的共享程序集

我们会在需要时首先运行共享项目的自动构建。
然后将构建质量更改为特定值（例如“Ready For Reference”）表示构建的输出需要自动复制到这些共享版本之一。

然后，我们可以使用这些共享项目的输出为项目运行自动构建。
我们使用其他构建质量状态（例如“系统集成准备就绪”）来指示主应用程序的构建已准备好部署到特定环境（例如测试）。
这会触发将项目输出打包到我们公共 \release 共享上的特定发布文件夹。

最后，我们使用自动部署工具将给定版本安装到给定目标环境中的适当服务器上。

Answer 2

所以你本质上是指通常所说的“依赖复制”。 利用 Team Build 并复制您的依赖项。有一个名为“Dependency Replicator”的工具可以让你将构建链接在一起。

例如，您的实用程序类可能不会有太大变化。但是当它发生时，您需要确保： A）它建立在服务器上 B) 所有依赖项目也都构建。

依赖关系复制器允许您（在 XML 中）指定程序集如何相互依赖，以及在更新依赖关系时运行哪个“构建”。