最近一直在使用Visual Studio 2010开发基于Silverligth的项目，并且使用Team Foundation Server作为整个开发过程的管理工具。为了保证开发过程中互相的嵌入不影响彼此，我们配置了Team Build Service，并且使用了Gated Check-in（参考Team Build 2010 – Gated Check-in 拒绝无法编译的代码嵌入了解Gated Check-in）来控制每个人嵌入的代码是可以被Team Build成功编译的。在开始的几天里，Team Build是可以正常的运行并且效率很高。但突然有一天发现Gated Check-in运行了长达6个小时却仍然无法结束，并且大有悄无声息继续长时间运行的势头，问题出在哪儿呢？
Figure 1 - 运行长达6小时的Team Build Instance
打开当前的Build实例来看看到底发生了什么。从下图中我们可以看到所有的Test都已经运行并且通过，Test Settings and Test Impact也都已经被运行和评审过，接下来的Publish的工作也完成了，那接下来它在干什么呢？我们不得而知，因为通过这里我们看不到它还有哪些工作需要完成。
Figure 2 - 当前运行的Team Build的最后动作
已经运行了6个小时了还要继续运行吗？答案是否。作为一个企业，运行一个长达6小时的Team Build那简直就是一种对工作的耻辱（很可惜的我们挑战了一次自己的忍耐力，但却没看到结果）。于是Stop Build。这一停止不要紧，通过Summary你顿时眼睛冒火，呵呵，我终于知道它都做过了什么。
Figure 3 - Team Build实例的信息汇总
上图的高亮部分我们可以清楚的看到Team Build都已经做过了哪些事情，我们还可以清楚的看到在测试运行过后我们都能看到代码覆盖率了。那好，我们现在知道它做完了这些事情，但问题是我们怎么知道它还要做哪些事情呢？还记得每个项目都有的TraceAndTestImpact.testsettings文件吗？它定义了对这个项目的调试分析的测试设置，说白了就是用于调试分析的。它指定在编译完整个项目后收集哪些数据来对项目做哪些分析。既然我们已经明确知道编译工作做完了，那么我们就能知道它是在运行调试分析了。看来就是这个文件的配置问题了。先打开TraceAndTestImpact.testsettings文件看看都有什么。
很快的我们找到了元凶。原来在Data and Diagnostics中定义了在做调试分析期间都做什么工作。默认情况下会有如下图所示的几个动作被选中，问题就处在这里了。但我们怎么定位是哪一步出问题了呢？
Figure 4 - Data and Diagnostics settings
在图三中我们已经得知其运行过的动作，并且可以清楚的看到Code Coverage的数据，那么对照上边的动作列表我们可以看出第二项就是Code Coverage，那么既然这一项运行完了，接下来肯定是运行IntelliTrace了。在使用IntelliTrace在Visual Studio 2010中调试.NET应用程序中我们也知道了IntelliTrace是非常消耗资源的，并且占用了巨大的空间来提供相关的调试信息，现在我们可以基本肯定就是这个动作在作怪了。System Information和Test Impact都不算太大的消耗，而且在图三中根本没有看到相关信息，所以我们认定是它了。OK，取消对IntelliTrace的选择，然后Apply，将改变的.testsettings嵌入Source Control。但奇怪的是，发生了意想不到的错误：
Figure 5 - 仍然无法build，提示有被其他线程使用的文件。
很简单的解决办法就是到Build Server上结束所有TFSBuildService账户（运行Team Build的账户）的所有线程，并重新启动Build Server。为什么呢？原因是Team Build一直试图在访问Out中的文件来获取相关调试分析信息，长时间的运行可能导致线程已经被架空但却一直在占有此文件夹。OK.重启后再次嵌入.testsettings文件，一切正常。再次嵌入其它的更改并触发Gated Check-in也一定会是成功的。
Figure 6 - 所有变动被正常提交
当然，.testsettings中还有相关对于Unit Test， Web Test等的设置，如何定义适合自己项目的配置项是需要仔细的琢磨的，合理的使用相关的配置项能给我们的软件管理带来很大的方便，但多余的项目或许就像本文描述的问题一样带给我们巨大的不便。希望对您有所帮助：）
