When VS 2005 was released I re-wrote my web site using the new "Web Site" project type.

Since then a lot of people have migrated from the new "Web Site" project type back to the old "Web Application" project type, so many that Scott Guthrie wrote a downgrade guide.  I've decided to stick with the Web Site project type.  Many would question this choice.  Before explaining the reason for my decision I probably need to go through the history of the two project types and the pros and cons of both.

History

For a novice creating their first ASP.NET project in VS 2005 with SP1 installed they might be thinking why has Microsoft given me two types of projects for creating web sites? And which one should I choose?

Web Application projects are the original type of project used in VS 2002/2003 for creating ASP.NET web sites.  When VS 2005 was released, the Web Application project was replaced by a new type of ASP.NET project the Web Site project.

After overwhelming demand for it from the ASP.NET development community, soon after VS 2005's release Microsoft released an add-on for VS 2005 to enable development using the old style Web Application projects.  Later, the Web Application project was included as a part Service Pack 1 for VS 2005.

I should also note that these project types are also used for ASP.NET Web Services.

Web Site Projects

To create a Web Site project select File->New->Web Site or Shift-Alt-N.  Web Site projects are greatly simplified compared to Web Application projects. The Scott Guthrie has a very long post explaining the be explaining the benefits of Web Site projects.  I'll briefly go through what I think the pros and cons are.

Pros

• Publishing Web Site projects is very simple.  To publish a Web Site project you simply select Build->Publish Web Site.  When a Web Site project is published the end result is very clean and easy to deploy.  When publishing, use the option "Use fixed naming and single page assemblies", for each page an assembly will be created, the benefit of using this option is that after the site is published you'll be able to update individual pages, without any need to re-deploy other pages.
• Web Site projects are very specialised for ASP.NET development and have features such as checking the site for standards compliance and Accessibility.
• Streamlined code generation much of the complexity is hidden from the developer, code generated by the designer is not included within the project.

Cons

• It can be quite useful to view the code generated by the designer.  To view the code generated for a ASP.NET page you have to dig around in the "<windows>\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET" Files folder.
• Web Site projects don't actually have a project file.  The project's details (location and source control bindings) are recorded in the solution file.  Any file or folder placed under the root for the web site will be included within the project. Some might see this as a pro, simple and quick to add and remove files.  But for those who want complete control over the files being included in their Web Site, this is not a good feature.  Having no project file also means you can't keep it in a source repository and see a history of the files that have been added and removed from the site. For me this is the biggest issue with the Web Site project type.
• The positive Web Site project deployment story comes at a cost.  In order to make Web Site projects more granular and easy to deploy, references from a page can only be made to code in the App_Code directory.  A superior alternative is to put common code in a seperate project and reference the project from the Web Site.
  This is required to avoid complex associations between assemblies for pages within the site, making the site simpler to deploy.  This is the most major difference between "Web Application" and "Web Site" projects.  For a lot of developers, especially those who were looking to migrate 2002/2003 Web Application projects to the new VS 2005 Web Site project type, this is a major issue.
• The Web Site project properties whilst containing features that are unavailable in other project types such as Standards and Accessibility checking, they are missing advanced features such as:
  • defining compiler symbols
  • setting the warning level for builds
  • supressing warning mesages
  • producing XML documentation
  • custom build events.
• Update 2008-05-26 Bug: if you are using TFS and have created a branch of your source, beware ! I have found opening a Web Site in a branch will confuse Visual Studio and cause a mix up in the TFS source control bindings between the main and the branch.

Web Application Projects

To create a Web Application project you select File->New->Project, Select Web and click on the project type.  Here's a list of the pro and cons for this project type:

Pros

• Web Application projects have a project file!  This means that a Web Application project can be configured like most other .NET project types.  You have better control over the files included within the project.  You can keep this project under source control and therefore be able to keep a history of the files included and excluded from the web site.
• Developers can structure the project any way they like, web pages can reference any class no matter where it is in the project.
• Web Application projects offer an environment identical to other .NET project types and offer a much easier migration path for those porting ASP.NET Web solutions built VS 2003/2002.

Cons

• Web application projects are compiled into a single assembly, this makes deployment a real issue.  To deploy a web application, usually you will need to deploy the entire site.  Accordingly, you cannot update a single page easily as you can with Web Site projects.
• The options introduced to produce compiler warnings related to accessibility issues are absent from the Web Application projects build options.

Conclusion

The deployment story for Web Site projects as well as the support for checking accessibility when compiling makes the decision to use the Web Site project type for a new web site a compelling one for me.

The development story for Web Application projects may at first make them seem a better option.  The restriction on references between classes within a Web Site projects may seem a little onerous.  Moving common code to a class library project is a much better option than placing it all in the App_Code directory, but both options are acceptable.

Having said all that, I would not use the Web Site project type for ASP.NET Web Services.  The deployment needs of Web Services are very different to web sites.  Quite often a Web Service will have only a single ASMX file, so having a single assembly for the project is not an issue.  Plus, the options for checking the accessibility of HTML in a Web Site project are non-sensical for web services.  This makes the restrictive development environment of Web Site projects onerous and completely unnecessary.