【发布时间】：2014-01-20 05:08:08
【问题描述】：
这可能是一个简单的问题，但我有点难过。
我正在定制一个 TFS 2013 构建过程来执行我们品牌的版本控制，其中一个步骤是应用包含刚刚构建的版本的标签。
新的 2013 工作流程在获取来源时应用标签。为了构建自定义标签，我需要建立版本的源代码，因为我们让开发团队根据功能和修复来管理他们的主要/次要版本部分。我可以轻松地抑制自动标记；事后应用自定义标签似乎并不那么容易。
Team Build 工作流的早期版本公开了工作区和构建代理上下文，这使得这很容易。 2013 年似乎将所有这些都包含在了新的活动中。
LabelWorkspace 活动看起来正确，但我无法找到 Scope 和 Workspace 所需的值。 LabelSources 也可以工作，但对于此目的来说似乎过于精细。
关于 GetWorkspace，在线文档对此活动的行为并不太清楚，我不喜欢为了获取环境工作空间的句柄而冗余获取所有源的想法。我可能误解了这个活动。
我也不喜欢在构建过程中直接使用 TFS API 先发制人地往返获取本地文件和已知版本的想法，这意味着，我不想这样做如果可以避免，则在新工作流程中完成标记，因为看起来这将是大量冗余代码和计算。
任何人都知道一种直接和简单的方法来连接它吗？
【问题讨论】：
-
不喜欢回答我自己的问题，但到目前为止我想出的最简单的答案是简单地使用 TfGetSources 活动，并将 LabelName 作为参数传递。对于这个活动实例，我指定 CleanWorkspace = False，期望这会做最少的工作并且不会获得多余的资源。我还确保我传递了“GetVersion”值，以确保构建是否配置为获取特定版本。我担心这会将错误的来源标记为高活性解决方案，因此我也在研究这个细节。
-
所以，事实证明微软在这方面的改变确实强制了一些正确性，因为最简单的事情是在获取源之前创建自定义标签。这确实防止了会导致错误包含在构建期间提交的更改集的竞争条件。我们可能可以在标签中没有 Major.Minor 版本元素的情况下生活，因为特定构建的 build.revision 冲突的可能性为零。
-
我在工作流程中将标签逻辑向前推进。这省略了主要 - 次要版本部分，经过考虑，这些部分对于将标记的源追溯到部署的程序集的能力并不重要。所以答案是在获取源之前计算您的标签，将值放入局部变量，然后在 TfGetSources.LabelName 属性中使用该值。如果您有需要访问受控项目的标签生成逻辑，那么您会遇到一个更复杂的问题，如果可能的话，您应该在设计中尽量避免。