Web Site vs Web Application Project (WAP)

In ASP.NET 1.x there was only one way to create a web app—the Web Application Project (WAP). In ASP.NET 2.0 WAP was killed, deliberately or not, and replaced with the lame Web Site “model.” WAP for Visual Studio 2005 was shipped separately later.

There are several reasons I strongly dislike Web Site projects.

Sloppy project structure

This model encourages sloppy project organization. A typical web site has no structure. You’re lucky if you see a namespace here and there. In my opinion, this is unacceptable. Since less competent developers simply use what comes out of the box, Web Site is a “bad practice” from the get-go.

Not long ago, I took over a project from someone who had everything dumped into a single Web Site. There were no logical or physical tiers. A Web Site has no solution file per se, so the guy made no effort to separate concerns.

Magic folders

According to MSDN, “You can store source code in the App_Code folder, and it will be automatically compiled at run time.” In real life, I see that App_Code is a garbage can where people throw code they don’t know where to put. Instead of thinking through which namespace a class should go to (logical organization), or even which folder (physical ogranization), App_Code serves as a dumpster.

There’s a whole bunch of other magic folders I’m not comfortable with.

Please note: this isn’t a discussion about convention vs configuration. It’s not like you can rename App_Code or stop its on-the-fly compilation. It’s imposed on you.

Migration

You don’t learn the true meaning of pain until you have to migrate a decent-size Web Site to a WAP. There’s no automatic migration. It’s all manual and very painful. I don’t want to belabor the point. Scott Guthrie and Mohamed Meligy have lengthy instructions. I had to go through a migration ordeal recently, and it wasn’t fun at all.

Beware of the following side effect: conversion to WAP resets AutoEventWireup.

The bin folder

Again, MSDN states, “You can store compiled assemblies in the Bin folder.” I inherited a project where all dependencies where simply dumped into bin. Another dumptser. In a WAP, you don’t mess with bin. You set references and they are copied into bin when the project is built.

When you migrate a Web Site to a WAP, you have to go and clean out the bin folder by hand.

Conclusion

In my no-so-humble opinion, the ASP.NET Web Site model is an aberration. I wish Microsoft retired it as a failed experiment.

For MSFT to retire the Web Site model as a failed experiment they'd have to first admit that it is a failed experiment. That would highlight that MSFT at least occasionally imposes ill-conceived practices on it's customers. Something that MSFT is not likely to do.

I'm not sure the Web Site style project was a bad idea. Releasing vs2005 without the Web Application Project support _was_ a bad idea.

The Web Site Project does have advantages, especially for adhoc style development - which I think appeals to certain styles of _small_ development. It's easily portable and tweaked, without having to force a build. The portability alone was leaps and bounds forward from the .NET 1.1 offering.

I also think it _can_ be well organised, with additional supporting projects (dll's) to provide app/business logic, and think of the Web Site Project as the presentation layer.

Where this has failed is in education on how to go about it - we have lots of screencasts on "how to drag this here" and "drop that there", but coding for maintainability and performance isn't really tackled a lot on the typical ASP.NET sites.

I use both types - both have pluses and minuses - so I think its about choosing the right one for the project.

I tend to agree with Dave.

As a small site developer I find having the option for both cumbersome. When and why do I use one over the other. Honestly I wish that someone would do a screen cast on proper DAL or BLL development. And not the pie in the sky MSFT designed adapter based DAL/BLL examples that exist now. I really don't believe that is production quality code. If someone can point me to statistics that say table adapters run more efficiently than a well written DAL I will switch in a minute.

I don't have hours to spend researching, developing and coding, it's not my primary job. I have a general idea of what things should look like but the best example that I have ever found is the Beer House examples and they are overkill for me most of the time. I really just want to see how some of the pros handle basic real world data access and business rules outside of full enterprise environments. Basically Beer House without the caching, inheritance and instancing that makes the code so much harder to follow.

But in the end maybe that's the problem, for smaller sites, where perfect performance and full features aren't necessary they don't spend the time, but how does that help non-professionals learn the truly best-practices?

When I first started with ASP.NET I used Web Site model because it made more sense to me. Now that I've spent the time to understand it I don't really see a reason to ever use Web Site model again. I don't mind rebuilding between changing or uploading a fresh .DLL.

The Web Site Project (WSP) model is great for small projects, prototyping, and demos. I teach a couple ASP.NET courses at the university and write a bunch of tutorials and articles. Having a self-contained folder with App_Code and App_Data and so on, makes it so much easier for a student or reader to take the demo code and get it up and running.

That being said, I use Web Application Projects (WAP) for all my real-world projects.

I wonder if things would have been clearer had left WAP in VS2005 and named WSP something like Website Prototype Projects.

I see the relationship between Web Site Projects (WSP) and Web Application Projects (WAP) as similar to that between Cassini and IIS (http://aspnetresources.com/blog/cassini_vs_iis.aspx) i.e. WSP are unprofessional. Even if a project is simple when created, building on a solid framework allows for easier expansion or future migration.

@Scott: What's the point in teaching students something they'll never use (or should never use) in the real world? In the end, it becomes a burden for companies forced to retrain graduates.

In your introductory paragraph, didn't you mean to say that the web site model was replaced with the web application project model? Also, the web site model wasn't "killed", just supplemented with the new WAP model (which has since been further supplemented, or perhaps extended, with the newer ASP.NET MVC model).

Scott, the first paragraph is correct. They shipped without WAP at first, advocating "web sites" all along. Somewhat later, they added WAP back as a separate bolt-on.

I totally agree to this post, surely the ASP.NET Web Site model is an aberration.