A few years ago, when I first got a look at asp.net 2.0, it was clear to me that there must have been some serious changes inside the development team at Microsoft. ASP.NET 1.x was a huge leap forward in server side web application frameworks, but it was also geared to an object oriented audience. While it did support direct data access from web pages and everything-in-one-file styles, Visual Studio's use of asp.net encouraged a more tiered design with clean separation of presentation, business, and data access. It also encouraged OO design by making inheritance, namespaces, and assemblies all obvious, simple, and the default way of things.

By the time asp.net 2.0 was coming out, more agile languages were getting all the buzz. PHP was still relevant and Ruby on Rails was shaping up to be the next big contender. By that time Java's JSP, the only other heavy OO platform that still mattered, had fallen flat on its face. So it wasn't exactly a surprise that there was a focus within asp.net 2.0 towards the "less is more" philosophy of quick, dirty, do-what-I-mean design. Codeless databinding, master pages, skins, themes, and configuration driven providers for common stuff like membership, profiles, personalization, etc. were all expected.

But what make several of us step back was the new compilation model and the "project-less" web site... er... project. Aside from being one of the most impossible to name mechanisms, it was also a breaking change in how asp.net was done. The new compilation model threw out the visual studio project file itself, took asp.net back to the "compile-on-the-fly" concept, all but eliminated the use of namespaces within a web site, and radically altered the way UI template and the associated code-behind were arranged.

But for those of us doing serious web frameworks in large or complex environments, the web site model had some serious drawbacks. The biggest for me was having to manually deal with namespaces, which the UI and code designers would fight every step of the way (until you finally gave up and just let it pile up in one big default namespace). The loss of the visual studio project files was also painful, and it lead to an awkward "exclude from project" mechanism where the only way to get Visual Studio to ignore a file was to physically rename it. Large web sites with lots of code suffered horribly in performance because so many helpful visual studio features, like refactoring and the verification compiler had to sift through every file in the project with no guidance from project configuration.

Microsoft seemed to notice the problem, and resurrected the old project model in what they called the "Web Application" Project. This was essentially a retro-fitted clone of the old project model complete with designer generated code files (updated to take advantage of partial classes though). The new project type brought back namespaces, and once again encouraged clean OO design patterns. It also became apparent over a very short time that Microsoft itself would consider the web application model the new "enterprise" project type while the web site project type was more for the beginner and casual developers. For example, Team system's testing, build, and deployment work great with the web application project, but work poorly if at all with web site projects. But the new project type also brought with it the need to compile everything in advance, and used a different mechanism to associate UI and code-behind files that was incompatible with dynamic compilation.

With Visual Studio 2008 Microsoft is keeping both project types. But I think they are missing an opportunity. While the web application project and web site projects both have advantages and disadvantages, there doesn't seem to be a compelling reason for some of the features to be mutually exclusive.

I for one would love to see a hybrid project type. Keep the project file to organize the site and give us a place to put visual studio specific settings. But switch it use the dynamic compilation model from web site projects. Dynamic compilation and xcopy deployment were powerful ideas, and I can't see any reason they can't be used still. The verification compiler can be optimized quite a lot by having access to a project file... exclusions can be dealt with elegantly, and the whole thing can be sped up. For other code though, you could choose to continue to compile to an assembly in advance, or leverage the app_code folder for dynamic compilation, or a combination of both. And of course, keep the namespaces and configurable compiler options.

I'd love to see a web project type that keeps the best of web site and web application projects both. Give me control over the project's structure, namespaces, and compilation but also give me xcopy deployment, dynamic compilation (using my settings), and keep a consistent way of associating an asp.net UI file to its code-behind without requiring the designer generated code file and full compilation.

[http://reddnet.net/code/aspnet-web-site-vs-web-application/]

…

I'll omit a detailed technical description of the differences between web sites and web applications. This territory has been better covered elsewhere on the web, and the MSDN documentation that ships with VS 2008 covers it in detail too.

What most people want to know is, which is better?

The answer does depend a little on personal preference and what kind of application you are building.

I write and maintain several web applications. Some are very small personal sites with mostly static content, while others are huge data entry applications. My largest solution includes about 22 different class library and database projects that support a single web site project.

The web site project has always disappointed me, even with my smaller applications. The Web Application project type has become my preferred approach for all new projects, and I've since converted most of my older web sites to web applications as well.

Web site projects:

Web sites are a little simpler if you are doing inline code instead of code behind. Web sites also reflect changes in code files without needing to be manually compiled. That means you can edit a file and just refresh the browser.

If you need to explicitly "build", so you can ensure your code doesn't have errors for example, you can still do so. However, the "build" command doesn't really compile the project... it just verifies it using the dynamic compiler. While 99% of the time this is fine, I have come across a couple of minor cases where the verification compiler didn't find an error, but attempting to run the site for real did.

Major advantages of web sites:

* Everything in the project's folder is part of the project. This makes it easy to use other editors or tools with web sites. If you add files outside Visual Studio, they will still be part of the project. If you edit a file outside VS it will still be compiled and the changes visible when the site is viewed in a browser.
   
* You can deploy without having to compile... just XCOPY and go. Web sites do support pre-compilation if you choose to use it.
   
* Files don't have to be written in the same language. VS will support having a mix of VB and C# code on a file-by-file basis. Sounds good, but I've never found this useful personally. Maintaining a site is much easier if you stick with one language.
   
* The add "item" dialogs in Visual Studio are more intuitive for web sites. I'm not sure why both projects don't use the same dialogs, but they certainly don't.
   
* Profile's design time compilation is automatic. The ProfileCommon class is created dynamically making it easy to work with the profile provider in a strongly typed way.

The biggest annoyance for me with web sites are:

* No way to really "exclude" a file without renaming it. Refactoring tools and the "compiler" have to crawl through every file in your application. This can get slow if you have a lot of files. For example, I often use FCKEditor, which has a dump-truck load of files. Most of them are not asp.net files. But just having to scan through them when I build or refactor can really slow things down. This has gotten a little better in VS 2008, but not fast enough for my tastes.
   
* No control over your namespaces. Sure, you can manually add namespaces to pretty much anything, but visual studio will fight you every step of the way. With generated code such as ADO.NET DataSets and such, this gets very hard to control. Eventually you will give up and just let VS put everything in the default namespace. In large applications this gets very annoying, especially if you like a well structured application.
   
* It is hard (read, nearly impossible) to reference pages, user controls, etc from custom classes in the app_code folder. This produces some interesting problems if you are doing anything fancy like dynamically loading pages or controls and such.
   
* The application compiles to the asp.net temporary internet files folder. This is a drop location for all that dynamically compiled code that the asp.net compiler will produce. This is a fine mechanism until it breaks. When it breaks you can get really weird errors from the compiler that don't make obvious sense. These are pretty easy to cause by accident. For example, if you tell VS to "build" then refresh a browser pointed at the site at the same time.... the two compiles often conflict in some bizarre manner corrupting the temp asp.net files. When this happens, assuming you figure out that this is the cause of the problem, you have to shut down VS and the web server, manually remove the files from the temp folder, then restart everything.
   
* No ability to product XML comment output files. I use the crap out of XML comments, so this is the big deal breaker for me.
   
* Not much control over build outputs. In most projects you can set whether a file is compiled, copied to the output directory, and such. But not with web sites. If a file is in the project's folder structure, it is part of the project.
   
* Team Build hates web sites. Lacking a project file, you can use the web deployment project add-on to help out, but even still I've found that trying to automate a build for any significantly complex web site is a disaster and time-sink.
* Disconnected Source Control. VS supports working disconnected from source control these days, but I find that it often has problems keeping web sites in sync when you reconnect. This is a sporadic problem, and hard to reproduce, but seems to be more common with delete, rename, and add operations.

The web application project:

The web application project is a little more formal than web sites. You get an actual project file by which Visual Studio tracks the files that are in your project. Web applications do generate "designer" files for your pages that link the code-behind to the controls you've put in the markup, but unlike old VS 2003 projects these are much simpler and leverage partial classes and such.

The drawbacks are:

* The site has to be compiled/built before it will run.
   
* Your project is specific to only one language.
   
* No automatic support for a Profile class. You have to use a separate tool to generate ProfileCommon or write one manually.

The major advantages are:

* Compile and refactoring is much faster since VS has a way to track what is in the project and doesn't have to scan everything in every folder. Also, you can have stuff in the folders that aren't part of the project (I find this useful sometimes). 
   
* You can control namespaces, assembly names, and build behavior for various files in the project. Namespaces are also automatically managed by VS based on the application's folder structure. This includes a real "project properties" editor too with all those familiar things like build options, references, settings, etc.
   
* You can generate XML comment output files.
   
* You can exclude files from the project without having to rename them.
   
* MSBuild and Team Build work much smoother with web application projects.
   
* Custom code files don't have to be in a specific folder, you can put them anywhere and organize them however you see fit.
   
* Classes can refernce pages and controls.
   
* You can split the site into multiple projects.
   
* Include pre and post build steps to compilation.
   
* Disconnected source control seems to work more consistently with web application projects.

The bottom line:

Web applications scale better and are just plain smoother than web sites assuming you plan to do most of your development directly in Visual Studio. The only major difference is that you have to build manually... so get used to CTRL + SHIFT + B. At least it's pretty fast in VS 2008 and it won't blow up the temporary internet files folder like web site projects can.

I can't say that web sites are inferior to web applications overall. There are cases where web sites do work very well, especially with smaller and simpler projects. I just personally don't find that having on-the-fly compilation is really much extra value, while more control over the application's compilation is always a good thing.

[http://reddnet.net/code/asp-net-web-site-vs-web-application-project-part-2/]