Web Application Projects vs Web Site Projects

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.

Published: Saturday, February 10, 2007 1:33 PM by Michael Lang
References Kick it

Comments

RE: Web Application Projects vs Web Site Projects

Published: Friday, May 30, 2008 10:39 AM by Carl Svenbro
Hi,

I think that the main drawback of website projects is, in my opinion, that you cannot add existing items as links, the physical files are always copied, meaning that you cannot share files between website projects which is possible in web application projects. It would be very easy for Microsoft to make it possible to share files between website projects, but unfortunately they haven't taken care of the problem in Visual Studio 2008. I suppose they have a philosophy that a website project should be equivalent with the physical folder, period; no exceptions allowed.

RE: Web Application Projects vs Web Site Projects

Published: Saturday, May 31, 2008 4:01 AM by Michael Lang
Thanks Carl, hadn't picked up on that one, but yea you're right.  This is an especially big deal if you're using TFS for source control as it doesn't support links to files within the repository (as was available in source safe).

I must admit the choice between the two projects types is still really line ball for me.  I had really hoped that Microsoft might have cleared up this mess a little with the 2008 release, however, both the Web Application and Web Site project types seem to be the same as they were in VS 2005 with SP1.

Leave a comment

Your Name (required):
Your Url (optional):
Title (required):
Your Comment (required):

MBLM Logic Check - Protection from spiders and scripts

Guarding against malicious attacks on the web is an unfortunate necessity. To prove your request is authentic, provide answer to the question below.

Enter the answer in numerical format e.g. Q: two + two A: 4
Work out the following three times zero
 

Home

Microsoft.NET services, software and development resources