.NET Framework - Why doesn't C# allow incremental compilation like Java?

Asked By mwelsh111 on 19-Apr-07 08:08 PM
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

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?


Nicholas Paldino [.NET/C# MVP] replied on 19-Apr-07 11:31 PM
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]
- mvp@spam.guard.caspershouse.com
mwelsh111 replied on 20-Apr-07 07:36 PM
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.


On Apr 19, 10:31 pm, "Nicholas Paldino [.NET/C# MVP]"
arn replied on 22-Apr-07 06:57 PM
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.

Jon Skeet [C# MVP] replied on 23-Apr-07 02:27 AM
I find it a problem - at least compared with using Eclipse in Java.=20
That builds every time you save, and has a sufficiently nippy=20
incremental compiler that it encourages you to save (and therefore=20
compile) often. I find this very helpful compared with the VS model,=20
where you can't build as often because the build takes significantly=20
longer. (Even if it's only 15 seconds, that's reasonably significant.)

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

That doesn't help the development time though.

Jon Skeet - <skeet@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
Paul Werkowitz replied on 23-Apr-07 03:07 AM
Am 19 Apr 2007 17:08:03 -0700 schrieb mwelsh1118@gmail.com:

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.


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

My 2 cents...
Jon Skeet [C# MVP] replied on 23-Apr-07 03:30 PM
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.

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.

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 - <skeet@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
arn replied on 23-Apr-07 07:32 PM
Both are considerable faster than my brain, so I do not care that
much ...

Jon Skeet [C# MVP] replied on 23-Apr-07 07:49 PM

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

I suspect two factors contribute the level of annoyance I feel which=20
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=20
large portions of code, then building, then developing the next large=20
portion of code, you'll probably spend a smaller proportion of your=20
time building. (I'd argue you'll spend a higher proportion of your time=20
debugging, but there we go...)

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

Jon Skeet - <skeet@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
Andy replied on 24-Apr-07 08:51 AM
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..

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.

Then stop compiling every change to a file.  Why would you even bother
recompiling after putting some whitespace into a comment?
Andy replied on 24-Apr-07 09:01 AM
But you still can't run without the other files compiled, am I right?

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

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

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

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

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.

So what?
Jon Skeet [C# MVP] replied on 24-Apr-07 12:04 PM
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.)

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

Everything *will* have been built though. That's the point - it's
(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

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.

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

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

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

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

Jon Skeet [C# MVP] replied on 24-Apr-07 12:49 PM
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.

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.

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.

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 - <skeet@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
tjmadden112 replied on 26-Apr-07 10:58 AM
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.


Tim Madden
Jon Skeet [C# MVP] replied on 26-Apr-07 02:58 PM
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 - <skeet@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
Andy replied on 26-Apr-07 03:31 PM
Ok, but I haven't had .Net project compiles take a huge amount of

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

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

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

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

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.

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.

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.

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 haven't used resharper yet, although I understand how much of a
benefit that functionality will provide.  I'm hoping to purchase
Resharper soon.
Andy replied on 26-Apr-07 03:36 PM
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.

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

There are times I recompile frequently, if I'm making minor fixes to
code.  It just doesn't seem to take that long for me.  Perhaps this is
because I have a lot of focused assemblies though.
Barry Kelly replied on 26-Apr-07 04:00 PM
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

-- Barry

Jon Skeet [C# MVP] replied on 26-Apr-07 04:17 PM
It depends on what you mean by "a huge amount of time". To me, 10
seconds is enough to be a distraction.

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

Rarely, indeed.

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

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'll have a look at what beta 1 does on my virtual PC.

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

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.

Possibly - depending on what it really does.

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 - <skeet@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
Jon Skeet [C# MVP] replied on 26-Apr-07 04:19 PM
Yes, it still takes me longer to write the code too - but the build
cycle is enough to be a distraction and an irritant.

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 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 - <skeet@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
Jon Skeet [C# MVP] replied on 26-Apr-07 04:20 PM
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 - <skeet@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
tjmadden112 replied on 27-Apr-07 11:05 AM
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.

Jon Skeet [C# MVP] replied on 27-Apr-07 11:46 AM
On Apr 27, 4:05 pm, "tjmadden1...@gmail.com" <tjmadden1...@gmail.com>

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.

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

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.

Andy replied on 27-Apr-07 12:24 PM
My builds typically take one second or less.

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

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.

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.

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

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

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

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.
Jon Skeet [C# MVP] replied on 27-Apr-07 02:05 PM
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.

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.

If you've got a subsecond build already, then I agree there's no
significant problem (except for reloading, by the sounds of it!).

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.

Right. Oh the things we could do if we had more time.

Bigger in just about every way. More classes, more KLOC, more projects
in the workspace (equivalent to the solution).

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

That all sounds good - but you did say that improving compile time was
one of the reasons for changing.

Yup, you can download a trial for free:

Jon Skeet - <skeet@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
arn replied on 28-Apr-07 01:46 PM
Oh yes. For a 2 or 8 hour build.

But not for a JBuilder or VS single project build.

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.

In my experience the time spend typing in code, building, running unit
tests etc. is a very small part of creating the software.

I have spend more time in Eclipse than in VS so ...

Andy replied on 30-Apr-07 10:38 AM
Understandable, and that would probably lead me to test a bit less
often, depending on how long the build takes.

It could be as simple as a slow HD.

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.

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.

And that seems to be strictly an NUnit issue, as 2.2.9 was fine.

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

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

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.

I'll go do that, thanks!
Jon Skeet [C# MVP] replied on 30-Apr-07 02:40 PM
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.

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

Have you tried Resharper UnitRun? I only found out about it today - a
better way of hosting unit tests than NUnit GUI, but free :)

It *may* be faster at reloading things - I don't know.

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

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.

Jon Skeet - <skeet@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
Andy replied on 30-Apr-07 04:56 PM
Excellent, at least you've improved things for yourself.

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.

I haven't, but I did notice some unit testing commands in the menus

I have multiple assemblies per layer, all seperated by functional area
(with some interfaces to allow some basic communication between the

Yes, that I won't be disputing.

Opps... that's not quite what I meant to say.  Replace "both to" with
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.
Jon Skeet [C# MVP] replied on 30-Apr-07 05:51 PM
Indeed. Life became significantly more pleasant today :)

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.

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.

Fair enough :)

Jon Skeet - <skeet@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