History of ASP.NET Web Application Development
In order to understand why there are different types of Web applications, a brief history lesson in Visual
Studio .NET is required. Visual Studio.NET 2002/2003 required the developer to use Internet Information
Server (IIS) when building ASP.NET projects. Typically, IIS was installed on the local development machine.
Front Page Server Extensions (FPSE) had to be installed on IIS in order for Visual Studio to create and modify
Web sites. Creating a new Web application project involved creating a new IIS virtual directory, which the
IDE would create at the root of an IIS Web site. You could also optionally connect to an existing IIS virtual
directory by creating a new “empty Web project”.
This dependency on IIS was problematic in many situations. Many IT shops preferred not to deploy IIS to
workstations in the enterprise because it is a security risk to expose many unnecessary IIS Web servers. If
there was a mismatch between the project declaration and the IIS configuration on the local machine, the
project would simply fail to load. Every time a code-behind file was changed, the entire Web project had to be
recompiled and its Dynamic Link Library (DLL) had to be redeployed to the /bin/ folder on the Web server.
Some IT shops required all developers to use one installation of IIS on a dedicated server that all developers
had to share, which required developers to “take turns” attaching to the IIS process to debug the Web site!
Acknowledging the problems above, Microsoft released Visual Studio 2005 with ASP.NET 2.0. Microsoft
altered the development architecture by changing Visual Studio “Web Application Projects” to Visual Studio
“Web Sites”. A “Web Site” allows you to develop your Web site on a local file directory – IIS does not even
have to be installed. A “Web Site” allows each Web page to be “Just in Time” (JIT) compiled as they are
requested. Changes to a Web page do not require a complete recompilation and deployment of the Web site!
Web page requests were handled by a light weight development Web server that shipped with ASP.NET 2.0.
The Web server (called WebDev.WebServer.exe) was automatically started when you launched a new
debugging session in Visual Studio 2005. This lightweight server only handled a limited number of requests
and ran silently in the notification area (tray). It automatically chose a port number that was unused on the
Web deployment was made easier, too. Developers could either create the Web pages using a “single file” or
“code-behind” model. Developers could connect to and deploy ASP.NET Web sites to any File Transfer
Protocol (FTP) Web Server. Developers could also connect and deploy their Web sites to any IIS server, so
long as FPSEs were installed. These deployment tools were meant to be used by Web developers only, for
moving Web pages to staging servers.
However, many enterprises were upset by this entire change to the Web development and deployment
architecture. Some considered the solution to be less secure because they did not want to deploy the code-
behind files (.NET source code) to their Web servers. Many organizations had created hundreds of “Web
Application Projects” and the upgrade to “Web Sites” was going to be very expensive. Some decided to put
off upgrading their Web sites from ASP.NET 1.1 altogether until Microsoft “fixed” this problem.
Hearing the voice of the enterprises, Microsoft created an interim solution called the Web Application Project
(WAP) Visual Studio Add-In. This allowed developers to continue using the classic “Web Application
Project” architecture, making upgrades from ASP.NET 1.1 less painful. The WAP Add-In was eventually
rolled into Visual Studio 2005 Service Pack 1 (SP1). Installing SP1 automatically installed the WAP Add-In.
Microsoft released Visual Studio 2008 with .NET 3.5. It supports both development architectures that were
available in Visual Studio 2005 SP1. Developers still have the choice of developing a new Web Site (a
collection of JIT-compiled files in a folder) or a new Web Application Project (all code files compiled into one
DLL). Developers also have the choice of what version of ASP.NET they want to use with their Web sites (.
NET 2.0, 3.0 and 3.5). Additional support was added to both ASP.NET application types, as you’ll soon
see. As of Visual Studio 2008, the J# language has been completely dropped, but support for Linq,
Silverlight, AJAX and the W’s (WPF, WCF and WF) has been added.
ASP.NET 3.5 is actually just ASP.NET 2.0 with additional BCLs that run along side of it. Some of the Web
framework libraries were replaced in .NET 3.5 while others are still version 2.0. For example, ASP.NET 3.5
added support for new Web Server controls, Web server extensions, handlers, modules, DataSet extensions
and Linq. However, System.Web, the root-level namespace in ASP.NET, is still version 2.0.
Thus, it is safe to state that if the .NET 3.0 framework or .NET 3.5 framework is installed on a Web server,
you are guaranteed that the .NET 2.0 framework is also installed.
History of ASP.NET Web Application Development
Table of Contents
Copyright (c) 2008. Intertech, Inc. All Rights Reserved. This information is to be used exclusively as an
online learning aid. Any attempts to copy, reproduce, or use for training is strictly prohibited.