Are ASP.NET Web Site projects inherently slow at compiling, or could I have deeper issues?

Question

Hi,

I've been working on a legacy ASP.NET Web Site (versus a Web Application) project at a client for some time now, and its slow compile time has me wondering:

Are web site projects known to be slow(er) at compiling (than Web Application projects)?

It's a pretty small website, but the entire solution has tons of functionality -- 19 projects worth of it, 18 of which compile really quickly (the non-web projects). The website project itself has ~100 pages and ~15 user controls (these actually take about half of the compile time) and normally compiles within 30 to 60 seconds. A complete re-build takes closer to the latter.

So, some things I believe could be slowing it down (you debunk them):

• (X)HTML validation issues (the code we inherited has thousands of compiler warnings about validation issues).
• High levels of abstraction -- since the code for the website pages is compiled at run-time, I'm guessing that whatever it's doing for user controls up-front is a lengthy process so that the binding at compile-time can happen.
• The mere size of the web site? I know these are not very efficient projects, and believe me, I've spent hours trying to get it converted to a web application, but Visual Studio was unable to parse a single ASPX file into its .aspx/.designer.xx components because of the validation problems I mentioned earlier.

Assuming my client won't approve more than a few hours to fix this up, is there any quick fixes, changes, or optimizations known that could help me out?

I do not have a puny computer, so its processing power is not an issue. I've also worked on Web Application projects equivalent in size and complexity that compile in just a few seconds.

I'm open to pretty much anything, so I'd love to hear your thoughts! Also, if you think this should be a wiki, let me know.

Answer 1

First read this blog post Tips to optimize design-time build performance for Web Sites in Visual Studio 2005

Main points made:

• Do not disable batch compilation
• Leverage Server-side Compilation
• Move App_Code files into a separate class library project
• Check for conflicting dependencies
• Turn off AutoToolboxPopulate in the Windows Forms Designer options.
• Disable validation for HTML editing

Another option that could help you is switching to a RAM disk: Running development from a RAM disk – options and products

If that doesn't help maybe splitting your large WAP into multiple ones could improve compile time. Unfortunatelly that strategy requires you to drop developing on Cassini. Instead you will have to use IIS as host: Using multiple Web Application Projects (WAP) in one Solution

Answer 2

My observations have been the same: web site projects take awhile to build, longer then web app projects. I think I found some information on why, check this out: http://msdn.microsoft.com/en-us/library/aa730880(VS.80).aspx

Search for "Iterative development". It says this about web site projects, when compared to web application projects:

By default, Visual Studio completely compiles Web site projects whenever you run or debug any page. This is done to identify compile-time errors anywhere in the site. However, a complete site build can significantly slow down the iterative development process, so it is generally recommended that you change the build project option to compile only the current page on run or debug.

Answer 3

Correction: web sites are not projects. You'll notice the lack of any .proj file.

Answer 4

One fact most developers overlook in an ASP.NET Web Project is the amount of classes in the App_Code folder.
The more classes you put in it, the longer it will be the compilation time.

From the ASP.NET Compilation Overview on MSDN:

ASP.NET creates an assembly for each application directory (such as App_Code) and one for the main directory. (If files in a directory are in different programming languages, then separate assemblies will be created for each language.)

So, if you can basically minimize the Folder Hierarchy and reduce the amount of classes in it, it will probably reduce the compilation time.

Another thing I noticed from your post is that, you have 18 non-website projects.
I think it is a bit too excessive because think of it this way.

When the Web Project compilation starts, the ASP.NET Compiler needs to link the 18 separate DLL files.
If those projects can be combined to reduce the number of DLLs, it might help also.

From maintainability viewpoint, having 18 projects is a bit excessive unless there are REAL strong reasons to do so.
I would suggest reviewing the projects and combine them.

I hope it helps.

Answer 5

This may not be ideal, but you can split your projects into multiple solutions. For example you can take the user controls and put them in Solution A and the rest of projects into Solution B. Then compile the controls in Solution A and file reference to them from Solution B which should help cut down the compile time

Answer 6

Website or web project, the performance should be similar after compilation phase. If the issue is poor performance immediately after deploying a new set of codes, a quick way I can think of is to pre-publish the site. (see reference http://msdn.microsoft.com/en-us/library/1y1404zt(VS.80).aspx)

Depending on the options you choose during the publishing, you may lack flexibility to make changes on the fly (which you shouldn't anyway).