当我编译这个项目时，它在错误列表窗口中显示400多个错误，然后我转到错误站点，修复一些，数字会说120多个错误，然后在修复一些之后，接下来再次编译400多个报告。我可以看到错误列表窗口中出现了不同的文件，所以我认为编译器在发生一定数量的错误后会中止？
如果是这样，原因是什么？它是否应该收集项目中存在的所有错误，即使它们超过10K +？
答案 0 :(得分：10)
我一直想写一篇关于此的博客文章。
您可能只是因为报告的错误数量而遇到了一些硬编码限制。你也可能遇到一个更微妙和有趣的场景。
命令行编译器和IDE编译器中有许多试图管理错误报告的启发式方法。两者都是为了让用户可以管理，并使编译器更加健壮。
简而言之，编译器的工作方式是它试图让程序通过一系列阶段，你可以在这里阅读：
http://blogs.msdn.com/b/ericlippert/archive/2010/02/04/how-many-passes.aspx
这个想法是，如果早期阶段出现错误，我们可能无法在没有（1）进入无限循环，（2）崩溃或（3）报告疯狂“级联”的情况下成功完成后续阶段错误。所以会发生什么，你得到一个错误，你修复它，然后突然下一个编译阶段可以运行，它会发现更多的错误。
基本上，如果程序如此混乱以至于我们甚至无法验证有关其类和方法的基本事实，那么我们就无法可靠地为方法体提供错误。如果我们无法分析lambda体，那么我们就无法可靠地为其转换为表达式树提供错误。等等;在很多情况下，后期阶段需要知道前面的阶段完成没有错误。
这个设计的好处是（1）你得到的错误是最“基本”的，没有很多嘈杂，疯狂的级联错误，以及（2）编译器更强大，因为它没有'我必须尝试对语言的基本不变量被破坏的程序进行分析。缺点当然是你的情况：你有50个错误，你修复它们，突然又出现了50个错误。
答案 1 :(得分：6)
当然它会在某个时刻停止。
即使在1次错误之后，所有其余的都充其量是可疑的。编译器将尝试恢复，但不能保证成功。
因此，在任何非平凡的项目中，在第一个错误（理论上最好的事情）停止并且在不可靠的状态下耕作之间，这是一个实际的决定。
最正确的操作是在1次错误后停止，但这会导致繁琐的“一次修复1”情况。因此编译器会尝试重新同步到已知状态并报告下一个状态。但是错误可能会导致跟随它的正确代码出现错误错误，所以在某些时候它会停止合理。
参考你自己的情况：经过一些修复后，400+会变为120。
答案 2 :(得分：1)
可根据MSDN
进行配置默认情况下，最大数量为200个错误和警告。