Why doesn't C# allow incremental compilation like Java?

[mwelsh1118]

Why doesn't C# allow incremental compilation like Java?

Specifically, in Java I can compile single .java files in isolation.
The resulting individual .class files can be grouped into .jar files.

In C#, there appears to be no analog. I have to compile all my .cs
files into a single .dll.

This has serious drawbacks in terms of compilation. With Eclipse, I
change a file and only that file is re-compiled. With Visual Studio, I
change a file and have to manually re-compile, which may take 10+
seconds for large projects (even if all I did was add a space to a
comment).

Why was this design decision made? And is there any way to speed up
Visual Studio 2005 C# compilation? Are there plans to have background
compilation in future versions of Visual Studio?

Thanks.

[Jon Skeet [C# MVP]]

Ravichandran J.V. <jv************ @yahoo.comwrote :

VS, incidentally, happened to be the first ide to provide for
incremental build/compilation.

Do you have a reference for that, out of interest? I'm sure it was long
before Java and .NET were on the scene, but it would be interesting to
know the history of incremental compilation.

It is still considered the more robust,
despite the many fans of Eclipse, ide doing the rounds.

Considered more robust by who, exactly? You may consider it more
robust, I consider it less robust (and less useful) - just two
opinions. Or do you have a decent poll available? Note that a lot of
people will say that one IDE is better than another without even using
both, unfortunately. (I try to avoid comparisons with JetBrains' IDEA,
not having used it much - but I've heard *great* things abobut it.)

Here is a comparison. I have personally sat through two hours of
distributed build using Xcode! This build targeted the Mac, with the UB
as the output. The same lines of code in VS (2003) took just under 30
minutes for the Windows platform.

What has that got to do with Eclipse's performance?

To cite Eclipse' performance, Eclipse is a far lighter software than VS
and hence, it can show up faster performance.

Far lighter? In what way? It doesn't have a load of designers etc out
of the box - but it *does* have more features in the text editor than
VS does, even in 2005. It had refactoring *ages* before VS did, along
with built-in unit testing, better source control support etc.

If you want designers, there are plenty of plugins available...

True, on Vs 2005, I seemed to *feel* the lack of speed compared to VS
2005 as you would if you use Word 2007 and save a file. It takes
considerably longer time in 2007 than 2003.

There's no question of "feeling" in this case. Saving/compiling on
Eclipse usually takes well under a second. Recompiling even a
relatively small solution in VS.NET can easily take 15 seconds.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Chris Nahr]

On Tue, 24 Apr 2007 07:33:12 +0100, Jon Skeet [C# MVP]
<sk***@pobox.co mwrote:

>There's no question of "feeling" in this case. Saving/compiling on
Eclipse usually takes well under a second. Recompiling even a
relatively small solution in VS.NET can easily take 15 seconds.

It's hard to compare build times without knowing how big a solution
is, but if even a "relatively small" solution takes 15 seconds to
build on your machine... you really should get rid of that old 486! :)

Building close to 50,000 lines of C# code (pure code lines, excluding
empty lines and comments, as per DPack solution statistics) spread
across 9 assemblies takes less than six seconds on my system, after
warming up. There are also over 50,000 lines of XML comments being
syntax-checked and extracted to XML files during compilation. That's
the full build which only occurs if I change a file in the assembly at
the root of the dependency tree; compiling a leaf assembly with about
7,000 code lines takes less than two seconds.

That's on a Core 2 Duo E6600 system with 3 GB RAM and a 10,000 RPM
SCSI-160 drive which admittedly is pretty powerful, but build times
were still only around 10 seconds with my old P4 3.2 GHz system.

Now that doesn't excuse VS2005 being much slower than Eclipse but it's
not a delay that would ever prevent me from building while coding.
Unless of course you'd qualify a combined 100,000 non-empty line count
as a "relatively tiny" solution, and yours has a few million lines. :)
--
http://www.kynosarges.de

[Andy]

On Apr 23, 2:27 am, Jon Skeet [C# MVP] <[e-mail] wrote:

I find it hard to believe that build time should really be a problem.

I find it a problem - at least compared with using Eclipse in Java.
That builds every time you save, and has a sufficiently nippy
incremental compiler that it encourages you to save (and therefore
compile) often. I find this very helpful compared with the VS model,
where you can't build as often because the build takes significantly
longer. (Even if it's only 15 seconds, that's reasonably significant.)

I think you're in a minority then. Personally, I'm not compiling
after every single change I make to a single file. I work in multiple
files to get a unit of work done, and compile that. Even still, my
library assemblies don't take anywhere near 15 seconds, although my UI
assembly with lots of forms takes about that long..

Part of that is due to assemblies being single files (which is
brilliant in many other ways) but I suspect VS could still do a better
job at incremental compilation. It would probably have to have its own
compiler (just as VS does for Java) which makes life trickier though. I
occasionally run into problems where Eclipse's internal compiler is
pickier than the JDK or vice versa.

VS assumes you want to build the entire project. There really isn't
much of a point in building a single file; you can't do anything with
the result of that, except to link it either other modules to form the
assembly. VS 2005 doesn't suffer the problems you mention for
esclipse, because it uses the same compiler that you would outside the
IDE (MSbuild, which in turn uses csc). Assemblies in .Net don't
contain self contained classes; usually the classes depend on each
other, and i imagine that's the case in java as well.

If you want maximum control over the build, then use NAnt.

That doesn't help the development time though.

Then stop compiling every change to a file. Why would you even bother
recompiling after putting some whitespace into a comment?

[Andy]

On Apr 23, 3:30 pm, Jon Skeet [C# MVP] <[e-mail] wrote:

Paul Werkowitz <newsgro...@pri maprogramm.dewr ote:
You don't *have* to create jar files in order to run the code - and you
don't *have* to run the code to benefit from compilation.

But you still can't run without the other files compiled, am I right?

Using Eclipse, I know that when I save, *all* compile-time errors will
be displayed, and very quickly. I know that these days IDEs tend to
display errors as you type, but I don't believe they find *all* errors
that way (at least in C# - VB.NET may be different).

I suggest moving to Vb.Ne then, as you will have that feature there,
although I must say this doesn't really come up much because of
Intellisense.

Further, I can then run unit tests or even run the app in the debugger
without packaging it into jar files. I tend to run the unit tests far
more often than I package the code up.

Does it make sense to run a test when some of the modules may not have
been built?

When a compile/launch unit tests/check results cycle is seconds rather
than half a minute, it encourages TDD far more.

How? What is the point of testing each single line change? Running
tests too often is just a waste of time. Most of the changes I need
to make are not trivial that I can code it in a few seconds and then
be ready to test it. The coding takes far longer than the compilation
time.

However, I suspect it still doesn't do the incremental compilation as
well as Eclipse does. At least, I haven't seen any evidence of that -
and of course it's a complete pain to set that up for every file.

So what? Again, if its that important to you, go to Vb.Net. Vb.Net
supports background compilation.

The size of the compilation unit is irrelevant if VS is recompiling all
the files. The question is whether it does - but as the C# compiler had
the /incremental option removed for VS2005, I suspect that it *does*
recompile all files, at least in projects where it's detected there are
changes (and possibly all dependent projects).

Thats not true at all. The more files you have, and the more code in
them, the longer it will take to compile. Dependant projects need to
be recompiled when their dependancy changes. Perhaps you are stuffing
too much into one assembly, or you simply have a slow machine.

Certainly my experience is that building with VS.NET is *considerably*
slower than building comparably sized projects in Eclipse.

So what?

[Jon Skeet [C# MVP]]

On Apr 24, 2:01 pm, Andy <[e-mail] rote:

Paul Werkowitz <newsgro...@pri maprogramm.dewr ote:
You don't *have* to create jar files in order to run the code - and you
don't *have* to run the code to benefit from compilation.

But you still can't run without the other files compiled, am I right?

The point is that by keeping each class in its own file, you only need
to touch the files which have changed and any dependencies. You don't
need to rebuild the larger jar files - whereas you *do* have to build
the full assembly in .NET. (Yes, using modules would help this, but
it's a pain.)

Using Eclipse, I know that when I save, *all* compile-time errors will
be displayed, and very quickly. I know that these days IDEs tend to
display errors as you type, but I don't believe they find *all* errors
that way (at least in C# - VB.NET may be different).

I suggest moving to Vb.Ne then, as you will have that feature there,
although I must say this doesn't really come up much because of
Intellisense.

I gather it slows things down significantly with larger projects
though - or at least did at one point. Either way, there's a
psychological difference between "I'll trust that the as-you-type
compiler has spotted all the errors" and "The code is actually built
and can be run, and I have no errors".

Further, I can then run unit tests or even run the app in the debugger
without packaging it into jar files. I tend to run the unit tests far
more often than I package the code up.

Does it make sense to run a test when some of the modules may not have
been built?

Everything *will* have been built though. That's the point - it's
incremental.
(Actually, Eclipse will let you run code even if you've still got
compilation errors - you'll get a runtime error when you enter the
method or type that failed to compile. It warns you on launch, of
course.)

When a compile/launch unit tests/check results cycle is seconds rather
than half a minute, it encourages TDD far more.

How? What is the point of testing each single line change? Running
tests too often is just a waste of time. Most of the changes I need
to make are not trivial that I can code it in a few seconds and then
be ready to test it. The coding takes far longer than the compilation
time.

I don't necessarily test every single line change, but I try to test
every functional change - and rerunning the unit tests very frequently
helps with that.

TDD is all about making small changes and making sure they work. If
you're not a TDD fan, fine - but please don't assume that just because
a relatively slow compile cycle doesn't hurt *your* productivity, it
doesn't hurt that of other people.

However, I suspect it still doesn't do the incremental compilation as
well as Eclipse does. At least, I haven't seen any evidence of that -
and of course it's a complete pain to set that up for every file.

So what? Again, if its that important to you, go to Vb.Net. Vb.Net
supports background compilation.

Actual background compilation, or just background error checking?
There's a big difference between the two. (Besides, I far prefer the
C# language to VB.NET.)

The size of the compilation unit is irrelevant if VS is recompiling all
the files. The question is whether it does - but as the C# compiler had
the /incremental option removed for VS2005, I suspect that it *does*
recompile all files, at least in projects where it's detected there are
changes (and possibly all dependent projects).

Thats not true at all. The more files you have, and the more code in
them, the longer it will take to compile.

That's because it's not an incremental compiler, as I say. In Eclipse,
if I change one method, even in a *giant* class, IIRC only that method
will actually be recompiled (and the whole class file regenerated). If
I change the method signature, other things which depend on it will be
recompiled. It doesn't need to recompile whole projects - only
dependencies.

Dependant projects need to
be recompiled when their dependancy changes. Perhaps you are stuffing
too much into one assembly, or you simply have a slow machine.

My machine is reasonably nippy, but it still takes 10 seconds to
compile the solution I'm largely working with at the moment.

Certainly my experience is that building with VS.NET is *considerably*
slower than building comparably sized projects in Eclipse.

So what?

So it's a pain in the neck, particularly for TDD developers. Have you
used Eclipse for significant projects? It's sometimes hard to
appreciate what a difference such features can make without having
experienced them for yourself.

I often talk about features like "Open Type" in Eclipse, and people
who haven't used Eclipse say they can easily live without it. I
haven't yet met anyone who *has* used Eclipse for significant periods
who doesn't agree that it would be a *huge* benefit to have in VS2005.
(Fortunately, ReSharper provides it. Shame it's not in VS itself
though.)

Jon

[Jon Skeet [C# MVP]]

Andy <an***@med-associates.comw rote:

I find it a problem - at least compared with using Eclipse in Java.
That builds every time you save, and has a sufficiently nippy
incremental compiler that it encourages you to save (and therefore
compile) often. I find this very helpful compared with the VS model,
where you can't build as often because the build takes significantly
longer. (Even if it's only 15 seconds, that's reasonably significant.)

I think you're in a minority then. Personally, I'm not compiling
after every single change I make to a single file. I work in multiple
files to get a unit of work done, and compile that. Even still, my
library assemblies don't take anywhere near 15 seconds, although my UI
assembly with lots of forms takes about that long..

I suspect I'm in the minority because most people don't practise TDD,
and most people don't realise how lovely it is not to have to wait for
a compiler.

Part of that is due to assemblies being single files (which is
brilliant in many other ways) but I suspect VS could still do a better
job at incremental compilation. It would probably have to have its own
compiler (just as VS does for Java) which makes life trickier though. I
occasionally run into problems where Eclipse's internal compiler is
pickier than the JDK or vice versa.

VS assumes you want to build the entire project. There really isn't
much of a point in building a single file; you can't do anything with
the result of that, except to link it either other modules to form the
assembly. VS 2005 doesn't suffer the problems you mention for
esclipse, because it uses the same compiler that you would outside the
IDE (MSbuild, which in turn uses csc).

Indeed - although I should stress that it's only been an issue on a
couple of occasions, and of course we run the unit tests on the JDK-
built classes as well, when we build the jar files.

Assemblies in .Net don't
contain self contained classes; usually the classes depend on each
other, and i imagine that's the case in java as well.

You've misunderstood what Eclipse does. When the save has finished, all
the classes have been compiled. However, they're still individual class
files (which makes them easy to write individually, of course). They
can still be run in that form - that's the difference between .NET and
Java. In Java although you *can* bundle classes together, you don't
have to.

If you want maximum control over the build, then use NAnt.

That doesn't help the development time though.

Then stop compiling every change to a file. Why would you even bother
recompiling after putting some whitespace into a comment?

I don't think I ever suggested that I'd recompile after changes quite
that minor (although as it's so cheap, you might as well save, and that
happens to compile). I still recompile very often (in Eclipse) though -
partly because of TDD, and partly because it just gives a warm fuzzy
feeling to *know* that you've got no compilation errors, because
everything *has* been compiled.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[tjmadden1128]

On Apr 24, 10:49 am, Jon Skeet [C# MVP] <[e-mail] wrote:

I think you're in a minority then. Personally, I'm not compiling
after every single change I make to a single file. I work in multiple
files to get a unit of work done, and compile that. Even still, my
library assemblies don't take anywhere near 15 seconds, although my UI
assembly with lots of forms takes about that long..

I suspect I'm in the minority because most people don't practise TDD,
and most people don't realise how lovely it is not to have to wait for
a compiler.

Well, you're not a minority of one, anyway. I have come to enjoy
automatic compile.
We don't practice TDD where I work, unfortunately, but I like being
able to launch
the GUI, test, and make changes, and test without having to relaunch
the GUI (and
login again, go to the proper spot, find the correct data, ad nausem).
I was rebuilding
the project when I first started, then a coworker pointed out I didn't
need to.

---snip---

--
Jon Skeet - <[e-mail] >http://www.pobox.com/~skeet Blog:http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

Tim Madden

[tjmadden1128]

On Apr 24, 12:33 am, Jon Skeet [C# MVP] <[e-mail] wrote:

Ravichandran J.V. <jvravichand... @yahoo.comwrote :

VS, incidentally, happened to be the first ide to provide for
incremental build/compilation.

Do you have a reference for that, out of interest? I'm sure it was long
before Java and .NET were on the scene, but it would be interesting to
know the history of incremental compilation.

I don't have a reference, but 'Edit and Continue' mode was in VS 6.
--snip--

True, on Vs 2005, I seemed to *feel* the lack of speed compared to VS
2005 as you would if you use Word 2007 and save a file. It takes
considerably longer time in 2007 than 2003.

There's no question of "feeling" in this case. Saving/compiling on
Eclipse usually takes well under a second. Recompiling even a
relatively small solution in VS.NET can easily take 15 seconds.

Mine are usually 5-10 seconds, but if you use TDD even that gets old
fast.

--
Jon Skeet - <[e-mail] >http://www.pobox.com/~skeet Blog:http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

Tim Madden

[Jon Skeet [C# MVP]]

tj**********@gm ail.com <tj**********@g mail.comwrote:

On Apr 24, 10:49 am, Jon Skeet [C# MVP] <[e-mail] wrote:

I think you're in a minority then. Personally, I'm not compiling
after every single change I make to a single file. I work in multiple
files to get a unit of work done, and compile that. Even still, my
library assemblies don't take anywhere near 15 seconds, although my UI
assembly with lots of forms takes about that long..

I suspect I'm in the minority because most people don't practise TDD,
and most people don't realise how lovely it is not to have to wait for
a compiler.

Well, you're not a minority of one, anyway. I have come to enjoy
automatic compile.
We don't practice TDD where I work, unfortunately, but I like being
able to launch the GUI, test, and make changes, and test without having
to relaunch the GUI (and login again, go to the proper spot, find the
correct data, ad nausem). I was rebuilding
the project when I first started, then a coworker pointed out I didn't
need to.

That's a slightly different feature - edit and continue - which I'm
actually *not* so keen on. (I believe it encourages a "tinker until it
looks like it works" approach, which doesn't prove that it would have
worked if you'd started from scratch. Unit testing gives a better
solution to this IMO. Edit and continue is useful for getting UIs to
look right though, I'll readily admit that.)

Edit and continue is a very different feature to incremental
compilation - it's perfectly possible to have incremental compilation
without E&C, although I guess the other way round is pretty tricky.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Andy]

On Apr 24, 12:04 pm, "Jon Skeet [C# MVP]" <[e-mail] wrote:

The point is that by keeping each class in its own file, you only need
to touch the files which have changed and any dependencies. You don't
need to rebuild the larger jar files - whereas you *do* have to build
the full assembly in .NET. (Yes, using modules would help this, but
it's a pain.)

Ok, but I haven't had .Net project compiles take a huge amount of
time.

I gather it slows things down significantly with larger projects
though - or at least did at one point. Either way, there's a
psychological difference between "I'll trust that the as-you-type
compiler has spotted all the errors" and "The code is actually built
and can be run, and I have no errors".

Are you talking about intellisense or the Vb.Net background compiler?
The former seems to eliminate 99% of compile errors to me. I haven't
used the latter, but I understand it DOES compile using vbc as you
type.

Everything *will* have been built though. That's the point - it's
incremental.
(Actually, Eclipse will let you run code even if you've still got
compilation errors - you'll get a runtime error when you enter the
method or type that failed to compile. It warns you on launch, of
course.)

I see. I'm not sure that running a program even with compile errors
is useful though.

I don't necessarily test every single line change, but I try to test
every functional change - and rerunning the unit tests very frequently
helps with that.

As do I. I typically have to wait longer for NUnit to reload the
assemblies than I do for the compiler though.

TDD is all about making small changes and making sure they work. If
you're not a TDD fan, fine - but please don't assume that just because
a relatively slow compile cycle doesn't hurt *your* productivity, it
doesn't hurt that of other people.

Actually I do like TDD; its just that VS lacking background /
incremental hasn't made an impact on how often I can test.

Actual background compilation, or just background error checking?
There's a big difference between the two. (Besides, I far prefer the
C# language to VB.NET.)

>From what I understand, actual background compilation, as many

Vb.Netters complain that things like invalid casts aren't caught in C#
until they compile, but Vb.Net catches all these errors almost
immediately. I can't fault you for perfering C# over Vb though. :-)
FWIW, I have heard that the Orcas will support C# background
compilation ala Vb.Net.

That's because it's not an incremental compiler, as I say. In Eclipse,
if I change one method, even in a *giant* class, IIRC only that method
will actually be recompiled (and the whole class file regenerated). If
I change the method signature, other things which depend on it will be
recompiled. It doesn't need to recompile whole projects - only
dependencies.

Understood, but again, I haven't seen many places where compiling
takes all that long at all. 1 - 2 seconds is typical, except for my
forms application, but that's also adding in resources and such.

My machine is reasonably nippy, but it still takes 10 seconds to
compile the solution I'm largely working with at the moment.

A forms application or straight class library? My forms application
takes a bit of time, mostly because of all the resources which get
embedded. Of course I'm planning on moving most of the forms to
library assemblies though, both to speed project compile time and
speed the loading of my application.

So it's a pain in the neck, particularly for TDD developers. Have you
used Eclipse for significant projects? It's sometimes hard to
appreciate what a difference such features can make without having
experienced them for yourself.

I haven't noticed a problem in the teams I've been in (solo now
though). I haven't used Eclipse, but I have used IDEs which do
incremental compiling. If the Orcas will have background compilation
for C# as I've heard, I guess I'll see then if it makes a difference.

I often talk about features like "Open Type" in Eclipse, and people
who haven't used Eclipse say they can easily live without it. I
haven't yet met anyone who *has* used Eclipse for significant periods
who doesn't agree that it would be a *huge* benefit to have in VS2005.
(Fortunately, ReSharper provides it. Shame it's not in VS itself
though.)

I haven't used resharper yet, although I understand how much of a
benefit that functionality will provide. I'm hoping to purchase
Resharper soon.