The .NET Framework

The .NET Framework is an essential technology for ASP.NET development. It provides the basic system services that support ASP.NET, as well as Windows Forms development, the new rich client development technology provided by .NET. Much like the Microsoft Windows NT 4.0 Option Pack, which was an add-on to Windows NT 4.0 that added Internet Information Server 4.0 and Active Server Pages technologies to NT 4.0, the .NET Framework is an add-on to Microsoft Windows XP, Windows 2000, Windows NT 4.0, and Windows 98/ME that adds the basic supporting system services for .NET technologies. The framework will also be built into newer releases of the Windows server operating system line, including the Windows Server 2003 line.

The .NET Framework consists of two main parts:

• The common language runtime

• The .NET Framework class library

The Common Language Runtime

The common language runtime (CLR) provides a run-time environment for the execution of code written in any .NET language. The CLR manages the execution of .NET code, including memory and object lifetime management. In addition to these management services, the CLR allows developers to perform debugging, exception handling, and inheritance across multiple languages. Performing these tasks requires that the language compilers follow the Common Language Specification (CLS), which describes a subset of the data types supported by the CLR that are common to all of the languages used in .NET.

The individual language compilers compile the code written by developers into an intermediate language called Microsoft Intermediate Language (IL or MSIL). The IL is then Just-In-Time (JIT) compiled at first execution. Optionally, IL assemblies may be compiled to native code by the CLR at install time using a utility called ngen.exe. This can improve startup time, although at some cost to performance, due to optimizations available during JIT compilation. Note that ngen.exe cannot be used for assemblies generated from ASP.NET pages and code-behind classes.

Code that is compiled to IL and managed by the CLR is referred to as managed code. It’s called this because the CLR takes responsibility for managing the execution of the code, including the instantiation of objects, allocation of memory, and garbage collection of objects and memory.

Components written in managed code and executed by the CLR are referred to as .NET managed assemblies, or assemblies for short. Assemblies are the basic unit of deployment in the .NET world and are quite similar to COM components. The difference is that whereas a COM component has a type library to describe how clients should interact with it, an assembly contains a manifest, which is the set of metadata that describes the contents of the assembly. Among other advantages, the self-describing nature of .NET components means that they don’t need to be registered on a computer in order to work!

This metadata also describes the dependencies and version information associated with an assembly. Not only does this make it much easier to ensure that all necessary dependencies of an assembly are fulfilled, but it also means that multiple versions of the same assembly can be run side by side on the same computer without conflict. This is a major step in resolving “DLL Hell,” the bane of many developers’ existence. Just ask any Web developer who’s worked with more than one version of Microsoft ActiveX Data Objects (ADO), and you’re sure to get an earful about applications being broken by a new version of ADO. With .NET, this issue should be a thing of the past. As long as the consuming application knows which version of an assembly it’s designed to use, it can locate the correct version among multiple versions of the same assembly by querying the assembly’s metadata.

There’s a great deal more to the CLR, which you’ll learn in future chapters. If you need further information on the CLR, do a search on “common language runtime” in either the .NET Framework SDK documentation or the MSDN Library documentation for Visual Studio .NET.

The .NET Framework Class Library

The .NET Framework class library is designed to support the efforts of developers by providing base classes from which developers can inherit. This class library is a hierarchical set of .NET classes that developers can use in their own applications. These classes, which are organized by containers referred to as namespaces, provide both basic and advanced functionality that developers can easily reuse. They include classes that support basic common datatypes; classes that provide access to data; and classes that support such system services as drawing (good news for anyone who’s had to use a third-party component for dynamically creating graphics in an ASP application), network functionality (including DNS and reverse DNS lookups), and many others.

The library also contains the classes that form the basis of ASP.NET, including the Page class (a part of the System.Web.UI namespace) from which all ASP.NET pages are derived, as well as many other classes in the System.Web namespace and the other namespaces nested under System.Web. Later chapters will discuss several of these classes.

Inheritance

Inheritance is a central concept in the .NET Framework. It provides a way for developers to use existing code in classes. A class can expose both properties and methods that clients can use. Classes that are inherited from a particular base class are said to be derived from that class. By inheriting from a class, a developer can reuse the functionality that it exposes without having to rewrite the code.

In addition (and more important), a developer creating a derived class can override one or more of the methods exposed by the parent class in order to provide a specialized implementation of that functionality. This capability will come in handy when you learn about custom server controls in Chapter 10.

.NET Languages and Language Tools

One of the best things about the .NET platform is that whereas classic ASP restricted developers to using scripting languages (with their inherent limitations), ASP.NET lets you work with any .NET-compliant language. This means that the code you write in ASP.NET is compiled for better performance, and you can take full advantage of advanced language features.

For the .NET platform, languages (and the development tools with which you’ll use them) are probably one of the most important topics to discuss. Let’s take a high-level look at some of the languages and tools that will be available for developing .NET applications.

Notepad and Other Text Editors

Believe it or not, many developers, particularly ASP developers, still do much of their development in Microsoft Notepad (which I used to lovingly refer to as “Visual” Notepad) or other free or inexpensive text editors. While Notepad has the substantial advantage of being ubiquitous, it’s not exactly what you’d call a robust development environment. That said, if you’re working with the .NET Framework SDK (rather than Visual Studio .NET), there’s no reason you can’t use Notepad (or another favorite text editor) to do all of your .NET development. The .NET Framework SDK includes command-line compilers for Microsoft Visual Basic .NET, Microsoft Visual C# (pronounced “C sharp”), and Microsoft JScript .NET. So, you can create your classes, ASP.NET pages, and so on in Notepad, and then you can either compile them explicitly using the command-line compilers or, in the case of ASP.NET, allow the ASP.NET runtime to dynamically compile the page when it’s requested for the first time.

Visual Studio .NET

For simpler and faster development, most developers will probably want to work in Visual Studio .NET, which provides a single integrated development environment (IDE) for all of Microsoft’s .NET languages (with the exception of Microsoft Visual FoxPro 7.0, which does not use the CLR or the .NET Framework). This means that developers of Visual Basic, Microsoft Visual C++, and C# all share the same IDE, including the capability to perform debugging and exception handling across languages, in the same environment.

Visual Studio .NET provides a substantial number of new features, including

• A single, unified programming model for all .NET languages and for both Windows and Web applications

• Drag-and-drop development for the server using the Server Explorer

• Dynamic Help

• A robust customization and extensibility model for the IDE

• Strong support for XML

• Web services with dramatically easier cross-platform application integration

You’ll learn more about the Visual Studio .NET environment later in this chapter.

C#

A new member of the Visual Studio family, C# is a descendent of the C language. It’s much like C++, but designed with greater simplicity and ease of use in mind. Although C# isn’t necessarily as easy to learn as Visual Basic, it’s far easier than C++ and provides nearly all of the power available to C++ developers. It also doesn’t require you to manage the allocation and deallocation of memory, as C++ does. Because C#, like Visual Basic .NET, is a managed language, all of the memory management is taken care of by the CLR. This is an important advantage because memory management is one of the most troublesome areas of C++ development and is responsible for many application crashes.

Developers familiar with C, C++, and Java will quickly become productive using C#. This book will include some code examples in C# to give you a taste of this exciting new language.

Additional .NET Languages

Visual Studio .NET also ships with JScript . NET, Visual C++, and the managed extensions for Visual C++, which allow C++ developers to target their applications to the CLR.

Visual Studio .NET also provides an extremely flexible plug-in architecture that allows other languages written for or ported to the .NET platform to easily use the power of the Visual Studio IDE. The current list of third-party languages planned for Visual Studio .NET includes

• APL

• COBOL

• Eiffel

• FORTRAN

• Haskell

• Mercury

• Mondrian

• Oberon

• Pascal

• Perl

• Python

• RPG

• Scheme

It’s important to point out that while some of the languages shown in the preceding list will be commercial implementations, some others are research projects being conducted by universities and might never reach commercial
status. Still, between the languages that ship with Visual Studio .NET and the third-party languages that are or will be available, there should be a language to please just about any developer.