Jeff Atwood has written a couple of entries recently about the C# Compilation tax and an article comparing Background Compilation and Background Spell Checking
I find the background compilation in vb.net, as it is currently implemented, does not work well for me. I often write the main structure of my code(which doesn't compile) and then fill in the gaps. And vb.net tells me it's wrong; except it isn't wrong, I just haven't finished. Ian finds this annoying as well and calls it Background Irritation.
Although it is, in someways, comparable to background spell checking, I find it is as irritating as MS Word's AutoCorrect. AutoCorrect decides that what I just typed is not what I meant to type and changes it. This works fine for "teh" and other such errors, but often AutoCorrect changes TLAs and other words until the meaning of what I have just written changes completely. Worse, it does it without telling me, which is very frustrating. But, I can switch it off when I know that I am writing something that it will cause me hassle with. In fact, now I think about it, I even use spell checking like I use the compiler. I write my text, I scan it to make sure that I think it's ok and then I ask the spell checker to double-check for me.
So what is wrong with background compilation? I want it on when I am bugfixing. I want it off when I am writing from scratch. I want it to work like that in c#. I don't care if it is on by default. But if it doesn't have a switch I don't want it. Therefore, for a tool to be useful to a good developer, it needs to be written as something that can be reached for when needed.
And on the subject of the c# compilation tax, VB.Net's bacground compilation is not free. The MSDN article Scaling Up: The Very Busy Background Compiler has some hints to help with large projects. But the idea of changing my code or switching off other features to help the performance of another feaure that I don't always want on, just seems to reinforce my perception that this needs a switch.