I’m still planning on finishing my exegesis on background compilation, but I thought I would take a moment to address something that came up in the comments on Part 1 and which we get from time to time: why can’t I turn off background compilation?

Unfortunately, we usually get this question because a customer has got a project where the background compilation is causing the IDE to become unacceptably slow. There are, of course, theoretical maximums of what any program can handle (and users love pushing those maximums), but there have been problems with background compilation in the past. After shipping VS 2002, we discovered that there were some bugs in the way that we did our dependency calculations that resulted in too much decompilation occuring. This caused problems on some very large projects and we fixed it in VS 2003. If you’ve got a large project in VS 2003 that’s still got problems with responsiveness in the IDE and would be willing to give it to us to test against Whidbey, drop me a line and I’ll connect you with someone. We definitely want to fix any problems!

The reason, though, why you can’t turn of background compilation is that the IDE completely depends on it. The information provided by background compilation drives Intellisense, it enables the WinForms designer (as well as all other designers), it fills the dropdowns at the top of the window, it drives the object browser, it enables go to definition, etc, etc, etc. Essentially, without background compilation, the IDE becomes Notepad.exe with syntax coloring. (Coloring, interestingly enough, does not require background compilation because it’s entirely based off the lexical grammar of the language and requires no further knowledge of the code.) So that’s why we don’t let you turn it off.

But I’ll emphasize again: we believe there’s no reason that large projects shouldn’t perform well. And we work hard on ensuring that, so let us know if there are still problems!