« Helsinki Looks | Main | Getting images back online »

Monday, May 29, 2006

Visual Studio 2005: Web Site Projects vs. Web Application Projects

Introduction
Microsoft Visual Studio 2005 (VS05) offers two models of web projects to its users. The project models are appropriately named – the Web Site Project (WSP) is suitable for web developers building web sites with (perhaps) some application functionality included, while the Web Application Project (WAP) is more suitable for application developers focusing on applications that happen to have web-based interfaces. Microsoft is committed to supporting both models into the future.

Web Site or Web Application?
In order to decide which model to use for a specific project, the developer or software architect should ask himself the following question: Is my project primarily a web site, or is it primarily an application that just happens to have a web-based interface?

The principal difference between the two VS05 project models is found in their respective project structures. The WSP uses a directory tree structure, while the WAP uses a project definition file structure. At first glance, this difference may seem trivial, but it filters down and translates into more tangible differences for projects and developers, alike.

History
For a better understanding of the tangible differences between the two project models, some history is useful:

When Microsoft released Visual Studio 2003 (VS03), it offered a single web project model with a structure based on the project definition file. Some VS03 users complained that this project model was too cumbersome and inflexible. It forced them to open projects for editing via IIS, instead of allowing them to open projects directly from any directory. It did not integrate easily with other web site front-end tools such as Dreamweaver or FrontPage. It required developers to define a project’s components explicitly, rather than simply to define a project root directory and have all of the directory’s contents (and that of its subdirectories) automatically included in the project. It required the developer to rebuild the entire project whenever he wanted to test changes made to any single page.

As the saying goes, “the squeaky wheel gets the oil,” and Microsoft tried to address the aforementioned user complaints with its Web Site Project model, introduced with Visual Studio 2005. Gone was the cumbersome inflexibility of the project definition file structure. Developers could now open any directory and edit it as a web project, without having to go through IIS. Front-end designers could use Dreamweaver or FrontPage to do their front-end magic. Project components no longer needed to be defined explicitly – any file under a project’s root directory was now considered a part of that project. Gone was the need to rebuild an entire project to test changes made to a single page. In short, the WSP was a major advance for teams who were using Visual Studio as a platform for building web sites in ASP.NET.

With the once-squeaky wheel now well-oiled, one might imagine that the story ended here, “and everyone lived happily ever after”. Not quite. Unfortunately, instead of making the WSP model an additional model available to VS05 users, Microsoft made it the only model available to them. Microsoft soon found out that not all of VS05’s users considered themselves to be web site developers. Many of them were application developers who were using Visual Studio to develop ASP.NET applications that just happened to have web-based user interfaces. These users did not find the VS03 web project definition file structure to be cumbersome. On the contrary, they found the old structure to be better-suited, in some ways, to the task of application development. A new wheel started to squeak.

Enter the Web Application Project model. On May 8, 2006, Microsoft offered the production release of an update to VS05 that made a second web project model available to its users. Called the “Web Application Project”, this model incorporated the VS03-style project definition file structure, along with some new improvements. With the release of this update, and the promise to support both models into the future, Microsoft admitted that a single web project model could not cover the needs of all of VS05’s users.

The WAP model requires application developers to explicitly define a project’s components (and, as such, does not require all project components to be stored under a project’s directory – desired behaviour in some cases). It allows a single application to consist of multiple web projects. It compiles all code into a single assembly. It allows any class within a project (or a separate project that references said project) to directly reference and use a page and its controls. It speeds up project compilation, supports XML code comments, works with standard TDD and unit test tools, offers control over the naming of output assemblies and allows developers to add pre- and post-build steps during compilation. In addition, it offers some new improvements over the VS03 model, including “Edit and Continue” development and a new .designer.cs file that makes it easier to work with code-behind by separating developer-written code from VS05-generated code. In short, the WAP was a major advance for teams who were using Visual Studio as a platform for building ASP.NET applications with web-based user interfaces.

Web Site Project Highlights
When VS05 was originally released, the only web project model it offered to developers was the WSP. This project type differed from the VS03 web project model, and the differences seem to be primarily the result of Microsoft product development engineers trying to address concerns and complaints from VS03 users who wanted a web project model that was more suited to web site development.

The Visual Studio 2005 Web Site Project:

  • Removes the VS03 requirement of a project definition file by simply including all files in a project’s directory tree as parts of the project upon compilation
  • Allows a developer to edit any directory as a web project, without hooking it up to IIS first
  • Allows easier integration with popular web front-end tools, such as Dreamweaver and FrontPage
  • Allows the developer to edit a page, save that page, and immediately view the results of his changes by refreshing the page in his browser (as opposed to rebuilding the entire site every time he changes any single page)
  • Is geared toward developers who prefer the single-page code model to the page-behind code model
  • Offers a compilation model that creates one Assembly per page, instead of one Assembly per project
  • Works with Visual Web Developer Express Edition

Web Application Project Highlights
The “new” WAP model was introduced by Microsoft as an add-on to VS05 in order to address complaints and concerns from VS05 users who wanted a web project model that was more suited to the development of applications with web-based interfaces. These users wanted a more application-centric web project model, similar to the one offered by VS03.

  • The Visual Studio 2005 Web Application Project: Offers a project definition file-based structure
  • Compiles all code in a project into a single Assembly
  • Compiles much faster than VS05 WSP projects during a full build / full rebuild
  • Allows any class within the project (or a separate project that references your web project) to directly reference and use a page and its controls
  • Makes code refactoring very fast, even for very large projects
  • Allows the use of all features of ASP.NET
  • Allows “Edit and Continue” during development
    • Only with the built-in Cassini web server
    • Requires the web server process to be created and shutdown on each debug session
    • Must be manually set in Project Properties page
  • Supports generating XML code comments (self-documenting code)
  • Works with any unit test or TDD tools that work with the Class Library Project system
  • Works with Web Deployment Projects (for precompiling code)
  • Does not work with Visual Web Developer Express Edition
  • Offers control over the names of output assemblies
  • Allows web application to be built from multiple web projects
  • Allows developers to add pre- and post-build steps during compilation
  • Is well-suited for migrating large VS03 projects to VS05
  • Splits partial class code into separate code-behind files (this addition makes it less likely that code inserted automatically by VS05 will interfere with code written by the developer, and vice versa)
    • .aspx.cs for developer code
    • .designer.cs for design-time (automatically-inserted code)

Further Reading / External Sources

Most of the information contained in the preceding article was gleaned from the following sources:

 

Author: Kurt Milam, Senior Consultant

May 29, 2006 in ASP.NET / Visual Studio 2005, Web/Tech | Permalink

TrackBack

TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a00d834558a0669e200e5506643888834

Listed below are links to weblogs that reference Visual Studio 2005: Web Site Projects vs. Web Application Projects:

Comments

In Web site projects way, I have option to just deploy the dll which got code behind chnages in it, this dll won't be having anything else, that way deployment team has full trust on what's coming for deployment and they just test that page and nothing else and that way we have Quicker QA Pass and Quick deployment.

So, the WAP way, how can I avoid the regression testing for whole site when I changed just one code behind file. Right now (in VS 2003), we have to do a full regression test for whole site to make sure it didn't break anything else.

What do you think, does WSP really has an edge over WAP in this matter, or I am missing something.

Posted by: gurpiar | Jun 14, 2006 5:01:36 AM

Nice work.

JS

Posted by: John | Jun 23, 2006 7:17:12 PM

no photos on this topic? ;-)

Posted by: a friend | Jun 30, 2006 1:42:26 PM

hi! yeah, helsinki is really a good place for individualists, and you can find those people indeed on the street :o) greets from HEL, wolf

Posted by: wolf | Jul 28, 2006 4:44:15 PM

Post a comment






 

All Images © Kurt Milam