Cancel the notorious background compilation

[Heiko]

Anyone out there who knows how to do that?

 

Our sln has become sort of big now, and its a nuisance to watch yer lines of code scroll in slowmotion. :-)

[Robby]

Do you mean that you have many projects in one Solution and you don't want to compile all of them each time you run?

If so, you can go into the Properties of the solution and select the projects to compile or not.

[divil]

I couldn't find an option to turn off background compilation, but it's odd that it slows your code view down because it happens in another thread. Is this a particularly old machine?

[Heiko]

Thanks, no that was not what I wanted (besides, what you described used to be better in VS 6 --- the IDE would automatically recognize, which part needs recompilation and which doesn't. In .NET I always have to wait until the whole thing is recompiled, even if I only changed one of the 7 DLLs).

 

 

No, what I want is to switch off that background thread that permanently performs syntax checks on my code, making the well-known lines (as known from the word spellchecker) at the places where syntax probs, undeclared vars etc have been detected.

[Heiko]

Not old for a galaxy, planet, or .NET Programmer.

 

2 1/2 yrs I'd say :-)

[Nerseus]

For reference, I upgraded from a PIII 700 w/ 384meg ram to a P4 3ghz w/ 1gig ram - made a WORLD of difference.

 

At home I had a PIII 733 w/ 512 meg ram, ran about the same speed so I assume it's not necessarily memory (but more always helps) but a good CPU as well.

 

.NET sure isn't VB3... (1 to 3 floppies :))

 

-Nerseus

[Heiko]

Oh well.

Time for a talk with my boss, I presume :-)

(P III 533 w/ 512 meg ram)

[Nerseus]

I should have mentioned that I have one form to handle a large transaction. It contains 9 tabs, all have mostly just grids but one tab has about 30-40 controls. We use a number of custom controls for DateTime and Number fields in addition to custom grids. It used to take about 10-15 seconds to show the form in the designer (just double-clicking the form), it now takes about 3 or 4 seconds. While my wife thinks I'm inpatient because I told her the 15 seconds was "too long", it really is a *long* time to wait for something so simple as tweaking a UI control. It also makes running the program/debugging more difficult because it takes over a minute to get to the point where the form is loaded in the correct state to test (mostly a lot of searches and what-not to get there).

 

If you have large forms or large projects, a faster machine is well worth the investment. I used to find myself distracted since, as I said, it took over a minute to get to the point where I could prep the form for debugging. I'd check/send an email, etc. while waiting, but it just spread out the time to debug. Not a good idea...

 

Of course, if MS ever puts back in the edit-and-continue (with the changes), this may help stop this. It's the one thing I miss about VB6 and prior.

 

-Nerseus

[divil]

Edit-and-continue is one of their biggest priorities for the next major release of VS.NET (the one after 2003).

[Heiko]

Yet I don't see how it is going to work, unless you disallow all edits that affect interfaces and types ... :-)

[Nerseus]

Even VB6 has it's limitations on what you can change at runtime. I'm sure MS will provide a list of what can/can't be changed at runtime. But changing some simple things like commenting out a line or changing a literal (4 to 5, for instance) will probably be allowed once they add the edit-and-continue. I'm not holding my breath, but I will be glad if/when it comes :)

 

-Nerseus

[divil]

Yeah, it'll certainly be nice to be able to change code without restarting the app, although it takes so little time I think I've just gotten used to it.

 

The immediate window is also pretty useful for debugging stuff, but not many people seem to know about using it.

[Heiko]

Oh yes. Intellisense in the immediate window, that'd be great.