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.

[Andy]

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

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, true, but I do TDD and haven't had much issue recompiling. As I
said, it always takes me longer to code the change I wish to test than
to compile.

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.

Its been a while since I've done the little java I have; .classes are
the unit of deployment then?

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.

There are times I recompile frequently, if I'm making minor fixes to
code. It just doesn't seem to take that long for me. Perhaps this is
because I have a lot of focused assemblies though.

[Barry Kelly]

Andy wrote:

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

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.

Its been a while since I've done the little java I have; .classes are
the unit of deployment then?

Jar files (aka packages) are the usual unit of deployment. Jar files are
zips of the directory structure and a manifest file, with one directory
for each element on the namespace path, so e.g. the class
java.lang.Class is in java/lang/Class.class of rt.jar (rt = runtime
jar).

-- Barry

--
http://barrkel.blogspot.com/

[Jon Skeet [C# MVP]]

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

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.

It depends on what you mean by "a huge amount of time". To me, 10
seconds is enough to be a distraction.

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.

Right. Shame it's still VB.NET ;)

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.

Rarely, indeed.

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.

Well, that's effectively part of the cycle, possibly again due to the
way that .NET assemblies work (as well as due to the lack of tight
integration between VS and NUnit).

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.

I really don't mean to be patronising (and I know perfectly well how
patronising this sounds) but it's easy to say that something doesn't
have an effect if you've never been without it. I didn't realise quite
how useful closures could be until I started working in a language
which supported them really well.

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.

That doesn't mean it's actually being compiled - just error checked.
The important thing is whether or not it's constantly updating the
assemblies. What does it still need to do when you hit build?

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.

I'll have a look at what beta 1 does on my virtual PC.

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.

As I say, it's about 10 seconds on the solutions I'm working on at the
moment, and that's a lot longer than with a much bigger project in
Eclipse.

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.

Class libraries and forms, or class libraries and web services,
depending on the solution.

The fact that you're thinking of changing the design of your
application even *partly* due to compilation time means that it *is*
significant to you though.

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.

Possibly - depending on what it really does.

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.

It's lovely from what I've experienced - although I think it does make
the editor slightly less responsive. The trade-off is worth it for me.

--
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

[Jon Skeet [C# MVP]]

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

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

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, true, but I do TDD and haven't had much issue recompiling. As I
said, it always takes me longer to code the change I wish to test than
to compile.

Yes, it still takes me longer to write the code too - but the build
cycle is enough to be a distraction and an irritant.

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.

Its been a while since I've done the little java I have; .classes are
the unit of deployment then?

They can be. You *can* bundle them into jar files (and they're almost
always deployed that way) but you can equally not bother. Java can load
the classes just as well when they're each in a separate file as when
they're bundled together. This, unfortunately, means that there's no
equivalent of "internal" in Java.

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.

There are times I recompile frequently, if I'm making minor fixes to
code. It just doesn't seem to take that long for me. Perhaps this is
because I have a lot of focused assemblies though.

I think it depends on quite a few factors. Even just cycling through
the projects which have no changes seems to take longer than I'd expect
it to, to be honest.

--
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

[Jon Skeet [C# MVP]]

Barry Kelly <ba***********@ gmail.comwrote:

Its been a while since I've done the little java I have; .classes are
the unit of deployment then?

Jar files (aka packages) are the usual unit of deployment. Jar files are
zips of the directory structure and a manifest file, with one directory
for each element on the namespace path, so e.g. the class
java.lang.Class is in java/lang/Class.class of rt.jar (rt = runtime
jar).

They're the *usual* unit of deployment - but you don't need to perform
that step just to run the application or the unit tests. Being able to
only rewrite the few small files which represent classes which have
changed is (I suspect - I haven't actually checked any of this) part of
what makes incremental compilation work so well with Java.

--
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

[Barry Kelly]

Jon Skeet wrote:

Barry Kelly <ba***********@ gmail.comwrote:

Its been a while since I've done the little java I have; .classes are
the unit of deployment then?

Jar files (aka packages) are the usual unit of deployment. Jar files are
zips of the directory structure and a manifest file, with one directory
for each element on the namespace path, so e.g. the class
java.lang.Class is in java/lang/Class.class of rt.jar (rt = runtime
jar).

They're the *usual* unit of deployment

Sure - that's why I used the word 'usual', especially in the context of
'deployment' (as opposed to development). :)

I was just supplying information.

-- Barry

--
http://barrkel.blogspot.com/

[Jon Skeet [C# MVP]]

Barry Kelly <ba***********@ gmail.comwrote:

They're the *usual* unit of deployment

Sure - that's why I used the word 'usual', especially in the context of
'deployment' (as opposed to development). :)

I was just supplying information.

Sure - I was just trying to make it crystal clear that it wasn't the
only way that code could be run.

--
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 26, 12:58 pm, Jon Skeet [C# MVP] <[e-mail] wrote:

tjmadden1...@gm ail.com <tjmadden1...@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 - <[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

Right, it's not quite the same, but the concept of changing something
and running a test without building and deploying is the same. I
didn't use it much because it would pop up a dialog telling me the
replacement failed.

Can you elaborate on 'slightly different' in the first paragraph, and
'very different' in the second? The underlying workings are not even
close, but the concept seems similar to me.

Tim

[Jon Skeet [C# MVP]]

On Apr 27, 4:05 pm, "tjmadden1...@g mail.com" <tjmadden1...@g mail.com>
wrote:

Right, it's not quite the same, but the concept of changing something
and running a test without building and deploying is the same.

The difference is that running unit tests after incremental
compilation is basically running the tests from a clean start.
Changing the code while the app is still running and assuming that
your change wouldn't have had any consequences earlier in the app's
run is a lot riskier to me.

I didn't use it much because it would pop up a dialog telling me the
replacement failed.

That's the other problem, of course - not all changes can be done "on
the fly".

Can you elaborate on 'slightly different' in the first paragraph, and
'very different' in the second? The underlying workings are not even
close, but the concept seems similar to me.

To me it's a matter of repeatability and confidence. If I change
something based on a manual test run, I'll want to rerun the *whole*
test again after fixing it anyway, to make sure I haven't screwed
anything else up - so I might as well stop the application. The same
is true for unit tests, except they're designed to run so quickly that
you usually don't bother stopping a test run - just let it run and
fail, fix the bug, then rerun.

And as you say, the implementation of the two features is vastly
different - incremental compilation doesn't require any support from
the runtime itself, for starters.

Jon

[Andy]

On Apr 26, 4:17 pm, Jon Skeet [C# MVP] <[e-mail] wrote:

It depends on what you mean by "a huge amount of time". To me, 10
seconds is enough to be a distraction.

My builds typically take one second or less.

Well, that's effectively part of the cycle, possibly again due to the
way that .NET assemblies work (as well as due to the lack of tight
integration between VS and NUnit).

I'm not sure it has anything to do with lack of integration,
especially considering that after upgrading to Nunit 2.4 assembly
reload DOES take significantly longer (ie, more than 15 seconds). I
think its more a function of how Nunit is built.

I really don't mean to be patronising (and I know perfectly well how
patronising this sounds) but it's easy to say that something doesn't
have an effect if you've never been without it. I didn't realise quite
how useful closures could be until I started working in a language
which supported them really well.

I did have it before though. I've been only VS for a while now, but I
have done testing and used compilers that did incremental compilation.

That doesn't mean it's actually being compiled - just error checked.
The important thing is whether or not it's constantly updating the
assemblies. What does it still need to do when you hit build?

It would seem redundant to build in error checking rules into the IDE
that the compiler already has. I must admit I don't know enough about
it to answer your question because I'm not a vb.net guy, but from what
I've read it does seem to compile it (because you can change code
while the program is running and let it continue). From what I can
gather, it would seem pretty much the same as what Eclipse would do.

I'll have a look at what beta 1 does on my virtual PC.

As will I... if I ever get time.. I'm not 100% sure if its a planned
feature or not, its something I've seen around on newsgroups though.

As I say, it's about 10 seconds on the solutions I'm working on at the
moment, and that's a lot longer than with a much bigger project in
Eclipse.

Fair enough.. but by bigger do you mean more classes, more KLOC, etc?

Class libraries and forms, or class libraries and web services,
depending on the solution.

I typically keep solutions to the main project and its test project.

The fact that you're thinking of changing the design of your
application even *partly* due to compilation time means that it *is*
significant to you though.

No, its separated due to functional area. I have two (and more to
come) applications which do have overlap in use cases. I'm trying to
keep things separate so that each application only gets the
functionality it needs and doesn't reference an assembly and not use
90% of it. I also keep my logical tiers as separate physical tiers as
well.

It's lovely from what I've experienced - although I think it does make
the editor slightly less responsive. The trade-off is worth it for me.

I'll have to see if there's a trial version then. The designer can be
slower than I'd like, but the code editor is pretty snappy.