Optimizing the build performance of an ASP.NET web site project?

Question

I'm currently working with an ASP.NET CMS that keeps close to 500 code files in the App_Code directory, as well as hundreds of web forms with code-behind in various folders of the site. It is a web site project (not a web application project) and I'm reluctant to change it since this is a project with multiple developers involved, plus that's the way the CMS is shipped.

I'm looking for hints and tips for optimizing the build process of this web site project, since Visual Studio often wants to rebuild all source files and code-behind files, which can take several minutes.

Are there ways to avoid rebuilding all the files? Should I bring up the point of separating our code and the CMS code into separate web application projects (instead of a web site project)? Are there any other ways to improve the build performance?

Answer 1

If the simplest solution patch-wise is to keep the .cs structure as similar as possible then I'd go with Andreas' recommendation of moving the App_Code into at least 1 other project.

Scott Guthrie posted a few tips on speeing compiles up in VS 2005, you didn't specify which version you were on, but the same speed tips apply. The second section of his post is specific to Web Site projects.

One other tip would be if you're working on pages and not code actually in the App_Code directory, there is a build option that may be useful. Go to Project Properties > Build > Change Before running startup page from Build Web Site to Build Page, this will build only the startup page when you fire up the debugger. I'm not sure if this scenario happens often, but if most of your work happens in the pages and not in App_Code, this will save you lots of compile time.

App_Code has to be built together, you should avoid having your codebehinds, etc in there. Everything that can be elsewhere should be. Just a note: the compilation time, at least in debug, is usually around 30-50x faster in a Web Application. That being said, you have to recompile the entire application every code change so there are drawbacks...but with namespace changes and such, I understand the strain patches would put on you.

Also, keep in mind that when you split code into other projects, besides being simpler all-around in terms of compile, Visual Studio will not need to compile those other dependency projects unless they have changed. As it stands right now, everything is fair game because anything in your project that can change can possibly affect anything else in there...however if you split it up, Visual Studio will only compile your other projects when either they change or a project they reference gets rebuilt.