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.

[Nicholas Paldino [.NET/C# MVP]]

That's not true, really. You could compile into individual netmodules
(using the /target:module switch) and then assemble them into an assembly
using the assembly linker tool (al.exe).

You should be able to configure VS.NET 2005 to output a module by
changing the project file (specifically, the inputs to the csc task).

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard. caspershouse.co m

<mw********@gma il.comwrote in message
news:11******** ************@b7 5g2000hsg.googl egroups.com...

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.

[mwelsh1118]

I've looked into that, but it's not possible to do within Visual
Studio (it always compiles projects to dll's). Regardless, it still
makes the project the minimum unit of compilation. It seems like
ideally the time it takes to re-compile should be proportional to the
number of changed classes within a project. Obviously changing the
non-private interface forces the dependencies of a changed class to be
re-compiled, but if I add a single statement to a single method of a
single class it takes exactly the same amount of time to compile as if
I'd added a statement to every class in the project.

Mark

On Apr 19, 10:31 pm, "Nicholas Paldino [.NET/C# MVP]"
<[e-mail] d.caspershouse. comwrote:

That's not true, really. You couldcompileint o individual netmodules
(using the /target:module switch) and then assemble them into an assembly
using the assembly linker tool (al.exe).

You should be able to configure VS.NET 2005 to output a module by
changing the project file (specifically, the inputs to the csc task).

Hope this helps.

--
- Nicholas Paldino [.NET/C#MVP]
- [e-mail] .caspershouse.c om

<mwelsh1...@gma il.comwrote in message

news:11******** ************@b7 5g2000hsg.googl egroups.com...

Why doesn't C# allowincrementa lcompilation like Java?

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

InC#, there appears to be no analog. I have tocompileall 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 2005C#compilati on? Are there plans to have background
compilation in future versions of Visual Studio?

Thanks.

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

mw********@gmai l.com wrote:

I've looked into that, but it's not possible to do within Visual
Studio (it always compiles projects to dll's).

VS provides "standard" functionality.

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

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

Arne

[Jon Skeet [C# MVP]]

Arne Vajhøj <ar**@vajhoej.d kwrote:

mw********@gmai l.com wrote:

I've looked into that, but it's not possible to do within Visual
Studio (it always compiles projects to dll's).

VS provides "standard" functionality.

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

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.

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

That doesn't help the development time though.

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

[Paul Werkowitz]

Am 19 Apr 2007 17:08:03 -0700 schrieb mw********@gmai l.com:

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.

And then? At runtime, everything has to be linked together, which uses more
time than compiling the while C#-program .... what do you gain?

IMO it is no good way to use files as containers for modules. .NET allows
physical allocation of sourcecode (files) and logical allocation
(namespaces, assemblies).

If you want it the Java-way, you can. Simply compile your files to modules,
(/target:module) and link them later. Note that AFAIK VS does not have
project settings to do that, you have to use command line.
[snip]

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

10 seconds? How many lines do you have in your compilation unit?

My 2 cents...
Paule

[Jon Skeet [C# MVP]]

Paul Werkowitz <ne********@pri maprogramm.dewr ote:

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.

And then? At runtime, everything has to be linked together, which uses more
time than compiling the while C#-program .... what do you gain?

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.

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

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.

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

IMO it is no good way to use files as containers for modules. .NET allows
physical allocation of sourcecode (files) and logical allocation
(namespaces, assemblies).

If you want it the Java-way, you can. Simply compile your files to modules,
(/target:module) and link them later. Note that AFAIK VS does not have
project settings to do that, you have to use command line.

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.

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

10 seconds? How many lines do you have in your compilation unit?

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

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

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

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Jon Skeet [C# MVP] wrote:

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

Both are considerable faster than my brain, so I do not care that
much ...

:-)

Arne

[Jon Skeet [C# MVP]]

Arne Vajhøj <ar**@vajhoej.d kwrote:

Jon Skeet [C# MVP] wrote:

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

Both are considerable faster than my brain, so I do not care that
much ...

Are you suggesting you never find yourself waiting for a build? Even 15
seconds? If a build takes 15 seconds and you want to build 20 times in
an hour (which I certainly do with TDD) that means I'm wasting 5
minutes. Taking a 5 minute break is one thing - that's a good way of
relaxing etc - but being held up for 15 seconds 20 times can be very
frustrating. It's not long enough to do anything useful (other than
maybe sip a drink) but it's long enough to irritate.

I suspect two factors contribute the level of annoyance I feel which
others apparently don't:
1) TDD really relies on a faster turnaround
2) When working with Java in Eclipse, such delays are very rare

If you're not working in a test-driven way, but instead developing
large portions of code, then building, then developing the next large
portion of code, you'll probably spend a smaller proportion of your
time building. (I'd argue you'll spend a higher proportion of your time
debugging, but there we go...)

Likewise without having experienced a really good incremental build
system, it's hard to appreciate the pain of not having one.

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

[Ravichandran J.V.]

VS, incidentally, happened to be the first ide to provide for
incremental build/compilation. It is still considered the more robust,
despite the many fans of Eclipse, ide doing the rounds.

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.

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

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.

with regards,
J.V.Ravichandra n
- http://www.geocities.com/
jvravichandran
- Or, just search on "J.V.Ravichandr an"
at http://www.Google.com

*** Sent via Developersdex http://www.developersdex.com ***