我想知道为什么C#和Visual Studio IDE没有提供这种功能?是否有原因?
这与Java实际上没有什么关系,而更多的是Eclipse的特性。特别地,增量后台编译自1978年左右就成为所有Smalltalk IDE的标准功能,甚至在Lisp IDE中也比那更早。
Eclipse最初是一个用Smalltalk编写的Smalltalk IDE,并且至今仍由IBM的Smalltalk部门维护。因此,当IBM的Smalltalk部门开发了自己的Java编译器时,他们自然而然地将其编写为增量和可重入的,就像他们的Smalltalk编译器一样。而这个编译器被称为Jikes,它与Eclipse一起成为“ecj(Eclipse Compiler for Java)”,为Eclipse JDT的所有增量即时编译、语法高亮、代码完成、类型推断和重构功能提供动力。
同样,C#也完全可以实现这一点。它“不能”工作的原因是因为编译器不支持它,特别是编译器不是增量式的。但这并不是.NET、C#或Visual Studio的固有限制,而是C#编译器维护人员想象力的限制:传统上,微软的所有编译器都是由C++编译器团队用C++编写的,而这些人从来没有听说过增量编译。这并不是因为他们愚蠢,而是因为在C++社区中没有人关心这个问题。
但是,例如,VB社区确实关心这些东西,因为他们从VB Classic中习惯了它。因此,VB.NET编译器实际上支持增量构建、编辑和继续、IntelliSense、类型推断和重构。
当然,C#插件也支持许多这样的功能,但它们并没有使用实际的C#编译器来实现。相反,他们基本上不得不重新实现了半个编译器才能让Visual Studio插件正常工作,但是他们没有实现实际的代码生成后端,因此虽然插件中的“编译器”可以进行增量解析、语法高亮、重构和编辑并继续等操作,但它实际上无法编译。
然而,对于C#来说,情况将会改变:编译器的责任被重新分配给了各自的语言团队,C#团队目前正在重新实现编译器,并且在C#团队内部进行。这次重写所带来的一个经常谈论的结果之一将是Compiler-as-a-Service(编译器即服务)功能,它允许您即时编译小段的C#代码和/或表达式树,为例如C# REPL和C#脚本功能提供动力。
鉴于为使REPL工作,编译器需要能够编译小段的单独代码,同时新编译器将被用于替换当前的IntelliSense和语法高亮黑客技术以使其在Visual Studio中运行,所以在Visual Studio中实现增量编译也不应该太难。
Resharper是一个用于VS的插件,它可以在编译时即时检测错误,但不具备自动构建功能。
除了最简单的应用程序外,任何自动构建都会带来巨大的延迟,因为每次按键都需要编译和链接。
VS确实具有智能感知和许多即时语法和合理性检查,这使您获得了大部分的自动构建优势而无需等待。(话虽如此,在VS2010中似乎过于热情惹人厌烦...)