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.

Answer 2

You should give a try to the new OptimizeCompilation flag that we recently added.

<compilation optimizeCompilations="true">

Please see my blog post to learn what it's about, and where to get it. Unless you're on Win7 or are using VS2010, you'll need to get it via a hot fix.

Answer 3

We suffered a similar issue with our project, which is built this way to allow hot adding of new whitelabel partner sites.

The simplest way we found to speed up the build time was to reduce the IO bottleneck that Visual Studio hangs itself with. Get a decent SSD (we use the OCZ 60gb Summit drives) you should find the build times improved substantially.

The other time saver is to reduce the overall number of directories that your project has. For each new directory that Visual Studio encounters it launches a new instance of the compiler. Having as many files in the same directory as possible reduces this cost. (To get the folder structure that makes the project maintainable, use virtual folders)

Answer 4

I think your biggest problem would be the massive ammount of files. I would seperate the web app into multiple (at least 2) projects: your web project and a business layer (or something of that nature).

I best that most of those files in the app code are entities or files that very rarely change and hence in your situation it doesn' make much sense to keep them in your web app.

If you do decide to go this route when you do make a change to one of the files in your other project you will have to be very careful when you deploy changes as you will have to deploy the entire dll.

Answer 5

You should at least try to convert it to a web application, unless there are some political reason for not doing it. Its not as hard as it sounds, the biggest problem is that all your developers might have to reconfigure their solutions.

Try moving as much as of the code in App_Code to different projects, as they don't really need to be in the Web-Site. That should help a little bit at least.