Web Site Project -- or Web Application Project?

The Romans would never have found time to conquer the world if they had been obliged first to learn Latin. --Heinrich Heine

I write this because I still see many, many posts and questions from n00b developers who have difficulty with the Web Site project model. In many cases,I believe they do not even know that Web Application Projects are an option, or they simply haven't installed Service Pack 1.

When Visual Studio 2005 first came out, I immediately took a disliking to the only ASP.NET model it had at the time, the "Web Site" project. Fortunately,I wasn't alone, and after listening to the screaming hordes of developers bitching about it, Mr. ASP.NET & Co. finally came out with the Web Application Project, which restored my sanity (and my productivity).

I do not like having multiple "per page" assemblies with weird, cryptic names; I do not like distributing my .cs source files onto a production webserver, and that's just the beginning! If I want my site to be updatable, I can recompile it in 2 seconds and copy over the new SINGLE ASSEMBLY very easily, and not have to worry -- because the names of the files will be identical. Same with revised ASPX pages.

Here is a detailed comparison , but the main differences are:

  • Web Application projects have a physical project file and resemble the "classic" Visual Studio 2003 web project model.
  • Web Application Projects compile all codebehind classes and related free class files in your project into a SINGLE ASSEMBLY.
  • Web Site projects have no project file (very annoying -- in a lot of different scenarios) and are solely based on what’s on the filesystem below the root folder.
  • Web Application projects are standard as of Visual Studio 2005 Service Pack 1.

At this stage, I can say that I would not create a Web Site project for anything except temporary small demos. Web Site ASP.NET web projects are particularly irksome in Team System due to the lack of a physical file that contains project information and metadata. It's impossible to check in code analysis rules on Web Site projects, for example. In addition, the wacky code compilation model that encourages developers to put what "should be" in separate class library projects in the same parent Solution into the APP_CODE folder instead -- just drives me NUTS!

In fact, when you right - click on a converted project and choose "Convert to Web Application" it actually renames the APP_CODE folder to "OLD_APP_CODE" - just so ASP.NET doesn't try to "double - compile" your stuff (a source of many "Tearing my hair out" type issues for inexperienced devs, to be sure!).

Bottom line is, make it a Web Application Project to keep your sanity, and if you have a Web Site project, consider converting it NOW.

Scott Guthrie has an excellent tutorial on how to do this. It doesn't take very long. You'll thank me later!

Now you will always get a few who disagree with me on this one. You know what I have to say to you? Phooey! Vee don't need no steenking Web Site projects! Don't forget the penultimate principle: "Less -- is more!" Rest my case. Some interesting comments so far. In particular, take a look at Ted Jardine's blog.


  1. Anonymous12:46 PM

    "Web Site projects have no project file (very annoying -- in a lot of different scenarios) "

    Ive seen this comment in a number of places. What scenarios? (Not doubting you, just curious).

  2. Anonymous5:29 PM

    For example Nant build scripts. In general I don't understand why all other project types are based on project files and this is not. Consistency that's what I value.

  3. Amen to that.

    What remains annoying are the esoteric hoops we sometimes find ourselves having to jump through when figuring out how to get other basic stuff working with Web Application Projects. Profiles anyone? Sure, it's getting better and better and we get them eventually figured out, but more time wasted by the leftovers of a so-so idea gone bad.

    I do have to admit also however that for quick mockups, Web Site Projects are wonderful.

  4. In a lot of different scenarios - Build scripts, TFS, and more. Ted, Profiles are easy to set up using the WebProfileGenerator add-in that's linked at the bottom of the Scott Guthrie conversion tutorial that I linked to. I've done it. This has a readme.txt file that explains a lot.

  5. thanks peter for very small but effective overview of the difference. i read similar things at many locations but this post made it clear !

  6. Anonymous2:16 AM

    Thank you for your post. Nice overview.
    Another nice feature of Web Apps that I re-found, was the documentation XML file that you set up in the project properties!

  7. Good point. Totally forgot about documentation. Not only that, but you can compile this into a nice CHM (or html) documentation file using NDOC or even Sandcastle.

  8. Anonymous5:51 PM

    Here is an example of web site madness. I add an .aspx. I check it in. Others get the page via VSS. I then delete the file locally and in VSS. But others will have the file locally and if not careful they will add it back into VSS. Then I get the latest and the file is back for me.

  9. This comment has been removed by the author.

  10. go back and read the post and the comments again, carefully. I didn't say "Solution".


Post a Comment

Popular posts from this blog

Effectively Promoting your Blog (or WebSite)

WCF Service Debugging with the serviceDebug element.

ASP.NET: Loss of Session / Cookies with Frames