When I start a new ASP.NET project in Visual Studio 2008, I can either create a new ASP.NET Web Site or an ASP.NET Web Application.
What's the difference between these two project types? Why would I choose one over the other?
If I'm using Visual Studio 2005 instead of Visual Studio 2008, is the answer different?
If I'm using Visual Studio 2010, is the answer different?
Web sites are dynamically compiled and source is distributed with them. Web Applications can be compiled into a single DLL and deployed.
You cannot use the app_code folder in WAP projects, but you can with WSP.
There is a bit of MSDN documentation between WAP/WSP.
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 code yet. Another problem can be in publishing.
If VS 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 dlls containing the same class name, which will generate plenty of errors. The Web Site project was introduced with VS 2005, but has turned out not to be extremely popular.
Web Application:
The Web Application Project was created as an add-in and now exists as part of SP 1 for VS 2005. The main differences are the Web Application Project was designed to work similar to the Web projects that shipped with VS.net and VS 2003. It will compile the application into a single dll at build time. In order to update the project it must be recompiled and the dll published for changes to occur.
Another nice feature of the Web Application project is it's much easer to exclude files from the project view. In the Web Site project, each file that you exclude is renamed with an exclude 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 tider.
This article 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 Web Application project.
- You want to generate one assembly for each page? use 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.
This may sound a bit obvious, but I think it's something that is misunderstood because VS2005 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 cs 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 nTier 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 here:
http://west-wind.com/weblog/posts/5601.aspx
http://blogs.vertigo.com/personal/swarren/Blog/Lists/Posts/Post.aspx?ID=10
Here is a post I put out that may answer your question:
http://www.codersbarn.com/post/2008/06/01/ASPNET-Web-Site-versus-Web-Application-Project.aspx
In short, stick to the Web Application project if you're doing any serious work.
Anthony :-)
Web Site = use when the website is created by graphic designers and the programmers only edits 1 or 2 pages
Web Application = use when the application is created by programmers and the graphic designers only edit 1 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.
I seriously do not understand the benefits of Web application projects.
Building everything into one assembly means 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 Websites changes are detected by the runtime and pages/controls are automatically recompiled.
Web application projects do not support custom build providers, so you cannot use other languages like php, ruby, python or whatever language you invented (http://msdn.microsoft.com/en-us/library/system.web.compilation.buildprovider.aspx).
"You end up with a lot more DLL files, which can be a pain"
Actually, you don't manage those DLL's, they are placed in %windir%\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\, you don't even have to know they exists. Not an issue.
Having the runtime manage the assemblies is actually less work for you, since you don't need to worry about giving pages/controls unique names, or organizing them into different namespaces.
Dynamic compilation is also used with Web application projects, for things like Page and OutputCache directives, these are parsed by the .aspx build provider which generates a class that inherits from the pre-compiled webapp page class.
"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 code yet."
This is not a problem because the framework supports this scenario. In pages/controls, you use the Reference directive.
In Web application projects you don't get error detection in pages/controls as the compiler only compiles your codebehind classes and not the markup code.
In Websites every file and directory is part of the website that get's deployed, which is very transparent, you are working with THE website, not a project that WILL PRODUCE a website. In Web applications you need an additional 'Publish' step.
Websites and dynamic compilation are the core of ASP.NET, Web applications is just an abstraction used to fit the Visual Studio project paradigm. In the end what ASP.NET parses and executes are websites.
If you are into MVC or separation of concerns, putting your templates, images and css into the same project as your model, data-access, bussines logic, is wrong. On the other hand, if you want to put everything into one project web application is obviously better.
Some details from Apress – Pro ASP.NET 3.5 in C# 2008 Second Edition
One thing to watch out for is that Website projects are difficult to build with MSBuild. You will only come up against this is if you are planning to automate the build which has always worked extremely well for me.
One additional benefit of the Web Application is that it produces a DLL suitable for static analysis. Trying to use tools like NDepend on a Web Site project is not fun.
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 VS will all take forever on any reasonably size project. For further information, see the the SO question: Slow “Find All References” in Visual Studio
I really can't see why they dropped web applications in VS2005 for the pain-inducing, sanity-draining, productivity carbuncle web site project type.
Continuous integration was much simpler for me when using Web Application projects. I've tried both, and the website required jumping through some hoops with Cruise Control.Net.
Chek out the article I wrote dedicated to the differences between Web Application Projects vs Web Site Projects at http://vishaljoshi.blogspot.com/2009/08/web-application-project-vs-web-site.html -Vishal
This is an old question but in case anybody is reading and wants to know the difference, I recommend you watch this video on asp.net website which explains the difference in great detail, it was quite helpful to me.
Web Application Projects & Web Deployment Projects
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.
I have an interesting scenario: - Site has 209,000+ pages. - Evertime a user submits a new article/item a new page is generated and if it has a refernece to one of the existing pages then that page is also re-generated and saved. - A windows service is looking after the generation of pages which creates a page(file) in the site directory. - The purpose of pre-generated pages was to save requesting data from the database as 75% times data will never be updated and having a pre-generated file on the FS saves processing and memory.
It has been working very well but we are concerned now...
The problem is the disk space is running out and if we restart the server it takes a while for site to compile and run and as volume increases we think this will cause us serious problems.
Is there a way to have pre-compiled site and we can still generate pages? (the generated pages all inherit from one class and they have custom controls)
Any suggestions?