Team Foundation Server：如何为共享程序集的两个应用程序配置工作空间？

Question

我对TFS上的工作区有疑问。目前，我正在使用TFS 2008（虽然我很快将迁移到TFS 2010），我有两个工作区：

• 工作空间1
• Workspace2

Workspace1和Workspace2每个都包含不同的应用程序，它们有不同的用途，不同的用户群，不同的开发人员对它们进行操作等等。因此，决定这两个应用程序应该驻留在它们自己的工作空间中，以便支持单独的构建管理，单独的权限等。但是，过去一些糟糕的规划已经在Workspace1中创建了对Workspace2的依赖。为了使Workspace1内的应用程序能够编译，它需要在Workspace 2中引用一些程序集。所以，它今天看起来像这样：

• 工作空间1
  • 对Workspace1程序集和Workspace2程序集的引用
• Workspace2
  • 对Workspace2程序集的引用

现在，我想看看是否有“最好”的方法来尝试完成以下任务：

• 让每个工作区包含其中代码的所有内容 需要才能编译和运行。
• 让两个工作区中的应用程序都引用共享 来自中心地方的集会。

我知道这两个目标相互冲突，但我很难决定该怎么做。也许我的整个问题是我使用工作区错了。或者，也许我正确地使用它们，并且这个问题没有真正的答案。我不知道。

所以，我的问题实际上有三个：

1. 这对其他人有意义吗？
2. 我做错了什么导致我陷入这种境地？
3. 如果你遇到这种情况，你会怎么做呢？

Answer 1

1. 将公共代码拉出到自己的项目中
2. 此新项目的自动构建会将生成的程序集部署到文件共享上的文件夹中
3. 两个现有项目都将引用共享中的公共代码

二进制文件不是源代码，不应检入源代码管理（IMHO）。

Answer 2

我认为这取决于Workspace 1在Workspace 2上的引用类型。如果引用的程序集采用“第三方”样式 - 我的意思是，不经常更新并且具有相当不变的API，以同样的方式引用互联网上的图书馆。如果是这种情况，我会将Workspace 2中构建的二进制文件签入到可以引用它们的文件夹中的Workspace 1中。每当对Workspace 2二进制文件进行更新时，请检查Workspace 1中的文件，将构建的文件复制到顶部并检查它们。

如果Workspace 2程序集的代码和API经常更改，那么您有2个选择。

1. 您可以尝试将2个工作区组合在一起（不确定它是多么容易）。
2. 您可以尝试将引用的二进制文件从Workspace 2分支到Workspace 1.有关如何执行此操作的信息here，但是存在一些限制，例如您无法分支Workspace 1（进行发布） / feature branch）虽然它有Workspace 2的分支。

Answer 3

从很久以前我花了很多时间在源代码管理中找到文件的最佳结构，在阅读了p＆amp; p指南之后，它向我展示了我需要的所有内容，比如在源代码管理中构建项目和解决方案，分支和合并策略，管理Visual Studio Team System中的源代码控制依赖关系以及许多其他有用的东西，您可以从codeplex下载它，点击以下链接 http://tfsguide.codeplex.com/

Answer 4

你有几个选择都需要权衡。

1. 将“共享代码”拆分为单独的TFS项目。正如约翰所说，从共享项目构建的放置位置获得每个依赖应用程序引用。

2. 将“共享代码”放置在与开发/发布周期最顺序的项目中。我指的是与其共享共同开发团队，共同发布周期和常见工作项规范的项目。是否有其他依赖项目从此项目放置位置引用该程序集。

3. 将“共享”代码的所有项目与公共库放在一个TFS项目中，以及“共享代码”。如有必要，为每个VS解决方案创建单独的构建。如果有必要，甚至可以锁定签入共享解决方案/项目的能力。