1.1. Overview of the .NET Framework
| < Day Day Up > |
| The .NET Framework is designed as an integrated environment for seamlessly developing and running applications on the Internet, on the desktop as Windows Forms, and even on mobile devices (with the Compact Framework). Its primary objectives are as follows:
To achieve these broad objectives, the .NET Framework designers settled on an architecture that separates the framework into two parts: the Common Language Runtime (CLR) and the Framework Class Library (FCL). Figure 1-1 provides a stylized representation of this. Figure 1-1. .NET Framework
The CLR which is Microsoft's implementation of the CLI standard handles code execution and all of the tasks associated with it: compilation, memory management, security, thread management, and enforcement of type safety and use. Code that runs under the CLR is referred to as managed code. This is to distinguish it from unmanaged code that does not implement the requirements to run in the CLR such as COM or Windows API based components. The other major component, the Framework Class Library, is a reusable code library of types (classes, structures, and so on) available to applications running under .NET. As the figure shows, these include classes for database access, graphics, interoperating with unmanaged code, security, and both Web and Windows forms. All languages that target the .NET Framework use this common class library. Thus, after you gain experience using these types, you can apply that knowledge to any .NET language you may choose to program in. Microsoft .NET and the CLI StandardsA natural concern for a developer that chooses to invest the time in learning C# and .NET is whether the acquired skill set can be transferred to other platforms. Specifically, is .NET a Microsoft product tethered only to the Windows operating system? Or is it a portable runtime and development platform that will be implemented on multiple operating systems? To answer the question, it is necessary to understand the relationship among Microsoft .NET, C#, and the Common Language Infrastructure (CLI) standards. The CLI defines a platform-independent virtual code execution environment. It specifies no operating system, so it could just as easily be Linux as Windows. The centerpiece of the standard is the definition for a Common Intermediate Language (CIL) that must be produced by CLI compliant compilers and a type system that defines the data types supported by any compliant language. As described in the next section, this intermediate code is compiled into the native language of its host operating system. The CLI also includes the standards for the C# language, which was developed and promoted by Microsoft. As such, it is the de facto standard language for .NET. However, other vendors have quickly adopted the CIL standard and produced just to name a few Python, Pascal, Fortran, Cobol, and Eiffel .NET compilers. The .NET Framework, as depicted in Figure 1-1, is Microsoft's implementation of the CLI standards. The most important thing to note about this implementation is that it contains a great deal more features than are specified by the CLI architecture. To illustrate this, compare it to the CLI standards architecture shown in Figure 1-2. Figure 1-2. Architecture defined by CLI specifications
Briefly, the CLI defines two implementations: a minimal implementation known as a Kernel Profile and a more feature rich Compact Profile. The kernel contains the types and classes required by a compiler that is CLI compliant. The Base Class Library holds the basic data type classes, as well as classes that provide simple file access, define security attributes, and implement one-dimensional arrays. The Compact Profile adds three class libraries: an XML library that defines simple XML parsing, a Network library that provides HTTP support and access to ports, and a Reflection library that supports reflection (a way for a program to examine itself through metacode). This book, which describes the Microsoft implementation, would be considerably shorter if it described only the CLI recommendations. There would be no chapters on ADO.NET (database classes), ASP.NET (Web classes), or Windows Forms and the XML chapters would be greatly reduced. As you may guess, these libraries depend on the underlying Windows API for functionality. In addition, .NET permits a program to invoke the Win32 API using an Interop feature. This means that a .NET developer has access not only to the Win32 API but also legacy applications and components (COM). By keeping this rather wide bridge to Windows, Microsoft's .NET implementation becomes more of a transparent than virtual environment not that there's anything wrong with that. It gives developers making the transition to .NET the ability to create hybrid applications that combine .NET components with preexisting code. It also means that the .NET implementation code is not going to be ported to another operating system. The good news for developers and readers of this book is that the additional Microsoft features are being adopted by CLI open source initiatives. Mono[2] , one of the leading CLI projects, already includes major features such as ADO.NET, Windows Forms, full XML classes, and a rich set of Collections classes. This is particularly significant because it means the knowledge and skills obtained working with Microsoft .NET can be applied to implementations on Linux, BSD, and Solaris platforms. With that in mind, let's take an overview of the Microsoft CLI implementation.
|
| < Day Day Up > |
