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 local machine.
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.
Copyright (c) 2008-2013. 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.