Difference between 'Web Site' and 'Project' in Visual Studio

> Possible Duplicate:
> ASP.NET: Web Site or Web Application?

I have noticed that there is clearly a difference in what you get when you fire up Visual Studio 2008 and choose 'New Project' -> 'ASP.NET Web Application' instead of 'New Web Site' -> 'ASP.NET Web Site'. For example if you choose 'Project', then you can compile to .dll and each page gets a *.aspx.designer.cs codebehind file.

1. Why do we have these two different project types?

2. Which do you prefer?

3. Why would I choose one over the other?

4. What's the deal with the *.aspx.designer.cs files?

They have different purposes.

A website is a site with content that is likely to change over time, that is the pages themselves will change. There is no actual project file and the site is deployed simply as a set of files.

An application is a site where the content is just the application, the dynamic part will mainly be in persistant store such as a database. It will have more complex logic since its likely to represent a set of forms for data entry as much as a means to examine content. It has a project file to more strictly control its configuration and its code deployed as a compiled dll.

1. The 'web site' model was introduced with ASP.NET 2.0, the 'web application' model was the project type of the original .net framework. They both have different uses (see below).

2. It depends on the context. A good example is if you are selling a software product, you may wish to use a 'web application' project because it naturally lends itself to cleanly compiled code.

3. See above, personal preference, maintenance characteristics. An interesting thing that a 'web site' allows you to do that can get you in a lot of trouble is making arbitrary changes to code-behind (typically a *.cs or *.vb) file in notepad while the website is running.

4. The designer.cs file is used to store the auto-generated code. "This code was generated by a tool."

• MSDN Article describing the differences
• Similar stackoverflow question

I won't duplicate the definition of the 2, since that just got answered.

So why use one over the other?

Web Site lets you treat it like a PHP or classic ASP site, where you can make inline changes that take effect immediately.

Pros

• You can make tweaks to the site right on the web server
• Deploying is as simple as copying the folder

Cons

• If you are not making the changes right on the live site, you can get into change management problems, where you forget to keep all your files in sync
• You can get runtime syntax errors displayed to your end users, since the only way to check is to manually run every page

Web Application lets you treat it more like how you would a desktop application - there is one deployable that is compiled on your machine.

Pros

• Clear, structured change management. You cannot accidently mix code from two different versions. This can be important when there are 2 people involved - one writing the code, and one responsible for putting files on the server.

• Because you compile it on your machine, everything gets syntax checked at that point*

Cons

• Deployment is a little more involved then just copying the folder from your development machine. However the usage of the "Publish" command greatly simplifies the process of compiling and putting together what files should be copied to the web server.

• Any changes need to be done on your machine, compiled, and a whole new version sent to the web server*

*The aspx/html files are only syntax checked if you turn this on in your build options though. It is also possible to edit these files on the server unless they are compiled into your project.

The simple answers are as follows:

1. New Web Site - creates code behind pages that are compiled at the server when page is requested.
2. New Web Project - creates pre-compiled pages into one or more assemblies (entire site even), and deployed on server.

Scenario #1 - If a hacker obtains your code-behind files, any database passwords are exposed. These pages are compiled at the time they are requested. You can choose to pre-compile everything into a large assembly. If not, there is more load on the server.

Scenario #2 - if a hacker obtains your assemblies, they will be obfuscated. Obfuscated assemblies are harder to crack. These assemblies are pre-compiled, thus reducing load on the server.

For more information:

Introduction to Web Application Projects

3. WebApplication projects are buildable by MSBuild. WebSites are not (without a lot of tweaking). If you use TeamSystem with automated builds then this is the way to go.

THe biggest difference that no one has really mentioned (except touched on by Annakata) is that with the model where everything is compiled into a single DLL, your have complete control over the classes that your application generates. You know where they are and can always reference them from anywhere else in the application.

With the single page model, you can't do this. You have to get around it by creating "stub" classes in the AppCode directory, and inheriting those in your pages, but even that isn't ideal, and add complexity.

You'll only really come up agaist this stuff if you're trying to develop an intricate dynamic site, where you dynamically load lots of user-controls at run-time based on content. Then, the differences are painfully clear - hence much of our development stalled on ASP 1.1 until we could go back to the same model later.

Nich

Speaking from experience with both: "Web Sites" are used where there is no testing methodology in place, no CI server, and a culture that encourages and promotes "hotfixes" to specific pages regularly. "Web Applications" are the de facto standard where proper software methodologies are followed and there is unit testing (if not full TDD) and a CI server with a focus on writing clean code and finding bugs before the need for a "hotfix" arises.

Sites are the 2003 original .NET way of doing web dev. In my experience they are extremely problematic since lacking a project definition they can't be reused and have issues with modular coding, have issues with TeamSystem integration and namespacing. The one-to-one bind with a domain and lack of real publishing abstraction creates maintenance problems down the line.

The ancient "classic" ASP way of !codebehind is a serious problem because it again impairs code reuse and testing, and the often cited benefits of allowing hot fixes - if ever called upon - is actually a massive signal that you have a failing development process. The ability to hot fix is of course better than not being able to, but it's something you never want to invoke.

You might say that the problems with the web site model were great enough that MS gave us web apps instead. Personally I would never use them for anything beyond demo code... no actually I wouldn't even do that.

1. At first there was a Web application project (it behaved similarly to the current Web site project). They changed it to reflect what some users requested. However people wanted the old functionality back so they re-introduced the Web site project which behaves like the original Web application project.

2. I -- and my workplace -- prefer the Web site project

3. We like that the files of the website are the files in the file system (no need to add them manually)

4. No idea

Here's two articles I found about both:

http://damieng.com/blog/2008/02/07/web-site-vs-web-application

http://www.dotnetspider.com/resources/1520-Difference-between-web-site-web-application.aspx

Note: A lot of the issues with Web sites have been resolved with the Web deployment project

Update: Fixed the point 1, Web application was there first

If your work needs to leverage oo language features (class hierarchies, namespaces) or if you need to reuse common code among projects (data access, class libs etc.) then the web application project is the only way to go.

The website project (the clue is in the name) is only really good for non-complex 'brochureware' sites (where the pages consist of static content) as opposed to web applications.

There is very little difference, and I would highly recommend using the Web Site model.

The main difference is for a website, some files need to be placed in certain directories (code files need to be placed in the 'App_Code' directory), besides that, it's pretty straight forward.

If having compiled code for deployment is important to you, and you want a single DLL (opposed to the several that are created when you do a normal publish for a web site), then you'll want to get this add-on: http://msdn.microsoft.com/en-us/asp.net/aa336619.aspx