Web site projects vs Web Application projects in ASP.NET 2.0

Visual Studio 2005 and ASP.NET 2.0 introduced a new project model, Web Site projects. The new project system allows you to open projects from a directory, local IIS or even from an FTP website.  Overall it became easier to use, however, an internal structure is very complex. It is based on delayed runtime compilation and event generation, partial classes, inferred referencing of assemblies, and a single-page assembly compilation. There is a lot of magic that happens inside and most of the times it works for your needs. However big generic projects usually hit the limitations listed below.

Limitations:

1. Deployment. If you need in-place deployment, this model is perfect. However, it’s not recommended since you are exposing your logic in clear text. So, anybody who has access to a physical server can mess with your code and you never going to notice this. You can try to make a precompiled website, but you going to end up with a lot of DLLs and almost untouchable ASPX files. Microsoft recognized this limitation and released a Web Deployment Project tool.

2. You need to keep track of what did you change locally and what did you upload to the production server. There is no versioning control. Visual Studio has a Web Copy tool, but this tool fails to help. I had to build my own tool, which kept track of changes based on Visual Source  Safe.

3. When you hit F5 for debug execution it takes merely 2 minutes to compile and execute a whole project. Of course, you can attach a debugger to an existing thread, but this is not an obvious solution.

4. If you ever try to generate controls on a fly you will hit the first unsolvable limitation. How to reference other pages and controls. Page and control compilation happens on a per-directory basis. In the best case you going to get assembly for each directory, in the worst case, each page or control is going to get its own assembly.  If you need to reference another page from the control or another page you need to explicitly import it with the @Reference directive.

So for:

customControl = this.LoadControl("~/Controls/CustomUserControl.ascx") as CustomUserControl;

You need,

<%@ Reference Control="~/Controls/CustomUserControl.ascx" %>

But what if you want to add something really dynamically and can’t put all appropriate @Reference directives? Or What if you are creating server control and it doesn’t have ASCX file, so you don’t have a place for @Reference ? Since each control has its own assembly, it’s almost impossible to do reflection.
 
Web Application Projects first appeared in Visual Studio 2005 SP1. They solved all issues mentioned above.

1. Deployment. You get just one DLL per project. You can create redistributable packages and repeatable builds. You can have versioning and build scripts.

2. If you did a code-behind change you can upload just one DLL. If you did ASPX change you can upload just ASPX change.

3. Execution takes 2-3 sec maximum.

4. The whole project is in one assembly, which helps reference any page or control. Conclusion. For any kind of serious work, you should use Web Application Projects. Special thanks to Rick Strahl for his amazing article Compilation and Deployment in ASP.NET 2.0.