.NET Framework Overview

The Internet is evolving from a collection of isolated Web sites into a general communication bus for distributed applications. Not only could the applications be geographically separate, but they also could be running on different hardware and OS platforms. Yet, they can communicate with each other over the Internet. The key that makes this communication possible is Web services, a mechanism to exchange messages between distributed applications using industry standards such as XML and HTTP.

The .NET Framework was designed from the ground up around this vision. Support for XML and Web services is built into the framework. Any application developed for .NET has the potential to run on a variety of hardware and OS platforms.

The .NET Framework, however, had many other design goals as well. The following are some of the important ones that the .NET Framework addresses:

• Reduced plumbing: To provide a rich set of classes so that developers can write less code and reuse more.

• Simpler development: To provide a code execution environment that reduces software issues. For example, developers need not write code to free previously allocated memory; the framework provides a memory-management mechanism that frees any unused memory automatically.

• Simpler deployment: To make installing applications as easy as using a simple XCOPY command; also to support running multiple versions of the same component side by side.

• Unified programming model: To define a standard, consistent way of programming and facilitate cross-language programming.

• Scalability: To provide features that help developing scalable applications.

• Security: To support developing secure applications. Security is an important consideration for applications, especially if they are communicating over the Internet. The framework must guarantee that the code is safe to execute. Furthermore, the security system is granular—rather than a simple on–off switch, enabling the programmer or the administrator to control what can run depending on the user and the source of the program.

• Cross-platform integration: To build communication on industry standards such as SOAP so that .NET-based code can communicate with any other code.

• Interoperability: To support integrating .NET applications with native Win32 APIs and COM+ components.

Even if you do not intend to develop applications targeting the Internet, you can still use the .NET Framework to develop applications that are robust, secure, and reliable. Moreover, by leveraging the rich set of classes provided by the framework, you can achieve greater productivity.

Anatomy of the Framework

Figure 4.1 shows the major components of the .NET Framework.

The heart of the .NET Framework is the common language runtime, which is responsible for executing the managed code. During execution, the common language runtime provides features to the code such as automatic memory management, security, and so on. It sits on top of the Windows OS and, in the first version, uses COM+ services internally for some of its functionality.

The .NET Framework also provides more than 2,000 types (classes, interfaces, structures, etc.) that not only enable programmatic access to the features of the common language runtime, but also provide a number of useful high-level services to help developers boost productivity. These types are collectively referred to as the .NET Framework Class Library.

The .NET Framework Class Library can be broken down roughly into four groups:

The BCL implements the set of functionality that is shared by all the applications targeting the .NET Framework. It defines and implements all the core types such as System.String, System.Int32, and so on, that we have seen in the previous chapter, used by every application.

ADO.NET is the successor to an earlier data access technology called Active Data Object (ADO). ADO.NET provides a set of classes to access and manipulate data. The data is typically obtained from a database and can be converted to XML for better remote manipulation.

Windows Forms (often called WinForms) provides features for developing standard Windows desktop applications. It provides a rich, unified set of controls and drawing functions for all languages. It effectively wraps Windows user interface APIs in such a way that developers rarely need to access the Windows APIs directly.

ASP.NET is the successor to a Web request processing technology from Microsoft called Active Server Pages (ASP). ASP.NET adds two significant enhancements to ASP:

It is worth noting that the term ASP.NET is used in two different contexts. As a class library, it provides a rich set of classes to develop applications such as Web services and Web forms. ASP.NET also refers to a runtime infrastructure that runs under Internet Information Services (IIS) and services ASP.NET applications.

The Common Type Specification (CTS) defines rules so that compiler vendors can implement a programming language of their choice on .NET. Microsoft itself has implemented .NET compilers for many languages including C#, Visual Basic.NET, J#, JScript, and so on. Even existing C++ code can be compiled for .NET under what Microsoft calls It Just Works (IJW).

The CLS makes it possible for applications developed in different languages such as C# and Visual Basic.NET to communicate with the class library as well as with each other.

To develop applications, Microsoft also provides tools such as the .NET Framework SDK and Visual Studio .NET IDE. The SDK provides useful documentation, samples, programmer's tools, and so on. The IDE provides a number of features to boost developers' productivity.

A detailed coverage of ADO.NET and Windows forms is beyond the scope of this book, but we touch on them as necessary. As for ASP.NET, our focus is on the core aspects such as developing Web services. User interface-related topics are not covered.

Installing the Framework

To install the .NET Framework, Microsoft provides a stand-alone program (dotnetredist.exe) that can be downloaded from Microsoft's Web site. This file contains a file, dotnetfx.exe, that can be extracted by executing dotnetredist.exe. Running dotnetfx.exe installs the framework in the %windir%Microsoft.NetFrameworkv<version> directory where %windir% points to the Windows directory and <version> is the version number of the framework. On my system, this directory is C:WinNT Microsoft.NETFrameworkv1.0.3705.^[1]

^[1] The version number for the first release of the .NET Framework is 1.0.3705.

Note that installing the Framework SDK or Visual Studio.NET automatically installs the .NET Framework.

Redistributing the Framework

You can download the Microsoft .NET Redistributable Package (dotnetredist.exe) from Microsoft's Web site, extract dotnetfx.exe, and use it for redistribution. From your setup program, you need to execute dotnetfx.exe before installing any of your .NET executables. Dotnetfx.exe can also be found on the Windows Component Upgrade CD of Visual Studio. NET install CDs. Check the article “.NET Framework Deployment Guide” [MS-02] for complete information and the End-User License Agreement on redistributing the .NET Framework.

Managed Code Execution Overview

Figure 4.2 presents the overall picture of how the source code gets compiled, loaded, executed, and serviced by the .NET Framework.

A .NET-compliant compiler takes one or more source files as input and generates an assembly file (Chapter 3) as output.

A traditional compiler processes the source code and stores native machine language instructions in the output. A .NET-compliant compiler, however, does not generate machine language instructions. Instead, the instructions are stored in the assembly in a format called MSIL. As we will see shortly, when the assembly is executed, the runtime converts the MSIL instructions to native machine language instructions on the fly.

An assembly can be built either as a library (DLL) or as a stand-alone executable (EXE). From the runtime's perspective, there is no difference between these two types except that an EXE-based assembly is required to have an entry point of execution. The entry point method must be declared static and must be named Main. The method can optionally take command-line parameters as input and can optionally return an integer value. The following are possible method signatures for Main in C#:

static void Main();
static void Main(System.String[] argv);
static int Main();
static int Main(System.String[] argv);

Once built, the assembly can be copied to an application's local directory or subdirectory on the user's machine. An assembly can also be installed into the GAC (Chapter 3), if it is desired that the assembly be shared by many applications.

An application can also specify that an assembly be downloaded over the Internet. In this case, the runtime stores the assembly in an area called the download cache. Assemblies downloaded over the Internet run under lesser security privileges, thus safeguarding the machine from malicious intentions.

The part of the common language runtime that is responsible for loading and executing an assembly is called the execution engine (EE). The EE is composed of many units, each of which is responsible for executing a specific task or tasks:

• The assembly resolver locates an assembly using some heuristics and externally specified configuration information.

• The assembly loader loads an assembly and stores in memory information about the assembly such as the name and version of the assembly and the available list of classes.

• The policy manager grants certain security permissions to an assembly based on externally specified security policy and the source of the assembly.

• The class loader loads a class and constructs an in-memory representation of the class such as its virtual table (vtable).

• The JIT compiler coverts the MSIL code to the native code. In the process, it checks the metadata for consistency (this is called validation) and verifies whether the code is safe to execute.

• The configuration manager makes externally specified configuration information available to any entity within the EE that needs it.

When an assembly's code is to be executed, the assembly resolver locates the assembly based on the name of the assembly and certain other characteristics, such as its version number and the external configuration. If need be, the assembly is downloaded over the network. The assembly is then loaded into the EE. The loader stores the information about the assembly and the list of classes it exposes in an internal table.

Before any code from the assembly can be executed, the EE consults the policy manager for granting certain security permissions for the code. In granting permissions, the policy manager checks the externally specified policy against certain characteristics of the assembly. For example, an assembly that has been downloaded over the Internet is granted a lesser degree of permissions such as being unable to read or write to the hard drive.

The class loader then loads the class containing the code to be executed and stores information about the class in an internal table.

Recall that the code is typically stored in MSIL form in the assembly. Before executing a class method, the MSIL code has to be converted into the native code. This on-the-fly conversion is referred to as JIT conversion. The part of EE that is responsible for this conversion is called the JITter. Besides compiling the MSIL code, the JITter also performs some additional checks on the code, such as verifying the code for type safety.

As the code is executing, the EE provides certain services to the code, such as the following:

• Automatic memory management

• Code access security

• Debugging and profiling services

• Interoperability with unmanaged code

We have already learned about managed code and unmanaged code in the previous chapter, but here is a refresher. For the EE to provide services to the executing code, the code must meet certain requirements of the common language runtime and must supply certain necessary metadata to the EE. Such code is called managed code. All code based on MSIL executes as managed code. However, one can always develop code without regard for the convention and requirements of the common language runtime. There is plenty of existing code written this way. Such code is referred to as unmanaged code. Although the EE can execute unmanaged code, the code cannot avail the services provided by the EE. For example, the EE cannot provide automatic memory management or code safety for unmanaged code.

As the code executes, it may call additional methods. If the method being called has not yet been compiled, the EE interrupts the code to JIT the method. In the process, a new assembly may get loaded (e.g., if the method being called belongs to a different assembly) or additional classes may get loaded.

The execution continues until the program comes to a logical ending (returns from Main). The execution also stops if the program gets aborted. This may happen, for example, if an exception is thrown, either by the program or by the runtime, and the program fails to catch the exception.

In the rest of the chapter, we examine each of the major steps of the managed-code execution process. The idea is to get a good understanding of the development, deployment, and execution processes under .NET. Some other aspects, such as interoperability, security, distributed computing, and so on, are covered in later chapters.

Before we proceed further, there is one thing worth mentioning. The .NET Framework provides a decent set of performance counters that you may wish to look at. It will give you a good insight into the managed execution process and help you track the performance of your application.

.NET Performance Counters

Track your application's performance by monitoring .NET performance counters. These counters can be viewed, for example, by using an OS-supplied tool, perfmon.exe.