473,320 Members | 1,974 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

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

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.

Apr 20 '07 #1
35 2966
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.com

<mw********@gmail.comwrote in message
news:11********************@b75g2000hsg.googlegrou ps.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.

Apr 20 '07 #2
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]"
<m...@spam.guard.caspershouse.comwrote:
That's not true, really. You couldcompileinto 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]
- m...@spam.guard.caspershouse.com

<mwelsh1...@gmail.comwrote in message

news:11********************@b75g2000hsg.googlegrou ps.com...
Why doesn't C# allowincrementalcompilation like Java?
Specifically, in Java I cancompilesingle .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#compilation? Are there plans to have background
compilation in future versions of Visual Studio?
Thanks.

Apr 20 '07 #3
mw********@gmail.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
Apr 22 '07 #4
Arne Vajhøj <ar**@vajhoej.dkwrote:
mw********@gmail.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.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Apr 23 '07 #5
Am 19 Apr 2007 17:08:03 -0700 schrieb mw********@gmail.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
Apr 23 '07 #6
Paul Werkowitz <ne********@primaprogramm.dewrote:
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.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Apr 23 '07 #7
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
Apr 23 '07 #8
Arne Vajhøj <ar**@vajhoej.dkwrote:
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.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Apr 23 '07 #9
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.Ravichandran
- http://www.geocities.com/
jvravichandran
- Or, just search on "J.V.Ravichandran"
at http://www.Google.com

*** Sent via Developersdex http://www.developersdex.com ***
Apr 24 '07 #10
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.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Apr 24 '07 #11
On Tue, 24 Apr 2007 07:33:12 +0100, Jon Skeet [C# MVP]
<sk***@pobox.comwrote:
>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
Apr 24 '07 #12
On Apr 23, 2:27 am, Jon Skeet [C# MVP] <s...@pobox.comwrote:
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?

Apr 24 '07 #13
On Apr 23, 3:30 pm, Jon Skeet [C# MVP] <s...@pobox.comwrote:
Paul Werkowitz <newsgro...@primaprogramm.dewrote:
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?

Apr 24 '07 #14
On Apr 24, 2:01 pm, Andy <a...@med-associates.comwrote:
Paul Werkowitz <newsgro...@primaprogramm.dewrote:
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

Apr 24 '07 #15
Andy <an***@med-associates.comwrote:
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.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Apr 24 '07 #16
On Apr 24, 10:49 am, Jon Skeet [C# MVP] <s...@pobox.comwrote:
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 - <s...@pobox.com>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

Apr 26 '07 #17
On Apr 24, 12:33 am, Jon Skeet [C# MVP] <s...@pobox.comwrote:
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 - <s...@pobox.com>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

Apr 26 '07 #18
tj**********@gmail.com <tj**********@gmail.comwrote:
On Apr 24, 10:49 am, Jon Skeet [C# MVP] <s...@pobox.comwrote:
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.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Apr 26 '07 #19
On Apr 24, 12:04 pm, "Jon Skeet [C# MVP]" <s...@pobox.comwrote:
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.

Apr 26 '07 #20
On Apr 24, 12:49 pm, Jon Skeet [C# MVP] <s...@pobox.comwrote:
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.

Apr 26 '07 #21
Andy wrote:
On Apr 24, 12:49 pm, Jon Skeet [C# MVP] <s...@pobox.comwrote:
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/
Apr 26 '07 #22
Andy <an***@med-associates.comwrote:
On Apr 24, 12:04 pm, "Jon Skeet [C# MVP]" <s...@pobox.comwrote:
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.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Apr 26 '07 #23
Andy <an***@med-associates.comwrote:
On Apr 24, 12:49 pm, Jon Skeet [C# MVP] <s...@pobox.comwrote:
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.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Apr 26 '07 #24
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.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Apr 26 '07 #25
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/
Apr 26 '07 #26
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.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Apr 26 '07 #27
On Apr 26, 12:58 pm, Jon Skeet [C# MVP] <s...@pobox.comwrote:
tjmadden1...@gmail.com <tjmadden1...@gmail.comwrote:
On Apr 24, 10:49 am, Jon Skeet [C# MVP] <s...@pobox.comwrote:
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 - <s...@pobox.com>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

Apr 27 '07 #28
On Apr 27, 4:05 pm, "tjmadden1...@gmail.com" <tjmadden1...@gmail.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

Apr 27 '07 #29
On Apr 26, 4:17 pm, Jon Skeet [C# MVP] <s...@pobox.comwrote:
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.

Apr 27 '07 #30
Andy <an***@med-associates.comwrote:
On Apr 26, 4:17 pm, Jon Skeet [C# MVP] <s...@pobox.comwrote:
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.
That would certainly explain why you don't see it as a problem - but
please believe that it *is* an issue for those of us who *don't* have a
one second build time.

Now, there's an open question as to quite *why* my builds are taking so
long. If it's that rare, it sounds like it's worth investigating a bit
further. Unfortunately I don't have any projects of any size at home
(although even my small MiscUtil project takes more than a second, if
I've made any changes).

My suspicion is that one of our pre-build steps is triggering a rebuild
of all the projects in the solution every time, which would account for
it, but I'll have to see.
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.
Wow - I don't think reload takes nearly that long for me, despite the
longer build time. Of course, that's another benefit of Java's "one
file per class" system - there's not a lot to load if you only use a
few classes.
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.
If you've got a subsecond build already, then I agree there's no
significant problem (except for reloading, by the sounds of it!).
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.
No - Eclipse doesn't do actual compilation until you save. It spots
some errors, but not all. For instance, if I delete a method that other
classes depend on, it won't produce any errors until I save.

In VS2005, the C# part of the IDE does some error checking without full
compilation, too. It's less work to parse the code, work out what
members are in which types, etc, than it is to do that *and* generate
the actual IL.
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.
Right. Oh the things we could do if we had more time.
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?
Bigger in just about every way. More classes, more KLOC, more projects
in the workspace (equivalent to the solution).
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.
That would certainly help to keep your build time down - but it does
have other disadvantages. It sounds pretty inconvenient if you have
several projects, and have to open up that many copies of Visual Studio
if you end up changing lots of them. (Does "Go to definition" still let
you bring up source code in your situation, btw? Not having that would
be a major inconvenience for me.)
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.
That all sounds good - but you did say that improving compile time was
one of the reasons for changing.
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.
Yup, you can download a trial for free:
http://www.jetbrains.com/resharper/

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Apr 27 '07 #31
Jon Skeet [C# MVP] wrote:
Arne Vajhøj <ar**@vajhoej.dkwrote:
>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?
Oh yes. For a 2 or 8 hour build.

But not for a JBuilder or VS single project 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 think the key point is the irritation.

If you do get irritated, then it is a problem.

But I just relax or look at something else.
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...)
In my experience the time spend typing in code, building, running unit
tests etc. is a very small part of creating the software.
Likewise without having experienced a really good incremental build
system, it's hard to appreciate the pain of not having one.
I have spend more time in Eclipse than in VS so ...

Arne
Apr 28 '07 #32
On Apr 27, 2:05 pm, Jon Skeet [C# MVP] <s...@pobox.comwrote:
That would certainly explain why you don't see it as a problem - but
please believe that it *is* an issue for those of us who *don't* have a
one second build time.
Understandable, and that would probably lead me to test a bit less
often, depending on how long the build takes.
Now, there's an open question as to quite *why* my builds are taking so
long. If it's that rare, it sounds like it's worth investigating a bit
further. Unfortunately I don't have any projects of any size at home
(although even my small MiscUtil project takes more than a second, if
I've made any changes).
It could be as simple as a slow HD.
My suspicion is that one of our pre-build steps is triggering a rebuild
of all the projects in the solution every time, which would account for
it, but I'll have to see.
That very well could be the issue. As I said, I know my Forms
projects take quite a bit longer, because of all the embedded
resoruces being compiled in.
Wow - I don't think reload takes nearly that long for me, despite the
longer build time. Of course, that's another benefit of Java's "one
file per class" system - there's not a lot to load if you only use a
few classes.
It never used it; a second or two at most. As soon as I upgraded to
2.4, reload time increased. On the NUnit list, it seems other's are
experiencing some performance issues as well. So I'm not sure that
one file per class would help as much. I"m also not sure it would
work in .Net anyway; doesn't NUnit load the tests and tested assemblie
in another appdomain? Once loaded, you'd have to tear down and
recreate the entire appdomain anyway.
If you've got a subsecond build already, then I agree there's no
significant problem (except for reloading, by the sounds of it!).
And that seems to be strictly an NUnit issue, as 2.2.9 was fine.
No - Eclipse doesn't do actual compilation until you save. It spots
some errors, but not all. For instance, if I delete a method that other
classes depend on, it won't produce any errors until I save.
Got ya; saving is actually something that could take some time,
because VS will do a checkout if the file isn't already checked out by
me.. but that's just the first time. I think the vb.net ide will
catch your mentioned error though. From what I"ve heard, anyway ;-)
That would certainly help to keep your build time down - but it does
have other disadvantages. It sounds pretty inconvenient if you have
several projects, and have to open up that many copies of Visual Studio
if you end up changing lots of them. (Does "Go to definition" still let
you bring up source code in your situation, btw? Not having that would
be a major inconvenience for me.)
I usually work on one layer at a time anyway, so I don't leave my
business layer until tests and coding are done. Then I do the UI. I
don't spend much time in my data layer because I generate most of it
off my table definitions. Goto defintion works the same as if you had
done it to a framework class; you get the definition based on the
metadata. Debugging though I can still step into the referenced
assemblies, once I tell vs to load the module and point it to a pdb
and source code location (which it remembers from then on). It can be
an inconvience, but at the same time I try to use my classes as black
boxes (until I try debugging when they aren't working well together)..
build to an interface after all. ;-)
That all sounds good - but you did say that improving compile time was
one of the reasons for changing.
I don't recall where I said that, if you could point me to a post
where I said that I'll check it out. But to be clear here and now, I
never seperated anything to improve compile time; I only did it to
seperate tiers or so that a useful class can be shared among
applications (or other assemblies, if we're talking the lower level
ones). I started out knowing I'd have multiple solutions and projects
and had an idea of what I wanted where.
Yup, you can download a trial for free:http://www.jetbrains.com/resharper/
I'll go do that, thanks!

Apr 30 '07 #33
Andy <an***@med-associates.comwrote:
On Apr 27, 2:05 pm, Jon Skeet [C# MVP] <s...@pobox.comwrote:
That would certainly explain why you don't see it as a problem - but
please believe that it *is* an issue for those of us who *don't* have a
one second build time.

Understandable, and that would probably lead me to test a bit less
often, depending on how long the build takes.
Fortunately, I've now made it significantly faster by fixing an issue
where a dependency kept getting rebuilt. It still takes longer than I'd
like to go through 8 projects spotting that all but one of them are up
to date, but it's a *lot* better than before.

<snip>
Wow - I don't think reload takes nearly that long for me, despite the
longer build time. Of course, that's another benefit of Java's "one
file per class" system - there's not a lot to load if you only use a
few classes.

It never used it; a second or two at most. As soon as I upgraded to
2.4, reload time increased. On the NUnit list, it seems other's are
experiencing some performance issues as well. So I'm not sure that
one file per class would help as much. I"m also not sure it would
work in .Net anyway; doesn't NUnit load the tests and tested assemblie
in another appdomain? Once loaded, you'd have to tear down and
recreate the entire appdomain anyway.
The point is that in a world without "large" assemblies, there's less
to load each time. It's not something that's likely to be changed, of
course...
If you've got a subsecond build already, then I agree there's no
significant problem (except for reloading, by the sounds of it!).

And that seems to be strictly an NUnit issue, as 2.2.9 was fine.
Have you tried Resharper UnitRun? I only found out about it today - a
better way of hosting unit tests than NUnit GUI, but free :)
http://www.jetbrains.com/unitrun/

It *may* be faster at reloading things - I don't know.
No - Eclipse doesn't do actual compilation until you save. It spots
some errors, but not all. For instance, if I delete a method that other
classes depend on, it won't produce any errors until I save.

Got ya; saving is actually something that could take some time,
because VS will do a checkout if the file isn't already checked out by
me.. but that's just the first time. I think the vb.net ide will
catch your mentioned error though. From what I"ve heard, anyway ;-)
:)
That would certainly help to keep your build time down - but it does
have other disadvantages. It sounds pretty inconvenient if you have
several projects, and have to open up that many copies of Visual Studio
if you end up changing lots of them. (Does "Go to definition" still let
you bring up source code in your situation, btw? Not having that would
be a major inconvenience for me.)

I usually work on one layer at a time anyway, so I don't leave my
business layer until tests and coding are done. Then I do the UI. I
don't spend much time in my data layer because I generate most of it
off my table definitions. Goto defintion works the same as if you had
done it to a framework class; you get the definition based on the
metadata. Debugging though I can still step into the referenced
assemblies, once I tell vs to load the module and point it to a pdb
and source code location (which it remembers from then on). It can be
an inconvience, but at the same time I try to use my classes as black
boxes (until I try debugging when they aren't working well together)..
build to an interface after all. ;-)
That makes sense when you only have one assembly per layer, but I tend
to have common assemblies, and occasionally thin "mini-layers" which
get their own assemblies but don't make sense to develop in isolation.
Also, making a change through all the layers is a lot easier to do when
everything's in one solution :)
That all sounds good - but you did say that improving compile time was
one of the reasons for changing.

I don't recall where I said that, if you could point me to a post
where I said that I'll check it out.
<quote>
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.
</quote>

<snip rest>

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Apr 30 '07 #34
On Apr 30, 2:40 pm, Jon Skeet [C# MVP] <s...@pobox.comwrote:
Fortunately, I've now made it significantly faster by fixing an issue
where a dependency kept getting rebuilt. It still takes longer than I'd
like to go through 8 projects spotting that all but one of them are up
to date, but it's a *lot* better than before.
Excellent, at least you've improved things for yourself.
The point is that in a world without "large" assemblies, there's less
to load each time. It's not something that's likely to be changed, of
course...
Hmm... possibly. There's so many ways to 'reload' though. I wouldn't
be suprised if many smaller files loaded slower though, as opening a
file is typically expensive, and loading the same amount of data from
one file vs. more smaller files may actually result in the one large
file being 'faster.' Of course my information could be outdated... I
remember that from the days of DOS.
Have you tried Resharper UnitRun? I only found out about it today - a
better way of hosting unit tests than NUnit GUI, but free :)http://www.jetbrains.com/unitrun/
It *may* be faster at reloading things - I don't know.
I haven't, but I did notice some unit testing commands in the menus
now.
That makes sense when you only have one assembly per layer, but I tend
to have common assemblies, and occasionally thin "mini-layers" which
get their own assemblies but don't make sense to develop in isolation.
I have multiple assemblies per layer, all seperated by functional area
(with some interfaces to allow some basic communication between the
two).
Also, making a change through all the layers is a lot easier to do when
everything's in one solution :)
Yes, that I won't be disputing.
I don't recall where I said that, if you could point me to a post
where I said that I'll check it out.

<quote>
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.
</quote>
Opps... that's not quite what I meant to say. Replace "both to" with
"which would." Application startup time is something that concerns me
and there's some reuse I would like to (there are a few use cases
shared in both applications). Compile time though has not been a
factor for me in deciding what goes where.

Apr 30 '07 #35
Andy <an***@med-associates.comwrote:
On Apr 30, 2:40 pm, Jon Skeet [C# MVP] <s...@pobox.comwrote:
Fortunately, I've now made it significantly faster by fixing an issue
where a dependency kept getting rebuilt. It still takes longer than I'd
like to go through 8 projects spotting that all but one of them are up
to date, but it's a *lot* better than before.

Excellent, at least you've improved things for yourself.
Indeed. Life became significantly more pleasant today :)
The point is that in a world without "large" assemblies, there's less
to load each time. It's not something that's likely to be changed, of
course...

Hmm... possibly. There's so many ways to 'reload' though. I wouldn't
be suprised if many smaller files loaded slower though, as opening a
file is typically expensive, and loading the same amount of data from
one file vs. more smaller files may actually result in the one large
file being 'faster.' Of course my information could be outdated... I
remember that from the days of DOS.
That would make sense if *all* of the files eventually needed to be
loaded. With unit tests, however, you tend (at least attempt!) to only
load a few classes.

<snip>
That makes sense when you only have one assembly per layer, but I tend
to have common assemblies, and occasionally thin "mini-layers" which
get their own assemblies but don't make sense to develop in isolation.

I have multiple assemblies per layer, all seperated by functional area
(with some interfaces to allow some basic communication between the
two).
I guess it depends on exactly what the problem is, but I've certainly
often been in situations where it *definitely* helps to have 5-10
projects in a solution.

<snip>
I don't recall where I said that, if you could point me to a post
where I said that I'll check it out.
<quote>
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.
</quote>

Opps... that's not quite what I meant to say. Replace "both to" with
"which would." Application startup time is something that concerns me
and there's some reuse I would like to (there are a few use cases
shared in both applications). Compile time though has not been a
factor for me in deciding what goes where.
Fair enough :)

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

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

1
by: jane | last post by:
HI, I had a question on incremental backup. We had an incremental backup every weekend. We did full backup every other week. That is one week incremental + full , the other week is...
12
by: Rhino | last post by:
I am having an odd problem: the sqlj command on my system doesn't work. I am running DB2 (LUW) V8 (FP8) on WinXP. I haven't done an sqlj program since Version 6 of DB2 (LUW) so I checked the...
149
by: Christopher Benson-Manica | last post by:
(Followups set to comp.std.c. Apologies if the crosspost is unwelcome.) strchr() is to strrchr() as strstr() is to strrstr(), but strrstr() isn't part of the standard. Why not? --...
0
by: Rudy Ray Moore | last post by:
I've been having trouble getting incremental linking to work under Visual C++ .net 2003 7.1 for my multi-project workspace. Ronald Laeremans and Carl Daniel (and a few others) helped me figure it...
8
by: Bern McCarty | last post by:
We have a large mixed dll that I can never seem to get to link incrementally. Below is the console output. For simplicity I've eliminated some stuff that we normally do when we really link this...
0
by: DolphinDB | last post by:
The formulas of 101 quantitative trading alphas used by WorldQuant were presented in the paper 101 Formulaic Alphas. However, some formulas are complex, leading to challenges in calculation. Take...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
0
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.