Web site vs web application in Visual Studio

Rob Conery got me thinking about web site maintenance and I put forward a brief comment on the two distinct types and how Visual Studio handles them which I have expanded upon here.

Web site

Primarily for working with ad-hoc web sites that have programmed elements. Easily identified by customer-specific content present in aspx files.

No solution or project files are required and the pages and source can reside locally (file system, IIS) or remotely (FTP, WebDev/FrontPage extensions) via the File > Open > Web Site… menu option.

Code-behind and classes are typically stored on the web server which compiles them in-memory on demand. Changes can be made to the files without restarting the application and losing sessions.

For Against
Quick edit, test, deploy cycle Syntax errors at run-time
No need to compile or restart app Can’t create an installer
Source always available Source on server useful to hackers

Web application

Web application projects were introduced as an add-on for Visual Studio 2005, later rolled in to VS 2005 SP1 and made a full first-class citizen with Visual Studio 2008.

Like the name implies these are primarily for web applications, those times when you have written a product or solution that happens to have a web interface.

Web application projects exist on your local drive and are treated like any other VS project type and can be added to existing solutions are subject to full compilation, validation and build steps.

Deployment is typically via MSI installers however you can also utilize the addition Web Deployment Projects add-in which allows you to deployment directly to servers which is useful for deploying to test environments.

For Against
Controlled build & deploy process Deployment causes application restart
No class files on web server, dll only Can’t deploy individual classes
Syntax errors at compile time


Sander and I were discussing this article and thought an interesting solution might be to use the Web Application model for local development but to use the Publish option to publish all solution files to an intermediate directory.

Then in the intermediate directory just remove the bin/applicationname.dll file and copy to the target. This should prevent an application restart unless the web.config or global.asax/global.asax.vb files have been modified.


12 responses

  1. Avatar for steve

    'Code-behind' is one of those terms that irrationally annoys me, because it's another term we didn't need. There were perfectly good terms already (like 'component' perhaps) to represent having compiled code behind a web application - after all in the days of yore ALL code was compiled (CGI), on-demand server-side code came later. I used DLLs behind a pre-.Net ASP application 10 years ago, written in VB6, and I didn't feel I needed a new term to describe it. Tsk.

    steve February 7, 2008
  2. Avatar for steve

    Before you ask, yes 'servlet' annoys me just as much. I mean, it's not even a proper word. shakes fist

    steve February 7, 2008
  3. Avatar for Baggio

    @Damien: loosing sessions ? :)

    Baggio February 7, 2008
  4. Avatar for Ken Egozi

    My favorite schema - I use MonoRail and AspView. So to the server I only deploy:

    1. web.config.
    2. global.asax
    3. Web.dll (controllers) dependencies (domain dll, castle, NHibernate, whadever)
    4. CompiledViews.dll (all of the view templates in precompiled format)
    5. js css image files
    6. Error.htm (just in case)

    so, usually a fix process to a template is: a. run vcompile (created CompiledViews.dll out of the view templates) b. copy compiledViews.dll to deployment machine.

    Ken Egozi February 7, 2008
  5. Avatar for Damien Guard

    @Steve: Yes, there wasn't a need for a new term. Just saying the code was in a class should have been enough to understand it wasn't inline script.

    @Baggio: Sorted! I'll get there eventually ;-)

    @Ken: That seems like a nice balance. Do you automate the deployment steps with scripts?

    Personally I'd love my web sites and apps to be deployed from a CI server on demand but we're still some way from continuous integration here.

    Damien Guard February 7, 2008
  6. Avatar for steve

    We had a 'semi-continous' integration server setup, in that the codebase was continuously rebuilt and unit tests run against it, but deployment was a separate step. Most CI servers don't operate within the same environment as the 'real' sized production / system test environs so can't 100% recreate it, unless it's very simple or your CI setup has a chunky budget (unlikely if you already have to fund full-size acceptance test environments, unless you're loaded). Stuff like integration with external systems, full-scale tests and even some aspects of web testing can't be done entirely properly by a CI setup, which is usually running on a modest dev box. We also had a strict sign-off system where it shouldn't be possible for a dev to deploy anything to a production server, only ops had that access and they required sign-off from acceptance testers (business stakeholders) first. We had scripts that did the deployment from any release to any server so it was repeatable no matter who was doing it, but we didn't find a decent way of integrating that into a CI setup.

    steve February 7, 2008
  7. Avatar for Dave^2

    I realise you said "classes are typically stored on the web server", but just thought I'd clarify that you don't have to deploy the source with Web Site. There are a number of publishing/precompilation options for Web Sites to avoid having to do this. Regards, David

    Dave^2 February 7, 2008
  8. Avatar for Lucas

    Hi Damien,

    Just wanted to clarify, you make it seem like "web applications" projects were developed after "web sites". As I remember it, web application was the only way in VS2003, and was replaced by web sites in VS2005. I think enough people missed web apps so much that it was released as an add-on to VS2005, included in VS2005 SP1, and later in VS2008.

    Lucas February 7, 2008
  9. Avatar for Lucas

    Oh, and another thing... I enjoy you blog very much. Keep it up ;)

    Lucas February 7, 2008
  10. Avatar for Damien Guard

    @Lucas: I intended on writing something about VS2003 only to find I couldn't remember much about it apart from hacking Class Library projects to behave as a web site you could store locally.

    Thanks for the kind words!

    Damien Guard February 7, 2008
  11. Avatar for Bruce

    Here's a few additional thoughts on both deployment methods:

    Website Method - Con: Very prone to failure due to outside influences. For example, Indexing Server locking the temp dll files which then causes sync issues.

    Web Application Method - Con: Totally dependant on good working practices. It only takes one junior developer failing to use Sourcesafe correctly to take down the whole site rather than just a single page. This is obviously more relevant to smaller development teams. I work in a small team and I've seen it happen more than once :)

    Bruce February 8, 2008
  12. Avatar for Gary

    "Codebehind" refers to the code associated with an aspx page. I guess you could broaden that to all the code in all classes, but I really think it was meant to be more limited. The additional classes are still called "components".

    As for Bruce's comment that the web app method is dependent on good working practices, most of those bugs can be caught in local testing. Once in a while, someone forgets to upload a DLL, and then yes, that only happens with web apps and not web sites.

    Gary August 3, 2011