Related
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?
Website:
The Web Site project is compiled on the fly. You end up with a lot more DLL files, which can be a pain. It also gives problems when you have pages or controls in one directory that need to reference pages and controls in another directory since the other directory may not be compiled into the code yet. Another problem can be in publishing.
If Visual Studio isn't told to re-use the same names constantly, it will come up with new names for the DLL files generated by pages all the time. That can lead to having several close copies of DLL files containing the same class name,
which will generate plenty of errors. The Web Site project was introduced with Visual Studio 2005, but it has turned out not to be popular.
Web Application:
The Web Application Project was created as an add-in and now exists as part
of SP 1 for Visual Studio 2005. The main differences are the Web Application Project
was designed to work similarly to the Web projects that shipped with Visual Studio 2003. It will compile the application into a single DLL file at build
time. To update the project, it must be recompiled and the DLL file
published for changes to occur.
Another nice feature of the Web Application
project is it's much easier to exclude files from the project view. In the
Web Site project, each file that you exclude is renamed with an excluded
keyword in the filename. In the Web Application Project, the project just
keeps track of which files to include/exclude from the project view without
renaming them, making things much tidier.
Reference
The article ASP.NET 2.0 - Web Site vs Web Application project also gives reasons on why to use one and not the other. Here is an excerpt of it:
You need to migrate large Visual Studio .NET 2003 applications to VS
2005? use the Web Application project.
You want to open and edit any directory as a Web project without
creating a project file? use Web Site
project.
You need to add pre-build and post-build steps during compilation?
use Web Application project.
You need to build a Web application using multiple Web
projects? use the Web Application project.
You want to generate one assembly for each page? use the Web Site project.
You prefer dynamic compilation and working on pages without building
entire site on each page view? use Web
Site project.
You prefer single-page code model to code-behind model? use Web Site
project.
Web Application Projects versus Web Site Projects (MSDN) explains the differences between the web site and web application projects. Also, it discusses the configuration to be made in Visual Studio.
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
Web Site = use when the website is created by graphic designers and the programmers only edit one or two pages
Web Application = use when the application is created by programmers and the graphic designers only edit one or two paged/images.
Web Sites can be worked on using any HTML tools without having to have developer studio, as project files don’t need to be updated, etc. Web applications are best when the team is mostly using developer studio and there is a high code content.
(Some coding errors are found in Web Applications at compile time that are not found in Web Sites until run time.)
Warning: I wrote this answer many years ago and have not used Asp.net since. I expect things have now moved on.
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.
There is an article in MSDN which describes the differences:
Comparing Web Site Projects and Web Application Projects
BTW: there are some similar questions about that topic, e.g:
Web Site vs. ASP.Net Web Application in Visual Studio note: was removed, no longer on SO
website or webapplication in.ASP.NET
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:
Web Application Projects and Web Deployment Projects are here
Web Site or Web Application?
From the MCTS self paced training kit exam 70-515 book:
With web application (project),
You can create an MVC application.
Visual Studio stores the list of files in a project file (.csproj or .vbproj), rather than relying on the folder structure.
You cannot mix Visual Basic and C#.
You cannot edit code without stopping a debugging session.
You can establish dependencies between multiple web projects.
You must compile the application before deployment, which prevents you from testing a page if another page will not compile.
You do not have to store the source code on the server.
You can control the assembly name and version.
You cannot edit individual files after deployment without recompiling.
It depends on what you are developing.
A content-oriented website will have its content changing frequently and a Website is better for that.
An application tends to have its data stored in a database and its pages and code change rarely. In this case it's better to have a Web application where deployment of assemblies is much more controlled and has better support for unit testing.
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.
Yes web application is much better than web sites, because Web applications give us freedom:
To have multiple projects under one umbrella and establish project
dependencies between. E.g. for PCS we can have following within web
application-
Web portals
Notification Controller (for sending Email)
Business layer
Data Access layer
Exception Manager
Server utility
WCF Services (Common for all platforms)
List item
To run unit tests on code that is in the class files that are
associated with ASP.NET pages
To refer to the classes those are
associated with pages and user controls from standalone classes
To create a single assembly for the entire site
Control over the assembly name and version number that is generated for the site
To avoid putting source code on a production server. (You can avoid
deploying source code to the IIS server. In some scenarios, such as
shared hosting environments, you might be concerned about
unauthorized access to source code on the IIS server. (For a web
site project, you can avoid this risk by pre-compiling on a
development computer and deploying the generated assemblies instead
of the source code. However, in that case you lose some of the
benefits of easy site updates.)
Performance Issue with Website(The
first request to the web site might require the site to be compiled,
which can result in a delay. And if the web site is running on an
IIS server that is short on memory, including the entire site in a
single assembly might use more memory than would be required for
multiple assemblies.)
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.
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.
I recommend you watch the video Web Application Projects & Web Deployment Projects on the ASP.NET website which explains the difference in great detail, it was quite helpful to me.
By the way, don't get confused by the title, a great part of the video explains the difference between website projects and web application projects and why Microsoft re-introduced Web application projects in Visual studio 2005 (as you probably already know, it originally shipped with only website projects then web application projects were added in SP1). A great video I highly recommend for anyone who wants to know the difference.
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 and Project>>website are two different methods of creating ASP.NET application using visual studio.
One is projectless and another is project environment. Differences are as
Solution file is stored in same directory as root directory in project environment.
Need to remove solution and project files before deploying in project environment.
Complete root directory is deployed in projectless environment.
there no much basic difference in using either approach. But if you are creating website that will take longer time, opt for project environment.
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.
It is always depends on the requirement of your client. ASP.NET just includes flexible features that the user needs for security and easy maintenance of your application.
You can think of a Web application as a binary file that runs inside the ASP.NET framework. And Web sites as a static webpage that you can review and easily deploy source code to.
But the advantage and disadvantages of these two ASP.NET technologies come what is good.
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.
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.
In Web Application Projects, Visual Studio needs additional .designer files for pages and user controls. Web Site Projects do not require this overhead. The markup itself is interpreted as the design.
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.
Definitely web application, single DLL file and easy to maintain. But a website is more flexible; you can edit the aspx file on the go.
Web applications require more memory, presumably because you have no choice but to compile into a single assembly. I just converted a large legacy site to a web application and have issues with running out of memory, both at compile time with the error message as below :
Unexpected error writing metadata to file '' --
Not enough storage is available to complete this operation.
error, and at runtime with this error message as below :
Exception information:
Exception type: HttpException
Exception message: Exception of type 'System.OutOfMemoryException' was thrown.
at System.Web.Compilation.BuildManager.ReportTopLevelCompilationException()
My recommendation for converting larger sites on memory-constrained legacy hardware is, to choose the option to revert back to the web site model. Even after an initial success problem might creep up later.
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.
To summarize some of the answers above:
Flexibility, can you can make live changes to a web page?
Web Site: Possible. Pro: short term benefits. Con: long term risk of project chaos.
Web App: Con: not possible. Edit a page, archive the changes to source control, then build and deploy the entire site. Pro: maintain a quality project.
Development issues
Web Site: Simple project structure without a .csproj file.Two .aspx pages may have the same class name without conflicts. Random project directory name leading to build errors like why .net framework conflicts with its own generated file and why .net framework conflicts with its own generated file. Pro: Simple (simplistic). Con: erratic.
Web App: Project structure similar to WebForms project, with a .csproj file. Class names of asp pages must be unique. Pro: Simple (smart). Con: none, because a web app is still simple.
I'd like to add MVC support to an existing Website project (not a Web application project) and have a few questions.
To get Visual Studio's MVC goodness, it appears that I need to update the .csproj file's <ProjectTypeGuids> node. There is no csproj file in a website project.
It appears that I need to create Models and Controllers folder in the App_Code. Is this true? I prefer having these folders under root.
For Views should I be creating a aspx and aspx.cs files? Is cshtml razor files supported in this kind of a setup?
Any other responses are appreciated. Thanks
With asp.net MVC2 and above, the MVC team separated the core functionality into
three different assemblies, each of which extends from the common System.Web assembly:
System.Web.Routing
System.Web.Abstractions
System.Web.Mvc
With this seperation, they went ahead and made the assemblies to "work in Medium-trust server enviroments and be bin-deployable".
One of the good things about this featuere is, you don't have to have a specific project type to run MVC. You only need the assemblies, some directories and a tweaked web.config.
To do this, you need only to place the assemblies in your local bin folder of your project and make the necessary references for those assemblies.
Once this is done, you have access to asp.net MVC.
Here are some detailed instructions from the Wrox Professional ASP.NET MVC 1.0 book which should help you get started:
Including MVC in Existing Web Forms Applications
Adding ASP.NET MVC functionality to an existing Web Forms application is comprised of three
different steps:
1. Add a reference to the three core libraries that ASP.NET MVC needs: System.Web.Mvc, System.Web.Routing, and System.Web.Abstractions.
2. Add two directories to your application: Controllers and Views.
3. Update the Web.config to load the three assemblies at run time as well as registering the UrlRoutingModule HttpModule.
For reference, here are a couple of blogs/sites which have some more detailed scenarios which might help you out:
Mixing ASP.NET Webforms and ASP.NET MVC
ASP.NET WebForms and ASP.NET MVC in Harmony
Good luck, and hope this helps you out some.
I've successfully added a ASP.NET MVC 3 to Webforms project and here are some suggestions:
Add Controllers as a separate class library project and add a reference to this project from the Web forms web project
I attempted to get VS MVC support (like goto controller etc), but adding the GUID {E53F8FEA-EAE0-44A6-8774-FFD645390401} to the .csproj file didn't help.
Yes, you can add references to get the Session from your class library. You can always mock it out if you want to write unit tests.
Add Views folder to the root
Add Models within App_Code
If you are using Razor, then you need to add System.Web.Razor and System.Web.WebPages references
If you are using Razor, update the Web.config per this post
Keep in mind, you can add server controls to your view as long as they don't use postbacks (I had a lot of server controls from my webforms project that I had to use)
I believe if you set up a new MVC project and copy your web forms across to the new project, they will render as expected.
I haven't experimented with this too much but I have tried in the past out of curiosity and the web forms were still rendered OK. I guess it depends on the complexity of your project as to whether this approach would work.
This would involve changing your project type.
I have seen this work in the past if you place a Global.asax file in the root of your website. You'll need a way for your project to recognize and differentiate MVC requests from standard requests, like this:
public static void RegisterRoutes(RouteCollection routes)
{
routes.MapRoute("Default",
"{controller}.mvc/{action}/{id}",
new { controller = "Home", action = "Index", id = "" }
);
}
So, an MVC url in your app might look like: http://www.mywebsite.com/mycontroller.mvc/View/5
I was tasked with updating (but unfortunately not re-writing) a legacy .Net 3.5, VB.NET (ughh) webforms, web site project and I successfully upgraded to 4.0 and added MVC3 support (with seperate code compliation folders to support C#, yah!), and it works just fine.
The #DotnetDude instructions do work, but be careful of a couple of things...
(1) When adding Razor support, this is done in the Views/Web.config file not the web.config file in the root of your project.
(2) If you do happen to add a Razor file (.chtml or .vbhtml) OUTSIDE of the Views directory, vs.net will update your root web.config with the following value
<appSettings>
<add key="webpages:Enabled" value="true" />
</appSettings>
Not good. This setting is to allow direct browsing of razor pages and when set to TRUE in my case, caused everything to break. That being said, I'm only using razor pages in my Views subfolder, however what I found nice is making AJAX calls from my .aspx pages to a controller defined in the App_Code directory allowing me to modernize an app that was mostly all postbacks, and C# to access the VB.NET written data layer.
ASP.NET MVC does not support web site template, it can only be Web Application. So you can not add MVC functionality to Web Forms project.
The title pretty much says it all.
Given a web site project in VS2008 named FooDLL, I would like to be able to specify the name of the assembly that VS2008 spits out when I click "Publish Web Site". I am using the "use fixed naming and single page assemblies" option, so the resulting DLL is consistently named.
However, I would much rather be able to specify that the DLL is named something like FooDLL.dll (or just Foo.dll, whatever) than be stuck with the ugliness of App_Web_foo.ascx.cdcab7d2.dll.
Am I stuck since Web Sites don't have .project files (e.g. aren't projects)?
Not to continue the pattern of answering my own questions, but here it is anyway:
All I had to do was add a Web Deployment Project for the web site containing my user control. Though you can't specify the assembly name when building/publishing a web site, you can do this through the web deployment project. It's basically just a nice GUI for an msbuild project file... for a web site. Hooray for hacking a .project file onto a web site!
You could just compile your code as a class library project, then drop it into the Bin directory of your website.
I believe you are.
I am unaware of any benefits to using a web site project and while the benefits of using a web application project are minor, they exist. Create web application projects from now on.
ASP.NET Merge Tool (Aspnet_merge.exe) is your way to go.
It merge your web assemblies into one assembly for the whole Web site.
more information:
http://msdn.microsoft.com/en-us/library/bb397866.aspx
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?
Website:
The Web Site project is compiled on the fly. You end up with a lot more DLL files, which can be a pain. It also gives problems when you have pages or controls in one directory that need to reference pages and controls in another directory since the other directory may not be compiled into the code yet. Another problem can be in publishing.
If Visual Studio isn't told to re-use the same names constantly, it will come up with new names for the DLL files generated by pages all the time. That can lead to having several close copies of DLL files containing the same class name,
which will generate plenty of errors. The Web Site project was introduced with Visual Studio 2005, but it has turned out not to be popular.
Web Application:
The Web Application Project was created as an add-in and now exists as part
of SP 1 for Visual Studio 2005. The main differences are the Web Application Project
was designed to work similarly to the Web projects that shipped with Visual Studio 2003. It will compile the application into a single DLL file at build
time. To update the project, it must be recompiled and the DLL file
published for changes to occur.
Another nice feature of the Web Application
project is it's much easier to exclude files from the project view. In the
Web Site project, each file that you exclude is renamed with an excluded
keyword in the filename. In the Web Application Project, the project just
keeps track of which files to include/exclude from the project view without
renaming them, making things much tidier.
Reference
The article ASP.NET 2.0 - Web Site vs Web Application project also gives reasons on why to use one and not the other. Here is an excerpt of it:
You need to migrate large Visual Studio .NET 2003 applications to VS
2005? use the Web Application project.
You want to open and edit any directory as a Web project without
creating a project file? use Web Site
project.
You need to add pre-build and post-build steps during compilation?
use Web Application project.
You need to build a Web application using multiple Web
projects? use the Web Application project.
You want to generate one assembly for each page? use the Web Site project.
You prefer dynamic compilation and working on pages without building
entire site on each page view? use Web
Site project.
You prefer single-page code model to code-behind model? use Web Site
project.
Web Application Projects versus Web Site Projects (MSDN) explains the differences between the web site and web application projects. Also, it discusses the configuration to be made in Visual Studio.
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
Web Site = use when the website is created by graphic designers and the programmers only edit one or two pages
Web Application = use when the application is created by programmers and the graphic designers only edit one or two paged/images.
Web Sites can be worked on using any HTML tools without having to have developer studio, as project files don’t need to be updated, etc. Web applications are best when the team is mostly using developer studio and there is a high code content.
(Some coding errors are found in Web Applications at compile time that are not found in Web Sites until run time.)
Warning: I wrote this answer many years ago and have not used Asp.net since. I expect things have now moved on.
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.
There is an article in MSDN which describes the differences:
Comparing Web Site Projects and Web Application Projects
BTW: there are some similar questions about that topic, e.g:
Web Site vs. ASP.Net Web Application in Visual Studio note: was removed, no longer on SO
website or webapplication in.ASP.NET
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:
Web Application Projects and Web Deployment Projects are here
Web Site or Web Application?
From the MCTS self paced training kit exam 70-515 book:
With web application (project),
You can create an MVC application.
Visual Studio stores the list of files in a project file (.csproj or .vbproj), rather than relying on the folder structure.
You cannot mix Visual Basic and C#.
You cannot edit code without stopping a debugging session.
You can establish dependencies between multiple web projects.
You must compile the application before deployment, which prevents you from testing a page if another page will not compile.
You do not have to store the source code on the server.
You can control the assembly name and version.
You cannot edit individual files after deployment without recompiling.
It depends on what you are developing.
A content-oriented website will have its content changing frequently and a Website is better for that.
An application tends to have its data stored in a database and its pages and code change rarely. In this case it's better to have a Web application where deployment of assemblies is much more controlled and has better support for unit testing.
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.
Yes web application is much better than web sites, because Web applications give us freedom:
To have multiple projects under one umbrella and establish project
dependencies between. E.g. for PCS we can have following within web
application-
Web portals
Notification Controller (for sending Email)
Business layer
Data Access layer
Exception Manager
Server utility
WCF Services (Common for all platforms)
List item
To run unit tests on code that is in the class files that are
associated with ASP.NET pages
To refer to the classes those are
associated with pages and user controls from standalone classes
To create a single assembly for the entire site
Control over the assembly name and version number that is generated for the site
To avoid putting source code on a production server. (You can avoid
deploying source code to the IIS server. In some scenarios, such as
shared hosting environments, you might be concerned about
unauthorized access to source code on the IIS server. (For a web
site project, you can avoid this risk by pre-compiling on a
development computer and deploying the generated assemblies instead
of the source code. However, in that case you lose some of the
benefits of easy site updates.)
Performance Issue with Website(The
first request to the web site might require the site to be compiled,
which can result in a delay. And if the web site is running on an
IIS server that is short on memory, including the entire site in a
single assembly might use more memory than would be required for
multiple assemblies.)
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.
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.
I recommend you watch the video Web Application Projects & Web Deployment Projects on the ASP.NET website which explains the difference in great detail, it was quite helpful to me.
By the way, don't get confused by the title, a great part of the video explains the difference between website projects and web application projects and why Microsoft re-introduced Web application projects in Visual studio 2005 (as you probably already know, it originally shipped with only website projects then web application projects were added in SP1). A great video I highly recommend for anyone who wants to know the difference.
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 and Project>>website are two different methods of creating ASP.NET application using visual studio.
One is projectless and another is project environment. Differences are as
Solution file is stored in same directory as root directory in project environment.
Need to remove solution and project files before deploying in project environment.
Complete root directory is deployed in projectless environment.
there no much basic difference in using either approach. But if you are creating website that will take longer time, opt for project environment.
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.
It is always depends on the requirement of your client. ASP.NET just includes flexible features that the user needs for security and easy maintenance of your application.
You can think of a Web application as a binary file that runs inside the ASP.NET framework. And Web sites as a static webpage that you can review and easily deploy source code to.
But the advantage and disadvantages of these two ASP.NET technologies come what is good.
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.
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.
In Web Application Projects, Visual Studio needs additional .designer files for pages and user controls. Web Site Projects do not require this overhead. The markup itself is interpreted as the design.
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.
Definitely web application, single DLL file and easy to maintain. But a website is more flexible; you can edit the aspx file on the go.
Web applications require more memory, presumably because you have no choice but to compile into a single assembly. I just converted a large legacy site to a web application and have issues with running out of memory, both at compile time with the error message as below :
Unexpected error writing metadata to file '' --
Not enough storage is available to complete this operation.
error, and at runtime with this error message as below :
Exception information:
Exception type: HttpException
Exception message: Exception of type 'System.OutOfMemoryException' was thrown.
at System.Web.Compilation.BuildManager.ReportTopLevelCompilationException()
My recommendation for converting larger sites on memory-constrained legacy hardware is, to choose the option to revert back to the web site model. Even after an initial success problem might creep up later.
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.
To summarize some of the answers above:
Flexibility, can you can make live changes to a web page?
Web Site: Possible. Pro: short term benefits. Con: long term risk of project chaos.
Web App: Con: not possible. Edit a page, archive the changes to source control, then build and deploy the entire site. Pro: maintain a quality project.
Development issues
Web Site: Simple project structure without a .csproj file.Two .aspx pages may have the same class name without conflicts. Random project directory name leading to build errors like why .net framework conflicts with its own generated file and why .net framework conflicts with its own generated file. Pro: Simple (simplistic). Con: erratic.
Web App: Project structure similar to WebForms project, with a .csproj file. Class names of asp pages must be unique. Pro: Simple (smart). Con: none, because a web app is still simple.
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?
Website:
The Web Site project is compiled on the fly. You end up with a lot more DLL files, which can be a pain. It also gives problems when you have pages or controls in one directory that need to reference pages and controls in another directory since the other directory may not be compiled into the code yet. Another problem can be in publishing.
If Visual Studio isn't told to re-use the same names constantly, it will come up with new names for the DLL files generated by pages all the time. That can lead to having several close copies of DLL files containing the same class name,
which will generate plenty of errors. The Web Site project was introduced with Visual Studio 2005, but it has turned out not to be popular.
Web Application:
The Web Application Project was created as an add-in and now exists as part
of SP 1 for Visual Studio 2005. The main differences are the Web Application Project
was designed to work similarly to the Web projects that shipped with Visual Studio 2003. It will compile the application into a single DLL file at build
time. To update the project, it must be recompiled and the DLL file
published for changes to occur.
Another nice feature of the Web Application
project is it's much easier to exclude files from the project view. In the
Web Site project, each file that you exclude is renamed with an excluded
keyword in the filename. In the Web Application Project, the project just
keeps track of which files to include/exclude from the project view without
renaming them, making things much tidier.
Reference
The article ASP.NET 2.0 - Web Site vs Web Application project also gives reasons on why to use one and not the other. Here is an excerpt of it:
You need to migrate large Visual Studio .NET 2003 applications to VS
2005? use the Web Application project.
You want to open and edit any directory as a Web project without
creating a project file? use Web Site
project.
You need to add pre-build and post-build steps during compilation?
use Web Application project.
You need to build a Web application using multiple Web
projects? use the Web Application project.
You want to generate one assembly for each page? use the Web Site project.
You prefer dynamic compilation and working on pages without building
entire site on each page view? use Web
Site project.
You prefer single-page code model to code-behind model? use Web Site
project.
Web Application Projects versus Web Site Projects (MSDN) explains the differences between the web site and web application projects. Also, it discusses the configuration to be made in Visual Studio.
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
Web Site = use when the website is created by graphic designers and the programmers only edit one or two pages
Web Application = use when the application is created by programmers and the graphic designers only edit one or two paged/images.
Web Sites can be worked on using any HTML tools without having to have developer studio, as project files don’t need to be updated, etc. Web applications are best when the team is mostly using developer studio and there is a high code content.
(Some coding errors are found in Web Applications at compile time that are not found in Web Sites until run time.)
Warning: I wrote this answer many years ago and have not used Asp.net since. I expect things have now moved on.
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.
There is an article in MSDN which describes the differences:
Comparing Web Site Projects and Web Application Projects
BTW: there are some similar questions about that topic, e.g:
Web Site vs. ASP.Net Web Application in Visual Studio note: was removed, no longer on SO
website or webapplication in.ASP.NET
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:
Web Application Projects and Web Deployment Projects are here
Web Site or Web Application?
From the MCTS self paced training kit exam 70-515 book:
With web application (project),
You can create an MVC application.
Visual Studio stores the list of files in a project file (.csproj or .vbproj), rather than relying on the folder structure.
You cannot mix Visual Basic and C#.
You cannot edit code without stopping a debugging session.
You can establish dependencies between multiple web projects.
You must compile the application before deployment, which prevents you from testing a page if another page will not compile.
You do not have to store the source code on the server.
You can control the assembly name and version.
You cannot edit individual files after deployment without recompiling.
It depends on what you are developing.
A content-oriented website will have its content changing frequently and a Website is better for that.
An application tends to have its data stored in a database and its pages and code change rarely. In this case it's better to have a Web application where deployment of assemblies is much more controlled and has better support for unit testing.
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.
Yes web application is much better than web sites, because Web applications give us freedom:
To have multiple projects under one umbrella and establish project
dependencies between. E.g. for PCS we can have following within web
application-
Web portals
Notification Controller (for sending Email)
Business layer
Data Access layer
Exception Manager
Server utility
WCF Services (Common for all platforms)
List item
To run unit tests on code that is in the class files that are
associated with ASP.NET pages
To refer to the classes those are
associated with pages and user controls from standalone classes
To create a single assembly for the entire site
Control over the assembly name and version number that is generated for the site
To avoid putting source code on a production server. (You can avoid
deploying source code to the IIS server. In some scenarios, such as
shared hosting environments, you might be concerned about
unauthorized access to source code on the IIS server. (For a web
site project, you can avoid this risk by pre-compiling on a
development computer and deploying the generated assemblies instead
of the source code. However, in that case you lose some of the
benefits of easy site updates.)
Performance Issue with Website(The
first request to the web site might require the site to be compiled,
which can result in a delay. And if the web site is running on an
IIS server that is short on memory, including the entire site in a
single assembly might use more memory than would be required for
multiple assemblies.)
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.
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.
I recommend you watch the video Web Application Projects & Web Deployment Projects on the ASP.NET website which explains the difference in great detail, it was quite helpful to me.
By the way, don't get confused by the title, a great part of the video explains the difference between website projects and web application projects and why Microsoft re-introduced Web application projects in Visual studio 2005 (as you probably already know, it originally shipped with only website projects then web application projects were added in SP1). A great video I highly recommend for anyone who wants to know the difference.
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 and Project>>website are two different methods of creating ASP.NET application using visual studio.
One is projectless and another is project environment. Differences are as
Solution file is stored in same directory as root directory in project environment.
Need to remove solution and project files before deploying in project environment.
Complete root directory is deployed in projectless environment.
there no much basic difference in using either approach. But if you are creating website that will take longer time, opt for project environment.
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.
It is always depends on the requirement of your client. ASP.NET just includes flexible features that the user needs for security and easy maintenance of your application.
You can think of a Web application as a binary file that runs inside the ASP.NET framework. And Web sites as a static webpage that you can review and easily deploy source code to.
But the advantage and disadvantages of these two ASP.NET technologies come what is good.
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.
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.
In Web Application Projects, Visual Studio needs additional .designer files for pages and user controls. Web Site Projects do not require this overhead. The markup itself is interpreted as the design.
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.
Definitely web application, single DLL file and easy to maintain. But a website is more flexible; you can edit the aspx file on the go.
Web applications require more memory, presumably because you have no choice but to compile into a single assembly. I just converted a large legacy site to a web application and have issues with running out of memory, both at compile time with the error message as below :
Unexpected error writing metadata to file '' --
Not enough storage is available to complete this operation.
error, and at runtime with this error message as below :
Exception information:
Exception type: HttpException
Exception message: Exception of type 'System.OutOfMemoryException' was thrown.
at System.Web.Compilation.BuildManager.ReportTopLevelCompilationException()
My recommendation for converting larger sites on memory-constrained legacy hardware is, to choose the option to revert back to the web site model. Even after an initial success problem might creep up later.
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.
To summarize some of the answers above:
Flexibility, can you can make live changes to a web page?
Web Site: Possible. Pro: short term benefits. Con: long term risk of project chaos.
Web App: Con: not possible. Edit a page, archive the changes to source control, then build and deploy the entire site. Pro: maintain a quality project.
Development issues
Web Site: Simple project structure without a .csproj file.Two .aspx pages may have the same class name without conflicts. Random project directory name leading to build errors like why .net framework conflicts with its own generated file and why .net framework conflicts with its own generated file. Pro: Simple (simplistic). Con: erratic.
Web App: Project structure similar to WebForms project, with a .csproj file. Class names of asp pages must be unique. Pro: Simple (smart). Con: none, because a web app is still simple.