Web Site or Web Application in ASP.NET

Question

Which Visual Studio template should be used for a ASP.NET web site, the Web Site template or the Project | Web Application template?

Answer 1

Both function and perform similarly, but still differ in following ways:

Web application:

• We can't include C# and VB pages in single web application.
• We can set up dependencies between multiple projects.
• Can not edit individual files after deployment without recompiling.
• Right choice for enterprise environments where multiple developers work unitedly for creating, testing and deployment.

Web site:

• Can mix VB and C# page in single website.
• Can not establish dependencies.
• Edit individual files after deployment.
• Right choice when one developer will responsible for creating and managing entire website.

Answer 2

you'd better read this: http://msdn.microsoft.com/en-us/library/aa730880(VS.80).aspx in my opinion it depends on what you are developing

Answer 3

Web application projects works more like a traditional VS project, which has a project file, is compiled in one step and so on.

Web site projects works more like classic ASP or PHP-sites. There is no project file (references are stored in the solution file), and pages are recompiled dynamically on the server. The nice thing with web sites is that you can just ftp to the server and change a file in a text editor. You dont need VS. Some may hate that, though.

It probably depends on your background. If you are used to ASP or PHP style development, web site projects will seem more natural to you. If you have a traditional application developer background, web application projects will seem more natural.

Answer 4

If you're using Team Foundation Server for source control, you'll probably have to use a Web Application Project, as you need a .csproj file.

There are more details from Jeff Atwood himself: Web Site Projects vs. Web Application Projects

Web Site web projects are particularly painful in Team System due to the lack of a physical file that contains project information and metadata. For example, it's impossible to check in code analysis rules on Web Site projects, because the code analysis rules are stored entirely on the client!

Answer 5

I prefer a website. A website is a collection of files in a directory. It becomes more portable and deployable. A web application clouds the issue with a project file.

Answer 6

In Visual Studio 2015, I've come to somewhat prefer web site projects over web app projects. I still use visual studio though because you get Nuget Packaging, you can install nuget packages to both types of projects.

However a WebSite Project does not have a project file, you are literally just adding a folder to your solution.

However you can still have code, but I prefer to put it in a separate project.

In WebApp projects you have your Assets, Css, Views (razor, aspx etc), Controllers/Code Behinds etc all in one project and it just mashes together. I prefer to work with websites in two halves. The front end (css, js, images, "html/cshtml/aspx/ashx/.master/etc") and the back end (all the code).

So I create a Web Site project and a class Library to accompany it (in visual studio you can add references to the web site project). I add my class Library as a dependency and all Code is in the class Library. You can still have a global.asax, you just have to tell it that the code behind is in another dll (not the one that the site will compile to). MVC views, you just specify the namespaces like normal (the dll is referrence so the namespaces are there). And in WebForms you Just have to remember to include the assembly name with your type references that the code is in.

It's a little tedious to get use to, but when you do you have isolated structure, everything is in a place that makes sense and modularized in an easy to maintain way.

And the PLUS side is that because the Web Site is just a folder (no project file) it can be opened in Visual Studio Code easily, and other popular text editors making it easy for designers to work on the css/js/images etc (which are not in the code project). Keeping the layer designers separated, the designer sees just what they need to see.

Now structure wise. I keep my code local on my machine checked into a subversion repository using Tortoise SVN and Visual SVN (java/.net shop). To test locally I install IIS and I set the website project up in IIS locally just like I would on the dev/prod servers.

Then I install MSDeploy on the dev/prod servers and I use the Publish web app feature via MSDeploy in visual studio and I use web.config transformations. So I have web.config transformations for dev and prod and the main web.config without transformations is for local testing (so it works for all devs on the project).

To previous stated cons: Having a WebSite Project vs a WebApp Project doesn't mean multiple developers can't work on it, that's only if your WebSite Project is on some server some where and you are loading it directly from there which would be bad practice.

You can treat a WebSite Project just like any other Visual Studio project, local code, source control, multiple developers.

As a final note, an added benefit of separating your code is you can put all of your code in a shared project. Then you can create a Class Library for each port you might do, say one on straight .net 4.6 and another on .net core 5 and link in your shared project. As long as your code is compatible with both, it will build and you don't have any duplicated code files.

Answer 7

Personally I use web application projects exclusively now. I actually converted a rather web site to a web application because of compilation times for the web site.

I also use pre-build events to move configuration specific configuration files around and pre-build and post-build events are not available in web sites.