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

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance



Andy <andyj@xxxxxxxxxxxxxxxxxx> wrote:
On Apr 27, 2:05 pm, Jon Skeet [C# MVP] <s...@xxxxxxxxx> wrote:
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 - <skeet@xxxxxxxxx>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
.



Relevant Pages

  • Re: Why doesnt C# allow incremental compilation like Java?
    ... On the NUnit list, it seems other's are ... It sounds pretty inconvenient if you have ... I usually work on one layer at a time anyway, ... assemblies, once I tell vs to load the module and point it to a pdb ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Make a DLL in C# for FoxPro
    ... Interop from managed -> COM is a different story, here we are talking about new developments, and here you have probably accepted the larger memory footprint :-) ... The first is handled by the DLL/C++ code I posted which loads the .NET runtime and allows loading of assemblies and types. ... If you're not adverse to registering components you can completely skip this step and just use the .NET wrapper component from FoxPro with CreateObject. ... *** Load Static Method ...
    (microsoft.public.dotnet.languages.csharp)
  • RE: bizarre asp.net app loading failure
    ... I gave it a try but unfortunately the fusion logs didn't show ... I see a bunch of assembly load logs for application 3e70de80 ... (presumably the name for the app pool). ... of assemblies that reference it, even though they are not used by all the ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Force Load DLL From Different Dir?
    ... try load the version MyAddIn bound to at compile time. ... Actually this is NOT version related, but context related: Assemblies can ... Microsoft Online Community Support ...
    (microsoft.public.dotnet.framework)
  • Comparing the assembly name resulted in the mismatch: Minor Version
    ... I think the problem is hidden in some dark corner of the Microsoft universe. ... An error occurred during the processing of a configuration file ... Could not load file or assembly 'ADODB, ... Line 64: <assemblies> ...
    (microsoft.public.vstudio.development)