Web Sites vs Web Applications
(Originally published: 3 January 2009)
One of the biggest confusions in the ASP.NET world is that of web project type. Visual Studio (VS) supports two web project types: web sites and web applications. Unfortunately, they are different enough that it is important to understand which type you are using and why. In this article we will discuss the differences between the two types by looking at their history. By the end of the article you should be comfortable enough to determine which type is best for you.
When Visual Studio .NET (VS.NET) was released it supported a single web project type, the web application. A web application looks and acts like a regular Windows or console application. A web application contains a set of project property pages which the developer can set including build and debugging options. This allows, for example, the developer to generate documentation for any code contained in the project.
When a web application is compiled all the source files (including the codebehind files) are compiled into a single assembly and stored in the Bin directory. The ASPX files are deployed with the binaries. At runtime the ASP.NET runtime compiles the ASPX files into an assembly when they are first needed. If an ASPX file ever changed then a new assembly is generated. The initial version of .NET did not support dynamic code generation like it does now so the performance overhead was a little high when recompilation occurred. As of v2.0 ASP.NET compiles the ASPX files differently to reduce performance hit and to optimize memory.
The fact that web applications work similarly to other project types is also one of its greatest disadvantages. A web application has to be deployed as one entity. If different parts of the application are managed by different teams then some repository is needed to allow changes to be consolidated and deployment to occur. This infrastructure also slows down the rate of the site changes.
Web applications are designed for projects where the entire site is a single entity. Any changes to the project requires redeployment. Multiple teams must synchronize their code before a build can occur. The application code itself is protected from prying eyes when it is compiled into an assembly.
When Visual Studio 2005 (VS2005) was released Microsoft removed the web application project type and replaced it with a web site. Somebody at MS dropped the ball here because these project types are completely different. A web site project is more ideally suited for intranet sites where separate teams are responsible for different areas of the site. In an intranet environment the safety of the source code isn’t as important as a fast turnaround time. In a web site project almost all the project settings are either removed or stored in the application configuration file. Options like whether to generate documentation files or do code analysis simply don’t exist in web sites. This fits in with the web site philosophy of compile as needed.
Only code residing in the App_Code directory is compiled down into an assembly at build time. The remaining code becomes deployment items along with the ASPX files. This has advantages and disadvantages. Making changes to a web site requires that you merely replace the corresponding source or ASPX files. The ASP.NET runtime will recompile the code as needed. The turn around is therefore high. Pushing most of the project settings to the configuration file also means that upgrading to newer components or tweaking build settings requires a simple change to the config file rather than compilation and redeployment.
Perhaps the biggest weakness of the web site project type is that the source code is visible and changeable to the outside world. Outside world, here, meaning anyone with file access to the web directory. IIS prevents web access to the source and configuration files. Another issue is performance. As files change recompilation has to occur. ASP.NET only does this when a page is first referenced so viewing a page is noticeably slower the first time after a refresh.
After the VS2005 release there was an uproar in the community about the new web site project. It wasn’t that nobody liked it but rather many people didn’t want to be forced to use the new model, especially since it didn’t fit in with many application models. MS remedied the situation by shipping an addin that would add the web application project type back in. In VS2005 SP1 web applications were formally added back into the VS project list.
Web Deployment Projects
One area that neither type of web project covers is the compilation of ASPX files to assemblies. In the initial release each ASPX file resulted in a separate assembly. This was great for ASPX files that changed a lot but bad for performance as each page was compiled, not to mention the number of assemblies generated.
After VS2005 was released MS released the Web Deployment Project (WDP) addin (here). This addin exposed some new options for controlling how web sites were deployed. Rather than compiling the ASPX files when they are needed the addin allows for precompilation of the site to speed things up. This has no impact on the site behavior because if an ASPX file changes then a recompilation will occur anyway. The benefit of this approach is that the initial load of the site will be fast since the ASPX files are already compiled.
Another area where the addin is useful is controlling how the site is compiled. The addin allows: all the ASPX files in the site, all the ASPX files in a directory or each individual ASPX file to be compiled into separate assemblies. The best choice depends upon the site in question. The more ASPX files you combine into a single assembly the better the performance and memory usage will be but at the cost of more overhead when any of the files change.
The addin supports several additional features that makes it worthwhile if you are managing a web project. I recommend that you take a look at it. The multiple configuration file support is especially interesting although it was difficult to use in the initial release.
The addin technically doesn’t do a lot on its own. Instead it relies on a couple of ASP.NET tools that ship with .NET: aspnet_compiler and aspnet_merge. (aspnet_compiler is responsible for compiling the ASPX files. It is used to for precompilation and to control whether ASPX files can be updated after deployment. Refer to MSDN for full documentation.
aspnet_merge works in conjunction with aspnet_compiler to merge the various ASPX assemblies into a new assembly or set of assemblies. It also is responsible for determining what gets combined and what remains separated. Refer to MSDN for full documentation if you are interested. It is probably just better to use WDP instead.
Note that VS supports publishing web projects (site or app) directly without the need for deployment addins. However the publishing tool is strictly for publishing the existing project without changing most of the options. The deployment project is for taking more control over the publishing process.
We will now compare the two web project types so that you can make a more informed decision.
- Ideally suited for web projects that have little or no changes over time and in cases where the project code is proprietary. Applications that use a web front end are good examples.
- Standard project settings are available so a developer can configure the application.
- Since most of the code is pre-compiled the application performance is good.
- Deployment involves copying the ASPX files and the Bin directory.
- Other than minor UI changes any application changes require recompilation and redeployment.
- Upgrading to newer third-party components requires recompilation and redeployment.
- Turn around time for changes can be long depending on deployment process.
- Sites where different teams are responsible for the content are harder to synchronize.
- Faster turnaround for code and UI changes.
- Multiple teams can be working on different areas of the same site without compilation or deployment issues.
- Configuration and dependency changes can occur with a configuration file change.
- Page loading is slower after any changes are made.
- Source code is visible to anyone with file system access.
- Deployment requires shipping the ASPX files, Bin directory and source files.