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.
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.
- 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.
- 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
- 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
- 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
- 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.
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.
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.