ASP.NET 2.0 is built upon Microsoft's Common Language Runtime. In its earliest days, programming Windows involved interacting with the operating system at a very intimate level. For example, getting a Window to show up on a screen took many lines of C code. In addition, Windows included a rudimentary component technology—raw Dynamic Link Libraries. Dynamic Link Libraries (DLLs) represent a necessary technology to enable composing systems dynamically—that is, to assemble applications from several disparate binary components. However, DLLs by themselves are not sufficient for composing systems reliably—primarily because it's very difficult to manage multiple versions of a component (a DLL).
During the mid 90's, the Component Object Model (COM) emerged as a way to help manage multiple versions of a component. By stipulating strict rules about how clients and components may interact, COM represented a technology sufficient for composing applications from different binary components. However, COM faced a few dead ends which became apparent as developers began building larger systems.
First, COM relied on humans following rules to get things to interoperate. For example, COM stipulates a rule that once a programmatic interface is published, it must never change. Changing a published COM interface after clients begin coding against it will almost certainly bring a system to its knees. In addition, COM relied on sometimes obtuse rules as far as managing resources. However, the coup de grace for COM was probably the disparate type systems involved. That is, COM represented many data types differently for three separate classes of developers: C++ developers, Visual Basic developers, and scripting developers. The different data type systems made it extremely inconvenient to build systems built from different languages. It could be done, but developers had to be very wary when making calls across such component boundaries.
.NET and the Common Language Runtime (the CLR) were developed to solve the dead ends appearing in COM near the end of the last century. When you choose to buy into the .NET runtime, it's like putting your code in a nice hotel room when it runs. For example, the .NET runtime loads and manages your code as it runs. Pure memory leaks are a thing of the past because the runtime collects garbage when necessary. The problem of overrunning array boundaries disappears because the .NET runtime keeps careful watch over memory and knows when anything is out of place. In addition, the .NET runtime includes a new security model making it more difficult to hack into .NET-based software. Finally, the .NET runtime introduces a new packaging and deployment model, .NET Assemblies, which helps enforce versioning components.
ASP.NET is founded on the .NET runtime. As we'll see in the following chapters, ASP.NET runs completely under the auspices of the CLR. After IIS hands an HTTP request off to ASP.NET, it runs through the ASP.NET pipeline. The request may be intercepted at various places along the way, and you have ample opportunity to interrogate the request and modify the response before it finally leaves the ASP.NET runtime. Gone is the COM layer between the HTTP request processing machinery and a business's domain objects. Domain objects running under .NET can be linked into the request processing pipeline for high performance and tight security. In addition, because all .NET components agree upon the data types being passed between them, there are no more bizarre data conversions (as there used to be in classic ASP).
In the process of building ASP.NET applications you will be developing .NET assemblies—most of the time implicitly, but sometimes explicitly. While you'll be focusing on ASP.NET as a Web application framework, you'll develop a strong familiarity with the .NET runtime as well. Very often, the classes you use in an ASP.NET application are the same or very similar to those you'd use in a console application, a Windows application, or even a component library.