tags:

views:

149

answers:

5

I am a C#/.Net developer who just began Java development for Android, and using Eclipse I noticed that it compiles as you go, so that at no point do you have to wait for the program to build. This seems pretty amazing, unless there is something going on I don't understand.

I was wondering why C# and the Visual Studio IDE don't provide this functionality? Is there a reason?

+6  A: 

In Java each class is compiled into a separate class file so it's very easy to compile small units of code on each save. In .net you compile a bunch of classes into a single DLL, which is slower and requires more logic in the compilation process.

BTW, this is not a language feature, it's an IDE feature. Not all java IDEs do auto-compile and you can also disable it in eclipse if you like. And I am sure there are auto-build tools for Visual Studio..

Nir Levy
Also, java does not require linking against runtime libraries, which I think C# does (but I am no C# expert)
Nir Levy
A good auto-building tool, which doesn't actually build but it can check your project for errors before you build, saving precious time, is Resharper.
Richard J. Ross III
Don't forget, VB does have this feature. C# does not, nor is adding it a popular request from C# devs. The IDE does parse as you go, which is good enough to catch most errors. Also, the IDE caches previous builds and only has to rebuild what changed on subsequent builds afterwards. In general, fully compiling C# as you go would be a performance drag, but doesn't add much additional value.
Stephen M. Redd
Thanks for your help. Jorg contributed a very thorough answer, so I figured I better mark his as the answer.
JimDaniel
A: 

Autobuilding anything other than the most trivial application would incur massive delays as it compiled and linked every time you press a key.

VS does have intellisense and a lot of on-the-fly syntax and sanity checking which gives you most of the advantages of autobuild without the delays. (having said that it appears to be annoyingly enthusiastic in VS2010...)

FixerMark
A: 

Not an auto-builder, I know, but using telerik's JustCode is a product that goes well beyond the VS on-the-fly syntax checking by providing solution wide code analysis. I don't imagine that I'm the only developer in the world that used to use an attempt to build as a way of checking that I'd included all the things I needed to to get my code to build. With JustCode, you get a lot of visual help with this kind of thing without having to wait for the compiler to tell you you've missed something.

Stuart Hemming
+5  A: 

This doesn't really have anything to do with Java. It's more a feature of Eclipse. In particular, incremental background compilation is a standard feature of all Smalltalk IDEs since at least 1978 or thereabouts, and even longer than that in Lisp IDEs.

Eclipse was originally a Smalltalk IDE, written in Smalltalk, and it is still to this day maintained by IBM's Smalltalk division. So, when IBM's Smalltalk division developed their own Java compiler, they naturally wrote it to be incremental and re-entrant, just like their Smalltalk compilers. And this compiler, called Jikes was open-sourced together with Eclipse and became the ecj (Eclipse Compiler for Java) that powers all of the incremental on-the-fly compilation, syntax highlighting, code completion, type inference and refactoring capabilities of Eclipse JDT.

There is absolutely no reason why this shouldn't be possible for C# as well. The reason why it doesn't work, is because the compiler doesn't support it, in particular, the compiler is not incremental. But that is not an inherent limitation of .NET or C# or Visual Studio, that's a limitation in the imagination of the C# compiler maintainers: traditionally, all compilers at Microsoft were written in C++ by the C++ compiler team, and those guys simply have never heard of incremental compilation. Not because they are stupid, but because in the C++ community nobody cares about that.

But, for example, the VB community does care about that stuff, because they are used to it from VB Classic. So, the VB.NET compiler actually supports incremental building, edit-and-continue, IntelliSense, type inference and refactoring.

Of course, the C# plugin supports a lot of that stuff, too, but they don't use the actual C# compiler to do that. Instead, they basically had to re-implement half of the compiler for the Visual Studio plugin to work, but they didn't implement the actual code generation backend, so while the "compiler" which is part of the plugin can do incremental parsing, syntax highlighting, refactoring and edit-and-continue, it cannot actually, you know, compile.

The situation for C# is going to change, however: the responsibility for the compilers was reassigned to the respective language teams, and the C# team is currently in the process of re-implementing the compiler in C# and within the C# team. One of the often talked about results of this rewrite is going to be the Compiler-as-a-Service feature, which allows you to compile small snippets of C# and/or Expression Trees on-the-fly and which powers for example the also often demonstrated C# REPL and C# Scripting capabilities.

Given that in order for the REPL to work, the compiler needs to be able to compile small individual snippets of code anyway, and the new compiler is supposed to be used in the Visual Studio C# plugin to replace the current pile of IntelliSense and syntax highlighting hacks, it shouldn't be too hard to get incremental compilation going in Visual Studio.

Jörg W Mittag
Great answer, thank you.
JimDaniel
+1  A: 

Resharper a pluging for VS gives you compilation errors on the fly but not an auto builder

Rony