71

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?

Community
  • 1
  • 1
Gudmundur Orn
  • 2,003
  • 2
  • 23
  • 31

11 Answers11

54

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.

AnthonyWJones
  • 187,081
  • 35
  • 232
  • 306
  • 2
    It may be good to note that you could choose to address the same business needs using either project type based on personal preference. – Ian Robinson Feb 26 '09 at 13:34
  • 1
    @Ian - not really, the site model has several business level drawbacks and only trivial gains. – annakata Feb 26 '09 at 13:45
  • 3
    This is not correct; they are both capable of the same tasks (Web sites can be compiled as a dll as well) – John Feb 26 '09 at 13:56
  • @John: There are all sorts of deployment scenarios, I was describing the purpose of the project types, if you were going to deploy a Website as a compiled dll why not use a proper project? – AnthonyWJones Feb 26 '09 at 16:04
30

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

Community
  • 1
  • 1
Ian Robinson
  • 16,892
  • 8
  • 47
  • 61
  • 1
    "The 'web site' modal was introduced with ASP.NET 2.0, the 'web application' model is the 'original'". Awkward. – annakata Feb 26 '09 at 13:31
  • 2
    About (1): the web application project was the one that was introduced in VS 2005 as a replacement for VS 2003's Web Project. [See here](http://damieng.com/blog/2008/02/07/web-site-vs-web-application). About (3): you can change this code only if the site is published as updatable. If not, there won't even be a *.cs or *.vb on the published site. – Abel Sep 07 '10 at 09:25
18

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.

David
  • 24,700
  • 8
  • 63
  • 83
  • For the web application type, what happens if you re-publish, overwriting the project's DLL, while users are still on the site? I need to know this for my project, but it isn't worth a new SO question. – HardCode Feb 26 '09 at 17:56
  • 2
    Personally I don't publish straight to the site, instead I use a staging folder. Overwriting the DLL causes a short pause, and then the next request is running. Keep in mind - updating *restarts* the application. For enterprise situations you should use a maintenance plan, not a surprise update – David Feb 27 '09 at 02:02
10

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

Michael
  • 1,340
  • 1
  • 11
  • 7
  • I upvoted this answer by mistake and cannot retract my vote. The points you make about scenarios 1 and 2 are largely irrelevant, if not untrue. – Marc.2377 Dec 18 '18 at 16:24
9

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.

DancesWithBamboo
  • 4,176
  • 1
  • 19
  • 20
5

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

Nich
  • 51
  • 1
  • 1
5

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.

Wayne Molina
  • 19,158
  • 26
  • 98
  • 163
4

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.

annakata
  • 74,572
  • 17
  • 113
  • 180
  • 1
    Web projects were the only option in .Net 1.0 and 1.1. VS 2005 initially got rid of web projects altogether until a large number of complaints encouraged their return in a service pack. VS 2008 continues to have options for both. – TGnat Feb 26 '09 at 14:39
  • 1
    But the Web Project in 1.1 was equivalent to the web site of 2.0 - it's more of a name change going into 2.0 (sans SP) than anything else – annakata Feb 26 '09 at 15:29
3

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.

immutabl
  • 6,857
  • 13
  • 45
  • 76
3

  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

mbillard
  • 38,386
  • 18
  • 74
  • 98
2

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

John
  • 17,163
  • 16
  • 65
  • 83
  • 3
    That isn't the 'main difference', there are numerous more important differences as outlined here: http://msdn.microsoft.com/en-us/library/aa730880(VS.80).aspx#wapp%5Ftopic5. Personally I think it is reckless to recommend the website model to anyone but a first year CS student or budding amateur web developer. – immutabl Sep 09 '10 at 10:12
  • 1
    How is it reckless? The only thing you lose is the ability to re-use the code elsewhere; I've never developed a site where I needed to use the code in another project.. If I did, that code would be in it's own project shared by both sites. – John Sep 09 '10 at 20:22