There have already been several posts about build being slower in VWD than in Visual Studio 2003. This is true.
With Visual Studio 7.0 and 2003 there was a huge gulf between the SDK version of examples, starter kits, etc., and the Visual Studio versions. The organization of the source code differed mostly in single-file SDK versions and code-behind VS versions. But there was an even more substantial difference in deployed webs. SDK versions seemed to simply and magically compile themselves, while the VS versions needed to be built and prop'd to the website. One big assembly was generated in the /bin directory. The SDK versions could be modified right on the web server using only notepad; the VS versions had to be modified in the VS Solution, built, and prop'd. Strangest of all, you could make some changes in the running VS webs using notepad, like modifying some text on an aspx page, and it would show up the next time you loaded the page in your browser, but other changes (like modifying the code) simply wouldn't "take."
This really didn't delight everybody. Modifying a sample meant fixing the C# & VB version for both the SDK & VS versions. It was difficult to exchange code. It was confusing. It looked broken. And having to resurrect a project to make a tweak and replace every executable bit to implement a one-line change was simply not a decent model for many kinds of web development.
Early in 8.0 we decided to rip the extensive build system out of the web project system, and instead rely on the managed Client Build Manager, an ASP.Net class wrapping the Build Manager, the ASP.Net piece that compiled the SDK-style webs. The advantages seemed pretty significant: excellent fidelity between development and deployment code generation, any-language support, no-solution-file web projects (my favorite) and simplicity. What the build system used to do was to spin up its own compilers and keep most code built to the state just before writing the actual assembly, so doing a build actually meant just emitting the assembly file.
Now we rely on the Build Manager itself, which isn't really aware that Visual Studio is even running. We've still got our own compilers building the symbol tables used by Intellisense, but they are not used to emit the executable code. And thus we incur some substantial costs in latency and working set.
Was it a good decision? Only time and your comments will tell. The new web project model is a delight to work with; all you have to do is select a folder and it behaves like a project; no files are added to it at all. Could we have accomplished this without duplicating compilation costs? Will version independence be a substantial win going forward? Will the cumulative compilation hit make old and bitter people out of us all? I'm interested in your feedback.
Here's a hint. For "consistency" we currently do a full build internally when you hit F5 before we request the target page, which will trigger a Build Manager build. If the delay is bothering you, try this:
Do this per web; there's no global setting.If this makes a noticeable difference in your day-to-day experience, let me know.Do you feel that this setting should be off by default?