Prior to the first release of ASP.NET, the tools available to developers for creating powerful and compelling web applications were limited and immature.
One of the first widespread tools for creating web applications was the CGI (Common Gateway Interface) standard, which essentially allowed a customized console application to run when invoked from the web and return a stream of text to the end user that served as an HTML page.
When the first version of the .NET Framework was released, it was released with ASP.NET. ASP.NET is a framework that takes the concept introduced by classic ASP to a new level. It allows you to write managed, compiled, secure, and reliable code to drive your web application, as well as providing a hefty library of code that automates standard web application tasks such as security, authentication, authorization, membership, and much more.
ASP.NET works by compiling the content in your web application into an assembly that is then used by Internet Information Server (IIS) to service requests for pages and web services. The ASP.NET Framework is made up of several components, including a page and control hierarchy, the page and control compiler, security management, state management, and application configuration. Each of those components is discussed in this section.
Don't worry if some of the information presented in the sections seems a little vague. As you progress through the ASP.NET chapters of this book, each of the items discussed here will be discussed in more detail with plenty of code samples and practical applications.
Page and Control Hierarchy
Tools such as Active Server Pages (ASP) worked by allowing the developer to write script that output text to a web page. This could become extremely tedious, and reading and maintaining code like that could become burdensome.
ASP.NET provides an entirely object-oriented approach to creating web pages and applications. There are classes that represent pages, applications, user controls, server controls, and much more. By allowing controls to become first-class objects, it becomes much easier to create powerful, reusable visual elements that can be reused among multiple pages or applications. Object inheritance can be used to create entire hierarchies of controls with expanding functionality.
ASP.NET 2.0 provides additional features that allow your applications to support skins and themes for enhancing an application's look and feel. Another feature new to ASP.NET 2.0 is the concept of master pages, which allow for a kind of visual inheritance among pages, further enhancing the code reuse that is already available in ASP.NET.
Introduction to the ASP.NET 2.0 Compiler
The ASP.NET 2.0 compiler makes use of partial classes to merge the ASP.NET markup found in .aspx and .ascx files with the code contained in associated C# files to produce a compiled assembly.
Each ASP.NET page has basically two halves: the half contained in a .aspx file that contains HTML markup and ASP.NET server controls, and the other half, which contains the remainder of the code. With partial classes, each ASP.NET page produces a single class, even though it is made up of at least two files.
Finally, another major benefit of having fully managed and compiled ASP.NET pages is that each ASP.NET page or control that you create has access to all the same functionality that any other managed application has, and it has that access in a tightly bound fashion. Classic ASP generally required late binding to make use of external components, and those components had to be COM-based.
Above and beyond Code Access Security features that are an inherent part of any managed code application, ASP.NET 2.0 provides a powerful suite of tools and features that help developers create secure applications. ASP.NET has built-in features that manage user authentication using cookies, specially written URLs, Windows authentication, and even support for Microsoft Passport.
Additional providers, tools, and controls are also available that assist in managing user membership on your site, user security roles, and much more.
HTTP is what is known as a stateless protocol. This means that the protocol itself has no support for maintaining state between multiple requests for a page. HTTP on its own can't provide the facilities required to maintain state information on a web application such as shopping carts, control state persisting between subsequent requests for the same page, or even simple things such as the current user's name.
ASP.NET provides facilities for maintaining state that HTTP itself can't provide. There are facilities for managing session state, which is a temporary store of information that persists for a specific user as long as that user is actively using the application. ASP.NET can manage session state directly within the application process, or it can maintain distributed session state to allow your application to share session state among the multiple servers within a Web Farm. In addition to session state, each ASP.NET control can persist its own state between subsequent requests for the same page through a mechanism called ViewState. ViewState essentially replaces the old technique of using hidden form variables to persist control state information between page requests. It stores information such as a control's items, width, height, state, and more in a specialized string that stores name/value pairs.
The Web Configuration System
The .NET Framework contains built-in functionality that supports the use of application configuration files. These files are XML files that contain information about .NET configuration as well as application-specific configuration.
ASP.NET extends the default .NET Framework configuration files to include several new sections that control web application configuration. By modifying the XML in these configuration files, you can control the authentication and authorization settings for your application, as well as error handling, tracing, debugging, and much more. The use of these configuration files makes deployment a much easier task. You can store connection strings in a configuration file, and then have a different configuration file for each of your build, stage, and production environments. Without such configuration files, managing multiple instances of the same application without writing a lot of unnecessary code would be extremely difficult.