Visual Studio Web Application Vs Web Site Model

Visual Studio Web Application Vs Web Site Model
ASP.Net tutorial ©2012
Next Page           
In Visual Studio 2001 and 2003, the web project model was a Web Application. Visual Studio 2005 introduced the Web Site model which initially completely replaced the Web Application. Because many customers could not practically convert their Web Applications into Web Sites, VS 2005 reinstated Web Applications as an add-in. In VS 2008, both Web Sites and Web Applications are included as standard projects.

Confusion on the differences between the two models abound. Forums often have questions posted concerning a Web Site and answers are posted that are accurate - for a Web Application.  This comparing of apples to oranges proliferates the "doesn't work of my site", "works on mine" posts.

Each model has its pros and cons.  This article will highlight some of the major differences between the two.
  Web Application Web Site Advantage
Goes To
Build Assemblies Single Assembly Multiple Assemblies Draw
Dynamic Compilation No Yes Web Site
Stand-alone Page and User Control Classes
Provides ability to cross-reference controls, public methods, and public properties
No Yes Web Application

Build Assemblies
The Web Application model builds into a single assembly. The Web Site model builds multiple assemblies. The single vs. multiple assemblies paradigm drives the "Dynamic Compilation" and "Stand-alone Page and User Control Classes" features.  This results in varying deployment considerations between the models.

 Web Application Model
Dynamic Compilation
Since the Web Application model contains a single assembly, there is no dynamic compilation feature.

Stand-alone Page and User Control Classes
Since the Web Application model contains a single assembly, class objects are stand alone classes that are easily referenced between web entities.  Pages and user controls can directly reference each other's public properties and methods.

Since the Web Application model contains a single assembly, code deployment requires the single dll and modified aspx/ascx components.  Web Application code deployment is less complex than Web Site code deployment.  However, inadvertent application updates are more easily introduced.  

 Web Site Model
Dynamic Compilation
From a developer's perspective, the biggest advantages of using the Web Site model is the Dynamic Compilation feature. This allows coding changes to be applied to web entities while the application is running. Developers no longer have to stop the application, apply updates, rebuild, and restart the application. 

The advantage of faster development time cannot be over-emphasized.  In the Web Application model, the time required to step through pages to reach altered code after an application is rebuilt can be quite substantial.  Products such as wizards force developers to muddle thru multiple pages, each of which require data entry and experience SQL performance overhead, before the coding updates can be tested. With the Web Site model, there is no need to end the debug session. Within the active session, code updates can be applied and saved. Refreshing the web browser loads the updated code. Eureka! The developer is testing the updated code on the desired page with the desired test conditions.  Note, updates to class libraries still require that the debugging session be ended. 

Stand-alone Page and User Control Classes
Since the Web Site model contains multiple assemblies, class objects and interfaces reside within the App_Code directory.  They are compiled into the App_Code.dll and thus are accessible throughout the application.  One of the biggest disadvantages of the Web Site model is that web pages and user controls are no longer stand-alone classes. Communication between a Web Site's master pages, web forms and user controls is not straightforward.  However, there are coding solutions. Refer to the Web Site Techniques and Interface Techniques tutorials which outline various solutions.

The "Use fixed naming and single page assemblies" option results in different deployment strategies.
  • "Use fixed naming and single page assemblies" is checked:  An assembly is generated for every page and user control.  The assembly name remains the same for each deployment.   For large code bases, this can result in a significant number of assemblies.  The advantage is that code deployment can be restricted to specific pages and controls.  This reduces the chances of introducing inadvertent updates.  The disadvantage is that required updates can be potentially left out of a deployment.  Change control and deployment procedures must meticulously track modifications. 
  • "Use fixed naming and single page assemblies" is not checked:  All code within the same directory is compiled into a uniquely named dll.  The assembly name changes with each new deployment.   The publish process inserts the dll name into the master page, web form, or user control definition.  Every component within a directory must be deployed whenever a single element is modified.   
        »  All web entities residing within a directory are compliled into App_Web_jrj48mxx.dll.
        »  SamplePage.aspx page which resides within this directory is updated to inherit this dll -  
             <%@ page language="C#" inherits="SamplePage, _Web_jrj48mxx" %>
        »  SamplePage2.aspx page which resides within this directory is also updated to inherit this dll -  
             <%@ page language="C#" inherits="SamplePage2, _Web_jrj48mxx" %>

 Contact Us      ©2015 - All rights reserved
Powered by