为什么在TrackFileAccess关闭时仍会发生Tracker.exe响应文件错误？

Question

我正在使用TFS 2010并尝试在两台Windows Server 2008（x86）构建计算机上构建一个.NET 2.0项目。构建机器安装了.NET版本1.0,1.1,2.0,3.0,3.5,4.0和Windows SDK 7.0A（以及TFS 2010和Visual Studio 2010）。

由于本周一些看似微小的重构更改，现在项目构建总是标记为部分成功：虽然编译完成没有错误，但TFS遇到七个Tracker.exe错误。例如，在构建摘要中，将显示以下报告：

Other Errors and Warnings
7 error(s), 0 warning(s)
Tracker.exe: Response file C:\Users\Builder\AppData\Local\Temp\5647f0a8ac7a4d53b87a8c2ebca3c4f5.rsp not found.
Tracker.exe: Response file C:\Users\Builder\AppData\Local\Temp\5647f0a8ac7a4d53b87a8c2ebca3c4f5.rsp not found.
Tracker.exe: Response file C:\Users\Builder\AppData\Local\Temp\5647f0a8ac7a4d53b87a8c2ebca3c4f5.rsp not found.
Tracker.exe: Response file C:\Users\Builder\AppData\Local\Temp\5647f0a8ac7a4d53b87a8c2ebca3c4f5.rsp not found.
Tracker.exe: Response file C:\Users\Builder\AppData\Local\Temp\5647f0a8ac7a4d53b87a8c2ebca3c4f5.rsp not found.
Tracker.exe: Response file C:\Users\Builder\AppData\Local\Temp\5647f0a8ac7a4d53b87a8c2ebca3c4f5.rsp not found.
Tracker.exe: Response file C:\Users\Builder\AppData\Local\Temp\5647f0a8ac7a4d53b87a8c2ebca3c4f5.rsp not found.

Tracker.exe错误的常规修复是通过将/p:TrackFileAccess=false传递给MSBuild或将TrackFileAccess=false添加到MSBuild项目中的配置设置来禁用增量构建。过去，这一直是修复Tracker.exe的问题。

但是，这次Tracker.exe仍然出现错误，即使在关闭TrackFileAccess后不再需要跟踪更改也是如此。我甚至在构建机器上重命名C:\Program Files\Microsoft SDKs\Windows\v7.0A\bin\NETFX 4.0 Tools\Tracker.exe - 并且仍然发生了错误（我原以为错误地说无法找到Tracker.exe）。

这可能会发生什么？我在构建机器的文件系统中搜索了Tracker.exe的其他副本。是否可以覆盖构建定义或MSBuild项目设置？谢谢！

Answer 1

您声明您已经重命名了构建服务器的唯一“Tracker.exe”实例，但构建完全没有受到影响。
实际构建是否可以在另一台计算机上进行（构建代理），TFS 2010构建拓扑很有可能：


确定实际构建发生位置的服务器的一种简单方法是检查构建日志，希望其中包含verbosity = diagnostic。打开“查看日志”并搜索“在代理上运行”。你应该得到像Run On Agent (reserved build agent <agentName> - <serverName>)这样的东西。显然<serverName>就是这一切发生的地方。

关于你的关注这可能是一个构建定义或MSBuild项目设置被覆盖？：再次，你最好选择检查构建日志。搜索MSBuild Log File，这会将您发送到跟踪实际MSBuild callup的区域。

Answer 2

这在某种程度上与WiX有关吗？我只在我的发布版本中获得这些。 this is your msdn link?

Answer 3

在我的情况下，这是由向现有程序集添加数据库项目（项目GUID {00D1A9C2-B5F0-4AF3-8072-F6C62B433612}）dll引用引起的。删除此引用（我只是用它来强制在测试时重建db脚本）解决了这个问题。