ASP.NET Web Site or ASP.NET Web Application?


11 Answers

Web Site is what you deploy to an ASP.NET web server such as IIS. Just a bunch of files and folders. There’s nothing in a Web Site that ties you to Visual Studio (there’s no project file). Code-generation and compilation of web pages (such as .aspx, .ascx, .master) is done dynamically at runtime, and changes to these files are detected by the framework and automatically re-compiled. You can put code that you want to share between pages in the special App_Code folder, or you can pre-compile it and put the assembly in the Bin folder.

Web Application is a special Visual Studio project. The main difference with Web Sites is that when you build the project all the code files are compiled into a single assembly, which is placed in the bin directory. You don’t deploy code files to the web server. Instead of having a special folder for shared code files you can put them anywhere, just like you would do in class library. Because Web Applications contains files that are not meant to be deployed, such as project and code files, there’s a Publish command in Visual Studio to output a Web Site to a specified location.

App_Code vs Bin

Deploying shared code files is generally a bad idea, but that doesn’t mean you have to choose Web Application. You can have a Web Site that references a class library project that holds all the code for the Web Site. Web Applications is just a convenient way to do it.

CodeBehind

This topic is specific to .aspx and .ascx files. This topic is decreasingly relevant in new application frameworks such as ASP.NET MVC and ASP.NET Web Pages which do not use codebehind files.

By having all code files compiled into a single assembly, including codebehind files of .aspx pages and .ascx controls, in Web Applications you have to re-build for every little change, and you cannot make live changes. This can be a real pain during development, since you have to keep re-building to see the changes, while with Web Sites changes are detected by the runtime and pages/controls are automatically recompiled.

Having the runtime manage the codebehind assemblies is less work for you, since you don't need to worry about giving pages/controls unique names, or organizing them into different namespaces.

I’m not saying deploying code files is always a good idea (specially not in the case of shared code files), but codebehind files should only contain code that perform UI specific tasks, wire-up events handlers, etc. Your application should be layered so that important code always end up in the Bin folder. If that is the case then deploying codebehind files shouldn't be considered harmful.

Another limitation of Web Applications is that you can only use the language of the project. In Web Sites you can have some pages in C#, some in VB, etc. No need for special Visual Studio support. That’s the beauty of the build provider extensibility.

Also, in Web Applications you don't get error detection in pages/controls as the compiler only compiles your codebehind classes and not the markup code (in MVC you can fix this using the MvcBuildViews option), which is compiled at runtime.

Visual Studio

Because Web Applications are Visual Studio projects you get some features not available in Web Sites. For instance, you can use build events to perform a variety of tasks, e.g. minify and/or combine Javascript files.

Another nice feature introduced in Visual Studio 2010 is Web.config transformation. This is also not available in Web Sites. Now works with Web Sites in VS 2013.

Building a Web Application is faster than building a Web Site, specially for large sites. This is mainly because Web Applications do not compile the markup code. In MVC if you set MvcBuildViews to true then it compiles the markup code and you get error detection, which is very useful. The down side is that every time you build the solution it builds the complete site, which can be slow and inefficient, specially if you are not editing the site. l find myself turning MvcBuildViews on and off (which requires a project unload). On the other hand, with Web Sites you can choose if you want to build the site as part of the solution or not. If you choose not to, then building the solution is very fast, and you can always click on the Web Site node and select Build, if you’ve made changes.

In an MVC Web Application project you have extra commands and dialogs for common tasks, like ‘Add View’, ‘Go To View’, ‘Add Controller’, etc. These are not available in an MVC Web Site.

If you use IIS Express as the development server, in Web Sites you can add virtual directories. This option is not available in Web Applications.

NuGet Package Restore does not work on Web Sites, you have to manually install packages listed on packages.config Package Restore now works with Web Sites starting NuGet 2.7

Question

When I start a new ASP.NET project in Visual Studio, I can create an ASP.NET Web Application or I can create an ASP.NET Web Site.

What is the difference between ASP.NET Web Application and ASP.NET Web Site? Why would I choose one over other?

Is the answer different based on which version of Visual Studio I am using?




Web Application project model

  • Provides the same Web project semantics as Visual Studio .NET Web projects. Has a project file (structure based on project files). Build model - all code in the project is compiled into a single assembly. Supports both IIS and the built-in ASP.NET Development Server. Supports all the features of Visual Studio 2005 (refactoring, generics, etc.) and of ASP.NET (master pages, membership and login, site navigation, themes, etc). Using FrontPage Server Extensions (FPSE) are no longer a requirement.

Web Site project model

  • No project file (Based on file system).
  • New compilation model.
  • Dynamic compilation and working on pages without building entire site on each page view.
  • Supports both IIS and the built-in ASP.NET Development Server.
  • Each page has it's own assembly.
  • Defferent code model.



One of the key differences is that Websites compile dynamically and create on-the-fly assemblies. Web applicaitons compile into one large assembly.

The distinction between the two has been done away with in Visual Studio 2008.




Websites - No solution file will be created. If we want to create websites no need for visual studio.

Web Application - A solution file will be created. If we want to create web application should need the visual studio. It will create a single .dll file in bin folder.




Compilation Firstly there is a difference in compilation. Web Site is not pre-compiled on server, it is compiled on file. It may be an advantage because when you want to change something in your Web Site you can just download a specific file from server, change it and upload this file back to server and everything would work fine. In Web Application you can't do this because everthing is pre-compiled and you end up with only one dll. When you change something in one file of your project you have to re-compile everything again. So if you would like to have a possibility to change some files on server Web Site is better solution for you. It also allows many developers to work on one Web Site. On the other side, if you don't want your code to be available on server you should rather choose Web Application. This option is also better for Unit Testing because of one DLL file being created after publishing your website.

Project structure There is also a difference in the structure of the project. In Web Application you have a project file just like you had it in normal application. In Web Site there is no traditional project file, all you have is solution file. All references and settings are stored in web.config file. @Page directive There is a different attribute in @Page directive for the file that contains class associated with this page. In Web Application it is standard "CodeBehind", in Web Site you use "CodeFile". You can see this in the examples below:

Web Application:

<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Default.aspx.cs"  
Inherits="WebApplication._Default" %>  

Web Site:

<%@ Page Language="C#" AutoEventWireup="true" CodeFile="Default.aspx.cs" Inherits="_Default" %> 

Namespaces - In the example above you can see also another difference - how namespaces are created. In Web Application namespace is simply a name of the project. In Website there is default namespace ASP for dynamically compiled pages.

Edit and Continue- In Web Application Edit and Continue option is available (to turn it on you have to go to Tools Menu, click Options then find Edit and Continue in Debugging). This feature is not working in Web Site.ASP.NET MVCIf you want to develop web applications using

ASP.NET MVC (Model View Controller) the best and default option is Web Application. Although it's possible to use MVC in Web Site it's not recommended.

Summary - The most important difference between ASP.NET Web Application and Web Site is compilation. So if you work on a bigger project where a few people can modify it it's better to use Web Site. But if you're doing a smaller project you can use Web Application as well.




In a web application you can create the layers of your project's functionality and can create inter-dependencies between them by dividing it into many projects, but you can never do this on a website.




A "web site" has its code in a special App_Code directory and it's compiled into several DLLs (assemblies) at runtime. A "web application" is precompiled into one single DLL.




WebSite : It generates app_code folder automatically and if you publish it on the server and after that if you do some changes in any particular file or page than you don't have to do compile all files.

Web Application It generates solutions file automatically which website doesn't generate and if you change in one file than you have to compile full project to reflects its changes.




This may sound a bit obvious, but I think it's something that is misunderstood because Visual Studio 2005 only shipped with the web site originally. If your project deals with a website that is fairly limited and doesn't have a lot of logical or physical separation, the website is fine. However if it is truly a web application with different modules where many users add and update data, you are better off with the web application.

The biggest pro of the website model is that anything in the app_code section is dynamically compiled. You can make C# file updates without a full redeploy. However this comes at a great sacrifice. A lot of things happen under the covers that are difficult to control. Namespaces are difficult to control and specific DLL usage goes out the window by default for anything under app_code since everything is dynamically compiled.

The web application model does not have dynamic compilation, but you gain control over the things that I have mentioned.

If you are doing n-tier development, I highly recommend the web application model. If you are doing a limited web site or a quick and dirty implementation, the web site model may have advantages.

More detailed analysis can be found in:




Applications are usually compiled before deployment where as the website makes use of the app_code directory. When anything changes in the app code folder the server will re-compile the code. This means that you can add/ change code with a website on the fly.

The advantage of an app is that there is no re-compiling and so initial start up times will be faster.




Here Web Supportive Application is an example of website. Website and Web Application both can be dynamic/static its depends upon requirements, here is an example to understand working of website's and web application.




Unless you have a specific need for a dynamically compiled project, don't use a web site project.

Why? Because web site project will drive you up the wall when trying to change or understand your project. The static typing find features (e.g. find usages, refactor) in Visual Studio will all take forever on any reasonably sized project. For further information, see the Stack Overflow question Slow “Find All References” in Visual Studio.

I really can't see why they dropped web applications in Visual Studio 2005 for the pain-inducing, sanity-draining, productivity carbuncle web site project type.




Related