我们正在运行TFS 2010标准版，并且我们已经build立了一个自动构build，以便在有人签入代码时运行。 作为构build的一部分，我们运行所有自动化testing（使用MSTest构build）。 我们已经configuration构build以运行testing作为64位进程，但运行testing的QTAgent.exe在testing运行时在内存中增长。 目前，我们已经达到了〜650个testing，达到了8GB，而当我们从450个testing变为650个testing时，这个过程已经显着减慢了。
当我们在本地开发环境中运行所有的testing时，内存似乎至less被每个TestClass释放，并且永远不会超过一定的水平。 在当地的开发环境中，运行所有testing的过程并没有显着增加。
有没有一种方法来configuration构build服务释放与每个testing或每个TestClass内存？ 在目前正在运行的方式中，当我们开始在机器上耗尽内存时，构build过程变得非常缓慢。
编辑：我发现生成日志中的MSTest调用，并手动运行，看到失控的内存相同的行为。 我从MSTest的调用中删除了/ publish，/ publishbuild，/ teamproject，/ platform和/ flavor参数，以防testing运行器持续到结果，但行为没有改变。 我在开发箱上运行相同的命令行，与生成服务器分开，并且内存经常被释放。 似乎必须有一些错误/不同的build设服务器，使其行为有所不同，但我很难看的地方。
我已经看过qtagent.exe.config，mstest.exe.config，两个可执行文件的版本。 还有什么可能会影响这个？
我最终发现，在自动构build过程中，内存消耗如此之快的原因。 通过创buildQTAgent.exe转储，我们能够检查其内容，find.NET堆上的内容。 事实certificate，我们把大量的对象放到一个caching对象中，并且由于caching对象在整个过程中都存在，所有这些对象都是存活的垃圾收集。
我们testing中的程序逻辑会生成一些随机数据，然后检查数据是否是唯一的。 大部分情况应该是这样，但偶尔也会有碰撞。 如果发生碰撞，我们最终将caching以前的数据。 这不应该成为一个问题，因为我们的testing在数据完成后会清理数据，因此碰撞风险应该相对较低。
通过检查caching中的内容，我们发现我们必须遇到大量的冲突，事实certificate，由于一些不正确的configuration依赖关系，我们的清理逻辑仅在自动构build/testing环境中失败。 这意味着每次运行我们的testing时，我们都会生成更多未被清理的数据，并且随后的运行可能会在testing运行期间将数据加载到caching中。
我认识到，进行不完全孤立的testing是我们问题的一部分，但是我想提出一些其他的经验教训：
不是真的，问题是由testing代理对所有testing的结果持有的，所以它可以在最后更新日志。 我的build议是从Visual Studiotesting移动到另一个testing代理（如NUnit）。
这会让你感到头疼，但是你应该得到一个更清洁的解决scheme。