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

Visual Studio 2005 and ASP.NET 2.0 introduced new project model, Web Site projects. The new project system allows you to open projects from a directory, local IIS or even from FTP web site.  Overall it became easier to use, however internal structure is very complex. It based on delayed runtime compilation and event generation, partial classes, inferred referencing of assemblies, single page assembly compilation. There is a lot magic that happens inside and in most of the times it works for your needs. However big generic projects usually hit 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 have access to physical server can mess with your code and you never going to notice this. You can  try to make precompiled web site, but you going to end up with a lot of dll and almost untouchable aspx files. Microsoft recognized this limitation and released Web Deployment Project tool.

 

2) You need to keep track of what did you change locally and what did you upload to production server. There are no versioning control. Visual Studio has 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 whole project. Of course you can attach debugger to existing thread, but this is not an obvious solution.

 

4) If you ever try to generate controls on a fly  you will hit first unsolvable limitation. How to reference other pages and controls. Page and control compilation happens on a per directory basis. On best case you going to get assembly for each directory, in worst each page or control is going to get its own assembly.  If you need to reference another page from a 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 it's own assembly, it's almost impossible to do reflection.
 
Web Application Projects first appeared in Visual Studio 2005 SP1. They solves all issues mentioned above.

1) Deployment. You get just one dll per project. You can created redistributable packages and repeatable builds.You can have versioning and build scripts.

2) If you did 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) 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.


Posted on Tuesday, July 8, 2008 by | Comments (1) | Add Comment

Comments

Gravatar

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

hi this project very good

Posted on 3/28/2009 4:52:09 AM by nagesh #
Gravatar

Which project?

New Comment

Your Name:
Email (for internal use only):
Comment:
 
Code above:

Categories

Recent Tweets

  • Simon Ince's Blog: Hierarchies with HierarchyID in SQL 2008 http://t.co/xSDwiF6rRS.
  • Visual Studio 2010 WAS painfully slow - CodeProject http://t.co/Usba1x6CZy

Valid HTML5