Web Site vs Web Application



Recently, we have done .net framework(FW) and IDE upgrade (FW 3.5 to FW4.0 and VS 2008 to VS 2010). It resulted in minor issues in service (WCF), business and data layers whereas many issues on web front-end. They are all fixed with moderate efforts except the ones of type :

Error: The type <Type> exists in both <Type1.dll> and <Type2.dll>.

And the journey started

Web front-end was a web site project (WSP) and by nature, WSP is not a project – there is no project file-, but collections of items within a directory. Because of that it produces multiple assemblies (one assembly per .aspx/.ascx) when build. That gave me the clue, it may be because of incorrect page or user control specific directive (CodeFile, Inherits) values which may be resulted in circular references. We have found a work-around solution by toggling batch = true/false in the web.config file, however it was not satisfied due to longer build time. Then I asked myself what if we use web application project (WAP).


I have been developing both WSP and WAS in many years, and to be honest with you, I was not clear on their differencesSmile. I have found good resources, some of which are listed under references section.

It is obvious that there are pros and cons in both side depending on the context. I am not going to talk about same things but will simplify and prioritize things I have found. Furthermore, I have also analyzed both them in regards to VS 2010 features. Below, you will see comparison matrix.

Project structure

· It is a project just like other type of application projects (Windows Forms, Console, WCF, Database etc.). It can be references by other applications.

· Namespaces provided when new item added. For example, if you add new item called ‘About’ under ‘Account’ folder, the class name would be ‘About’ with ‘WAP.Account’ namespace.

· Class files (.cs, .vb) is located under any directory chosen as added.

· Projects are tied to a specific language. You may choose any CLI language to develop your project. If it is a cs project, then the project file extension is .csproj, if f# then .fscsproj, for example.

· There is no a project file associated. Site includes collection of items (page, user controls, sources, etc.).

· No namespace defined when new item added into the site by default, class names differentiated based on container names, if you add a new item called ‘About’ under ‘Account’ folder, the class name would be ‘Account_About’. That may lead incorrect CodeBehind and/or Inherits references due to copy-paste cases and the page will still build and work.

· Class files (.cs, .vb) is located under App_Code folder.

· Supports multi language partially (C# and VB only)


· It creates one single assembly when build. To browse or debug for even one single page, all project must be build first and that wipes sessions and caches.

· Edit and Continue may be used for debugging when browsing the page – no need to restart the page.

· Syntax errors can be found in compile time.

· Built-in master page integration

· Include/exclude does not cause name changes

· Will enforce clean builds before check-in.

· Remember, each page produces its own assembly. Therefore, even though, you have some build errors on other pages, you can still keep browsing, developing, debugging your own page as long as your page and the components that it is depended on, works fine. Sessions and caches are available as long as worker process (WebDev.WebServer) running. This one of the biggest pros of using WSP. For example, if your project has 1000s of pages in your site, and you are doing some works page by page; you can develop, debug, and browse instantly.

· It may require good convention and check-in/out policies.


· Easier. Unit tests can be generated for any class in the project.

· MVC type of WAP is suitable for Test Driven Development (TDD)

· Not good for unit testing; unit tests can be generated for only classes under App_Code folder.

Build & Deployment

· It is pre-compiled already.

· Easier: one single assembly for whole application along with static content.

· Well integrated with TFS 2010 Build and Deploy features.

· TFS Build Templates can be customized specific to WAP.

· Web.config transformation supported (VS 2010 only).

· May need explicit pre-compilation

· Since no single assembly, you can’t use TFS Continues Integration and Nightly Builds features.

· Let’s you make quick fixes (if inline coded – yes I know it is spaghetti, but well, if it works for you, then why not use it) on production.

· It may be difficult to find circular references.


In this study, I have tried to compare both WSP and WAP with different angles, ignored some features that both satisfy such as FTP support, source control integration.

IMHO, there is no single answer suitable for any context. Depending on your business requirement (development time, whether to follow an Application lifecycle management (ALM) methodology on which Development, Test, Build, and Deployment phases are well  integrated), one can be chosen.

In our case, to fix the error and to follow ALM with TFS 2010, we have converted WSP to WAP successfully with the steps detailed in this post. The problem is fixed, yet a new journey startedSmile.


  1. msdn – Web Application Projects versus Web Site Projects
  2. Vishal Joshi’s Tangent – Web Site vs. Web Application
  3. Web.config transformation