.net TFS以静默方式修复.sln文件-有办法停止吗？

想象一下以下场景：

Solution1.sln

包含项目

A

、

B

和

C

。（.NET 4.0，C#）

Solution2.sln

包含项目

A

、

B

和

D

。（.NET 4.0，C#）

在

Solution2.sln中工作的开发人员在
B
中添加了对
D
的引用。显然，
Solution1.sln
不再编译了，因为它不包含
D
（测试了VS2010、VS2013和独立的MSBuild，只是为了确保这一点）

“问题”在于夜间构建运行的
Solution1.sln
工作正常，令人惊讶。当我查看构建服务器上的
.sln
文件时，我看到它被修改为添加缺少的项目

一开始这看起来是一个不错的特性，但我更愿意知道解决方案已经失败，而不是让构建神奇地工作

有没有办法在TFS2013中关闭此功能？我很肯定这不会发生在TFS2010中，但我不能说是TFS2012。
解决方案只是一组项目，仅此而已

当MSBuild在解决方案上工作时，它会计算生成顺序，分析项目和二进制引用——此过程在Visual Studio和Team build（即TFS）中是相同的。对于项目引用，它根据生成输出确定项目是否应重新生成。只要MSBuild能够解析文件系统上的引用，一切都很好

您将在VisualStudio中看到相同的行为：您只得到一个警告，但构建成功

Team Build为所有生成输出使用一个目录，因此您用于生成解决方案的顺序也会影响二进制引用。
不应该这样做。您确定在生成框中修改了sln文件吗？您能否在服务器上打开sln文件以检查引用指向何处？@AdarshShah.sln的“修改日期”比所有其他文件晚一分钟，这些文件可追溯到生成工作流的“获取工作区”部分。也许我应该提到缺少的项目在工作区中，而不是在解决方案中。生成服务器上的
.sln
文件包含对正确项目的引用。它是项目引用还是程序集引用？它是与其他项目和解决方案位于同一目录的项目。我想它可以使用它的GUID找到正确的项目。这是项目引用还是程序集引用？正如我在问题中提到的，在VS和独立MSBuild中生成失败。我没有得到任何警告。。。是否有任何设置需要更改以获得您提到的行为？我使用VS 2013.1进行了测试，因此MSBuild 12可能有不同的行为，但我不这么认为。也许在您的配置中缺少了一些导致您出现问题的东西。