Speeding up build times in ASP.NET

Question

I am currently involved in a ASP.NET project with about 40 projects in the solution. We are doing all our development in cloned Virtual PC environments so all developers hav

Answer 1

You can greatly reduce the time you wait for a build with ASP.NET by doing the following:

• Use the new "optimizeCompilations" flag. It will tell .NET to not rebuild the entire project just because you changed one project/dll. If you have 40 projects and you don't use this, every time you change a simple method in one project, .NET will try to compile all other projects and dlls. With the new flag (plus the installation of a hotfix) you will see a lot of increase overall performance during development. Check it out this blog post with details on how to speed up the build with this the optimizeCompilations flag: http://www.wagnerdanda.me/2009/11/optimizing-asp-net-build-time-with-dynamic-compilation-and-optimizecompilations/

Hope it helps!

Wagner Danda da Silva

Answer 2

Scott Gu has an fairly helpful post about this:

Tip/Trick: Optimizing ASP.NET 2.0 Web Project Build Performance with VS 2005

Scott also has another article on the speed of this Hard Disk, which also has an impact on the general performance of Visual Studio:

Tip/Trick: Hard Drive Speed and Visual Studio Performance

Answer 3

We have a similar situation, and I found that our virtual machines were being heavily throttled, and so although they each ran on a single CPU, they weren't allowed to fully utilise that CPU. I managed to get 3 virtuals running on one physical to all perform 100% faster.

---

I'd also look at trying to reduce your number of projects. Our main solutions has 40 projefts, and I've been slowly consolidating these, and making sure new development fits in to existing projects where possible. The main culprits for this were webservices, where each had originally been created in a separate project. I am now adding all new webservices into a single project, and slowly moving the others across.

Answer 4

What we did at our company is to use file reference, so only the changed projects need to be built, and at any given time there is no more than 10 projects in my solution, mostly 2~3 gets built.

We also build our trunk for each check-in, and have batch file for developers to pull the most recent dlls.

Of course, this doesn't stop the painful assembly reference error from happening, but they become more of a nuisance than problem after a while.