RSS Feed


Web Site or Web Application?

Here's a question I hear a lot: "Should I use a Web Site (WS) or Web Application (WAP) for my ASP.NET 2.0 project?" Certainly Web Site projects look attractive when you are using a free copy of Visual Web Developer and a just have a couple of pages in your site. But how do they work for a real application?

There are many differences between these two project types and the choice will often be made based on either developer preference or operations considerations.  Project type usually has no impact on the capabilities or performance of the application itself – except for any compilation you postpone to runtime.  But if you are a developer using VS.NET 2005 for a medium-to-large application, WAPs can save you a lot of time over WSs.  The full-site compilation tax for Web Site projects is very noticeable, and must be paid every time you:

  • Run the site (debug or not)
  • Use the refactoring tools
  • Run code analysis

I am that VS2005 developer and this is the deal-breaker for me. I just hate how much it slows down my coding. So, for all but the most trivial projects I use a WAP.

But not everyone feels uncomfortable with the compilation tax. Since some folks will choose to use a Web Site project for a productions web app, I'll add this tip: consider compiling and deploying the entire site as a single DLL to avoid the runtime recompilation vulnerability. ScottGu has a number of must-read compilation and deployment tips for Web Site project users.

Here's a checklist of differences between the project types:

 

Web Site (WS)

Web Application (WAP)

Comments

Tools support

VS.NET, Web Developer, notepad

Requires VS.NET 2005, SP1 and later

  

Supported page code models

Code-beside

Code-in-page

Code-behind

Code-beside

Code-in-page

All code models work in both models, including the code-in-ASPX model.  

Code-behind also generates a partial class for code declarations in a designer.cs file  

Time for full site compilation

Very high

Normal

The time to compile a WS scales in an almost linear fashion with the number of pages in the project.   For a medium-sized projects, a full-site compile for a WAP can be 10x faster than a full-site compile for a WS.

Full site compilation can have a significant impact on developers that use VS.NET refactoring features.

"Magic"

Mostly compile-time magic:

Namespaces can be random and generated at compile time

DLL are randomly named at compile time

Assembly references are inferred from #using statement and DLLs in the bin directory

Mostly design-time magic:

   

.designer files are generated for control declarations

Overall, WAPs are much less magical. 

Less magic can be helpful for cases where you want to exercise explicit control over how components appear to each other.

Magical assembly references in WSs can be harder to manage for a team project.

Production recompilation vulnerability

Utilities that touch source files in the production environment (like virus checkers) can cause recompilation, and may cause an app restart as well.

n/a

For WS projects, this vulnerability can be mitigated by compiling the entire site to a DLL.

Deploy changes to only part of the web application

Because the page DLLs are magically named at compilation time, it's often difficult to replace a single page without restarting the application.

Partial changes can be deployed by copying markup files (if needed) and the site DLL to the production server.

Contrary to what most folks would guess, the magical compilation of WSs makes it a bit more difficult to deploy partial site changes than for WAPs.

Team-wide code analysis rules supported?

no

yes

Code analysis rules are part of the project for WAPs, and can be standardized and checked in for the whole team.  WSs support unshared personal rules only. 

Resources

The WS model splits the majority of string resources in separate, per-page resource files.  It's possible to use Global resources, but more clunky. 

Per-page or explicit models supported.

Per-page file approach can increase the cost of localization (round-tripping multiple files to the translation vendors).

XML documentation support (VS.NET)

no

yes

  

Strongly-typed MasterPage support

no

yes

Using strongly-typed MasterPages, you can define members on the MasterPage that are available to all of the derived pages, without resorting to reflection.

Supported by Team System Build?

no

yes

  

Project to project references supported

no

yes

For WSs, you must copy the built DLLs into the WS's bin folder, either manually or by doing some fiddling with the build output path in the component project.

Cross-project debugging supported

sorta

yes

With project to project references (WAP), you can debug into a component project in the solution with no additional setup. It just works.
For WSs you must build a debug version of the component and manually attach to it during your debug session.

 
Posted by Susan Warren | 8 Comments | Trackback Url | Bookmark with:        
Tags:

Links to this Post

Comments

Tuesday, 19 Jun 2007 04:49 by Biased against the website model?
You are too biased against the website model and have slanted your comparison chart as a result. You are making a big deal out of the compilation time for the full website. You do not mention that if you just change a single page and view it on the development web server it shows the change immediately as it just has to compile a single page. Since we update one page at a time this is the ideal choice. And when ASP.NET 2.0 was released it only had the website model. Later, after some vocal developers complained, they released the legacy web application model that was in ASP.NET 1.1. And for strong-typed master pages you can easily make use of base classes. Instead of inheriting from MasterPage, Page and UserControl you can create your own base classes on top of them and add events, methods and properties. I did that with a website and it works great. And to prepare a website for deployment you can use the website deployment project type. That all works great with MSBuild which is what Team System uses on the build server. I always see the web application project type as the choice for the developers who want to stay behind with the ASP.NET 1.1 model which generated code in the code-behind instead of using the dynamic compilation features in the website model. I also work with a set of large websites in the web application model. They take forever to compile. At least with the website model I could compile it once and then go back to the per page compilation model.
Tuesday, 26 Jun 2007 09:52 by Recommend using Web Deployments Project snap-in
I use the Web Deployments Project snap-in (http://msdn2.microsoft.com/en-us/asp.net/aa336619.aspx) to pre-build my web site project before deploying it to the web server. That way, there's no in-place compilation, no compilation tax, and no source code on a production server. The snap-in also orchestrates the use of aspnet_merge so that you don't have to have randomly numbered, magically named DLLs. It also gives you a good introduction to MSBuild. As far as compilation tax in development, you could go to your Solution's Property Pages and, under Configuration Properties, uncheck "build" for your web site. This should avoid re-building the web site every time you hit Run--looks like your link to ScottGu's post discusses this somewhat.
Tuesday, 26 Jun 2007 11:03 by I have to agree with the above comment.
The website model gets a massive plus from me, due to the ease of deploying small changes to single pages or classes. I can't count how many hours I wasted uploading 1mb+ web application DLLs to make changes to a single page.
Wednesday, 27 Jun 2007 09:49 by Not too bad
This is a great idea, and not a bad breakout of important attributes, but seems to be developed from the standpoint of trying to justify one's decision to go with WAP. WS projects have some very good attributes also, but you don't list them. When doing these comparison charts, you should think about what a supporter of each technology would tell you to include. Also, there are many more people using Express and Professional than the Team Systems, so all the emphasis on TS does not necessarily reflect what's important to MOST people. Thanks for doing this, I hope it doesn't come across as too negative, because it was a good read. -Todd ("Speednet")
Thursday, 28 Jun 2007 07:32 by Maintenance ?
Your comparison fails to consider the maintenance aspect of most websites. Typical (90%) of websites are "websites" because they are under routine revision. Regular modifications are always simplest to do on a page level which also votes hard against the idea of even using code-beside. If desired, a push of a button on a .bat file will compile all the App_code folder into a single dll which can then be uploaded to the production server. That's more than enough to resolve compile time concerns on th e production server. I see no real advantage to Web Applications except to make another fashion statement in an attempt to again take a simple concept and make it look very complicated, similar to using complex C# instead of simpler VB. All the efforts to make web development look like desktop development is a folly.
Tuesday, 3 Jul 2007 07:30 by Web Application is not legacy.
The Web Site model was a reaction to complaints from corporate environments, where many people have to share one project file. But for a web developer who works on many projects for many clients, either alone or with a small team, Microsoft got it right the first time. The proof is the fact that Web Application projects' made a comeback. And even without the comeback, no other type of project was changed to use a file-system-based approach. If the Web Site project was as great as its proponents claim, then MS should have continued with the approach and applied it to other types of projects. The Web Application project isn't really "legacy," considering that it's the way the .NET engineers intended web projects to work, and it's included in VS 2005 SP1. The Web Site project is a drastic change to address a single issue. But if you never considered project file sharing a major issue, the drastic change doesn't really help much. Web Site is a good option if you have project file sharing challenges, but it should never have displaced the Web Application project. Web Site's slow builds and flawed deployment options are frustrating. (VS 2003 also had no worthwhile deployment option, but we had UnleashIt.) Build-on-the-fly is cool, but it doesn't play nice with namespaces or dependent projects.
Tuesday, 3 Jul 2007 10:33 by Definitely biased against the WebSite model!
After some time working with a web project it became a reoccurring annoyance for issues usually caused by the new web site project type. Issues included: - Project items are automatically included in the project, exclusion is only possible by renaming them to *.exclude - Project settings are managed differently, some options not available -- it is not possible to set defines, such as TRACE. -- no pre- or postbuild step -- no distiction between debug and release build as with other projects - Assembly references are handled by placing them along with some control files in the bin folder. -- reference updates often fail -- these files become project files (despite the fact that they are intermediary output), thus the SCM tool insisted on putting them under control -- during build the SCM tool updated those files without permission, not even asking -- some references could not be set because they were already referenced (copied) implicitely with others - Information for the aspnet compiler is being put in the web.config and updated during build. Again the SCM tool updated the web.config without permission. - Building the whole web site takes considerable amount of time. Eventually we decided to migrate to WAP, a project type similar to the one in VS2003, yet updated to support additional VS2005 features (such as using casini). Our problems were virtually gone. Yes, I _am_ biased against the web site model.
Monday, 9 Jul 2007 02:34 by "the choice will often be made based on either developer preference or operations considerations"
This was my assertion in the original posts, and the comments certainly support it. I welcome the passionate discussion on this issue. I personally hate the development compilation tax, which is required for features I routinely use (debugging, refactoring, code analysis). But I certainly acknowledge and respect that other folks work differently from me, and on projects with much different operations requirements from me. Thanks for the awesome tips. ~Susan
Name:
URL:
Email:
Comments:

CAPTCHA Image Validation