The .NET Framework Components and ECMA

In this book, we mostly follow the common informal usage as far as terminology is concerned, in which the terms .NET Framework and CLR are used roughly interchangeably, both to mean the whole set of software Microsoft has written that allows you to run managed code on Windows. The term .NET Framework possibly has a broader meaning, since it also includes support libraries and tools that are useful but not essential to run managed code, and are not part of the CLR. The CLR provides the runtime environment, and consists of a number of components implemented by various DLLs, including mscoree.dll, mscorjit.dll, and so on.

The diagram shows the main components of the framework:

click to expand

Many of the boxes in this diagram will be familiar to you. For simplicity, I've only marked a few components of the CLR that are particularly relevant to code execution. Other aspects of the CLR include, for example, the code responsible for security and for reflection.

It's worth making the following observations:

  • An important distinction between the CLR and the class library is that the CLR is written in unmanaged C++, while the framework classes are almost entirely written in C# - managed code which depends on the CLR to execute.

  • The class loader performs the first stage of processing when some managed code is to be executed. It reads the assembly, using the hash to check the assembly has not been tampered with. It then reads the metadata, and from the metadata works out how to lay out the types defined in the assembly in memory. For types that have been defined with auto layout (as opposed to sequential or explicit), it is the loader that decides what order the fields will be arranged in. I mention it here because it is not so well known as other related components such as the JIT compiler.

The ECMA Standard

What I've just presented is the .NET Framework as implemented by Microsoft. You'll no doubt be aware that a core part of the specifications of the framework have been accepted as ECMA standard 335. This standard defines what is formally known as the Common Language Infrastructure (CLI) - a set of minimum features that should be supported by any software product that implements the equivalent of the .NET Framework. The ECMA standard indicates the supported feature set, including the definition of Intermediate Language, but does not define any particular implementation.

The ECMA standard can be broken down into two components: the Virtual Execution System (VES), which is the actual environment under which the code should run, and the libraries. Hence, under this scheme, the .NET Framework is an implementation of the CLI, the CLR is an implementation of the VES, and the .NET Framework Class Library is an implementation of the ECMA spec for the libraries. However, the .NET Framework goes further than this: both the CLR and the .NET Framework Class Library implement many additional features that are not defined in the ECMA specs.

Amongst the features defined by the CLI are:

  • The common type system

  • The file format for assemblies

  • Common Intermediate Language (CIL - note that IL and MSIL are just alternative names for CIL)

  • The extensible metadata system

The CLI is formally defined in five documents that are formally known as the partitions. You can find these documents at http://www.ecma.ch/ecma1/STAND/ecma-335.htm. Alternatively, copies of the partitions are supplied as Word documents in the Tool Developers Guide\Docs subfolder in the .NET Framework SDK. These documents cover the following areas:

  • Partition I Architecture. This describes the architecture of the CLI.

  • Partition II Metadata. This is the largest of the documents. It describes in detail not only the items of metadata in an assembly, but also PE assembly file format. It includes, for example, specifications of value and reference types, enums and delegates, method calling conventions, and so on. It also gives the syntax for IL assembly language, and defines the IL source code directives.

  • Partition III CIL. This partition specifies the instruction set for Intermediate Language, along with some background information. It includes a complete list of CIL opcodes.

  • Partition IV Library. Explains the difference between the kernel and compact profiles (see below), and indicates the libraries required for each.

  • Partition V Annexes. Contains information about various other topics, including good programming guidelines and information about some portability considerations.

Besides defining the CLI, these documents also specify (in Partition IV) two possible levels of implementation: a compact implementation and a kernel implementation. Software is said to provide a compact implementation if it implements everything defined in the CLI. On the other hand, it could alternatively implement a more restricted set of features, known as the kernel features, in which case it is a kernel implementation of the CLI. Having said that, though, the kernel implementation isn't that much more restrictive than the compact implementation. In reality, it includes almost everything with just a few exceptions, the most significant being that there is no requirement to support floating-point numbers in the kernel implementation.

As you might expect, the .NET Framework implements virtually everything as defined in the CLI, and so is for most practical purposes a compliant compact implementation - besides implementing a huge superset of features not defined in the CLI (a more sophisticated JIT compiler and garbage collector, many more class libraries, etc.) There are, however, a few places in the documents in which it is indicated that the CLR does not implement some small feature that is strictly speaking a formal CLI requirement, at least in version 1 of the .NET Framework. These few exceptions are relatively minor, and I would imagine are very likely to be addressed in future .NET Framework releases.

The ECMA Libraries

I've mentioned that the ECMA standard includes class libraries. The standard defines the classes, the signatures of their methods, and their purposes. The .NET Framework Class Library of course includes all the libraries in the ECMA definition, as well as a lot more. Here I'll briefly summarize which classes are defined by the ECMA libraries. Full details are available from the ECMA web site.

A kernel implementation of the CLI should provide these libraries:

  • The Runtime Infrastructure Library includes classes required by compilers that target the CLI.

  • The Base Class Library contains many of the basic classes in the System, System.IO, System.Collections, and other namespaces, including classes to support string handling, primitive types, file I/O and collections.

A compact implementation of the CLI should in addition provide these libraries:

  • The Network Library, which contains classes to support networking.

  • The Reflection Library, which contains classes to support reflection.

  • The Xml Library, which contains some of the classes in the System.Xml namespace.

  • The Extended Numerics Library, which provides support for floating-point arithmetic. For example, the System.Single and System.Double types count as being in this library.

  • The Extended Array Library, which supports multi-dimensional arrays and arrays that are not zero-indexed.

I only list these libraries here for reference. When you are actually using the classes in them, you certainly don't need to worry about which library a particular class comes from - after all, lots of .NET developers are almost certainly even now writing code that uses all the classes in the framework class library, without even being aware of the existence of the formal CLI libraries. The specifications of the CLI libraries may become relevant in the future though, if .NET is ever ported to another platform and you need to start worrying about whether your code is portable.

Framework SDK Resources

For basic .NET programming, the information in the MSDN documentation is normally adequate as far as documentation goes. However, many of the topics that we cover in this book are not documented in MSDN. Instead, there are resources in the Framework SDK that you may find useful. These include:

  • The Tool Developers Guide, which consists of Microsoft Word documents that describe certain advanced features of .NET, as well as copies of the ECMA partition documents. This includes documentation for several unmanaged APIs that are exposed by the CLR, including the debugging API (which allows debuggers to attach to running managed processes), the metadata API (allows compilers to generate metadata for assemblies), and the profiling API (allows profilers to attach to running managed processes).

  • Header files that define many of the constants and internal C structures used in .NET and in assemblies, as well as structures and interfaces required by the unmanaged APIs.

  • A number of advanced samples.

You can locate all this information by browsing around the folder in which you have installed the Framework SDK, and its subfolders.

Shared Source CLI

Another source of invaluable resources for anyone who wants to understand the internal working of the CLR is Microsoft's Shared Source CLI (code-named Rotor). Rotor is a complete implementation of the ECMA-standard CLI that will work on the Windows XP and the FreeBSD operating systems. The best bit of it is that it's free (subject to licensing restrictions), and it comes with source code! Microsoft has provided Rotor for the benefit of developers who want to experiment with .NET, or use it for research purposes, for example to see how a CLI could be implemented. Studying the Rotor source, or compiling it and playing around with it, will give you an idea of how things can be implemented at a logical level to conform to the ECMA standard. I am also told that, although the JIT compiler and the garbage collector in Rotor are far simpler than those of the CLR, the remainder of the implementation very closely matches the CLR itself. You can download the source code for Rotor at http://msdn.microsoft.com/downloads/default.asp?URL=/downloads/sample.asp?url=/MSDN-FILES/027/001/901/msdncompositedoc.xml.

While we are on the subject of alternative implementations, it's also worth mentioning the Mono project. This is an open source community-based CLI implementation primarily aimed at the Linux platform, though it also runs on Windows, Solaris, and FreeBSD. You can find out about Mono at http://www.go-mono.com/.

Finally, we should mention DotGNU Portable.NET (http://www.southern-storm.com.au/portable_net.html), which is a CLI implementation targeted initially at Linux platforms. This forms part of the wider DotGNU project that includes other components and tools that aren't related to the CLI, and which aims eventually to comprise an "operating system for the Internet".



Advanced  .NET Programming
Advanced .NET Programming
ISBN: 1861006292
EAN: 2147483647
Year: 2002
Pages: 124

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net