Like any other platform, the .NET Framework introduces terminology that you need to be aware of. Following is a list of some of these terms.
1.1 CLR
The Common Language Runtime (CLR) is a key .NET Framework
component. The CLR is the container, or the execution environment, in which all the managed code runs. The CLR gets its name from the fact that .NET provides a binary standard and any programming language that adheres to the binary standard can be used for writing code that can be run by the CLR. In its function and nature, the CLR is similar to the Java Virtual Machine (JVM). The CLR provides infrastructure services to support execution of managed code. These services include automatic memory management, type safety, thread and process management, security, and versioning. The CLR sits between the managed code and the operating system so that your code is insulated from interacting directly with the operating system. This arrangement makes your code portable to some extent and also frees you from having to do system-level tasks so that you can concentrate on writing application code.
Microsoft .NET Framework provides a Common Language Runtime (CLR) that manages the execution of source code after being compiled into Microsoft intermediate language (MSIL), OptIL, or native machine code. All code based on MSIL or OptIL executes as managed code; that is code that runs under a "contract of cooperation" with the .NET Framework. The.NET Framework provides services such as memory management, cross language integration, exception handling, code access security, and automatic lifetime control of objects. In return, managed code must supply enough information in metadata to enable the .NET Framework to locate and unwind stack frames. For a high level description of the features that the .NET Framework provides to managed code, see the ".NET Framework Overview" specification. A key feature of CLR is its ability to provide software isolation of programs running within a single address space. It does this by enforcing typesafe access to all areas of memory when running typesafe managed code. Some compilers generate MSIL that is not only typesafe but whose type safety can be proven by simply examining the MSIL. This process, verification, allows servers to quickly examine user programs written in MSIL and only run those that it can demonstrate will not make unsafe memory references. This independent verification is critical to truly scalable servers that execute user-defined programs (scripts).
The CLR provides the following services:
Code management
Software memory isolation
Verification of the type safety of MSIL
Conversion of MSIL to native code
Loading and execution of managed code (MSIL or native)
Accessing metadata (enhanced type information)
Managing memory for managed objects
Insertion and execution of security checks
Handling exceptions, including cross-language exceptions
Interoperation between .NET Framework objects and COM objects
Automation of object layout for late binding
Supporting developer services (profiling, debugging, etc.)
The CLR supplies the common infrastructure that allows tools and programming languages to benefit from cross-language integration. Any
technical improvements to the CLR will benefit all languages and tools that
target the .NET Framework.
One of the most important functions of the CLR is on-the-fly conversion of MSIL (or OptIL) to native code. Source code compilers generate MSIL (or OptIL), and JIT compilers convert that MSIL to native code for specific machine architectures. As long as a simple set of rules is followed by the MSIL generator, the same MSIL code will run on any architecture that supports the .NET Framework. Because the conversion from MSIL to native code occurs on the target machine, the generated native code can take advantage of hardware-specific optimizations. Other significant CLR functions include class loading, verification, and support for security checks
1.2 Managed Code
Managed code runs under a contract of cooperation with the CLR. This means that managed code must supply the metadata necessary for the runtime to provide services such as memory management, cross-language integration, code access security, and automatic control of object lifetime
1.3 MSIL
The Microsoft Intermediate Language (MSIL) is the equivalent of Java byte code. The MSIL executes the managed code. Languages that support generating MSIL can leverage the infrastructure services of the CLR. MSIL is a stack-based set of instructions designed to be easily generated from source code by compilers and other tools. Several kinds of instructions are provided, including instructions for arithmetic and logical operations, control flow, direct memory access, exception handling, and method invocation. There is also a set of MSIL instructions for implementing object-oriented
programming constructs such as virtual method calls, field access, array access, and object allocation and initialization.The MSIL instruction set can be directly interpreted by simply tracking the
data types on the stack and emulating the MSIL instructions. It can also be converted efficiently into native code. The design of MSIL allows this process to produce optimized native code at reasonable cost. The design of MSIL allows programs that are not typesafe to be expressed, since this is essential for support of some common programming languages. At the same time, by following a simple set of rules, it is possible to generate MSIL programs that are not only typesafe but can easily be proven to be so (see the Verification section for more information about type safety and verification).
OptIL is a subset of MSIL that can be generated by optimizing compiler front ends. OptIL contains embedded annotations, which are MSIL instructions that supply control flow and register allocation information. Since OptIL is a subset of MSIL, any component that can execute or analyze MSIL can also analyze or execute OptIL (ignoring the embedded annotations if necessary). The OptJIT compiler (to be shipped in a future release), however, uses the embedded information to rapidly produce optimized native code. The correctness of this native code depends on the annotations, so they are subject to verification. OptIL is useful in situations where limited time and memory resources are available during the conversion to native code (ie at JIT time), yet the native code produced must meet high performance standards.
1.4 JIT Compilation
The CLR provides three JIT compilers for converting MSIL to native code:
EconoJIT, JIT, and OptJIT. Each JIT compiler has been designed to meet
specific goals with respect to performance and resource usage. The
performance characteristics are summarized in
1. Because of the low overhead of the EconoJIT compiler, as well as the ease with which it can be ported to new architectures, the .NET Framework does not include an interpreter for MSIL. (EconoJIT is so named because it performs the same task as the full JIT compiler, but using less computer resources. As a trade-off, the quality of the generated code is not so high). In some cases, tools vendors or researchers might want to design their own JIT compilers for use with the .NET Framework. Using the standard interface between the CLR and a JIT compiler, a third-party JIT compiler can
be "plugged in" to the CLR and interact appropriately. This interface (to be published in a future release) will consist of two parts: one used when MSIL is compiled to native code (the JIT/CLR interface) and the other when the compiled code is executed (the code manager). The code manager performs the stack walks required for memory management, exception handling, and security checks. It also performs other functions, such as converting the .NET Framework exceptions into the form expected by the source language processor's exception handlers. Vendors who design custom JIT compilers
can use the CLR's code manager or they can design a custom code manager to describe the layout of the method state for code they have compiled
1.5 Assembly
An assembly is a versionable unit of deployment of the .NET Framework. It is equivalent to Java's .jar, .war, and .ear file formats but is a lot more feature-rich. An assembly performs the following functions:
It contains code that the runtime executes. MSIL code in a
Portable eecutable (PE) file will not be executed if it does not
ve an associated assembly manifest. Note that each assembly n have nly one entry point.
It forms a security boundary. An assembly is the unit at which permissions are requested and granted. An assembly is to .NET security what a protection domain is to Java security.
It forms a type boundary. Every type's identity includes the name of the assembly in which it resides. A type MyType loaded in the scope of one assembly is not the same as a type MyType loaded in the scope of another assembly.
It forms a reference scope boundary. The assembly's manifest contains assembly metadata that is used for resolving types and satisfying resource requests. The manifest specifies the types and resources that are exposed outside the assembly. The manifest also enumerates other assemblies on which it depends.
It forms a version boundary. The assembly is the smallest versionable unit in the CLR; all types and resources in the same assembly are versioned as a unit. The assembly's manifest describes the version dependencies you specify for any dependent assemblies.
It forms a deployment unit. When an application starts, only the assemblies the application initially calls must be present. Other assemblies, such as localization resources or assemblies containing utility classes, can be retrieved on demand. In this way, applications can be kept simple and thin when first downloaded.
Assemblies can be static or dynamic. Static assemblies can include .NET Framework types (interfaces and classes) as well as resources for the assembly (bitmaps, JPEG files, resource files, and so on). Static assemblies are stored on disk in PE files. You can also use the .NET Framework to create dynamic assemblies, which are run directly from memory and are not saved to disk before execution.
You can save dynamic assemblies to disk after they have executed.
There are several ways to create assemblies. You can use development tools,such as Visual Studio .NET, that you have used in the past to create .dll or .exe files. You can use tools provided in the .NET Framework Software Development Kit (SDK) to create assemblies by referencing modules created in other development environments. You can also use CLR application programming interfaces (APIs) to create dynamic assemblies.
1.6 Application Domain
Application domains provide a secure and versatile unit of processing that the CLR can use to enable isolation between applications. You can run several application domains in a single process with the same level of isolation that would exist in separate processes, but without incurring the additional overhead of making cross-process calls or switching between processes. The ability to run multiple applications within a single process
increases server scalability dramatically. The isolation provided by
application domains has the following benefits:
Faults in one application cannot affect other applications. Because type-safe code cannot cause memory faults, using application domains ensures that code running in one domain cannot affect other applications in the process.
You can stop individual applications without stopping the entire process. Using application domains enables you to unload the code running in a single application.
Code running in one application cannot directly access code or resources in another application. The CLR enforces this isolation by preventing direct calls between objects in different application domains. Cross-domain calls use the same remote call infrastructure as calls between two processes or between two machines.
The behavior of code is scoped by the application in which it runs. In other words, the application domain provides configuration settings such as application version policies, the location of any remote assemblies it accesses, and information about where to locate assemblies that are loaded into the domain.
You can control permissions granted to code according to the application domain in which the code is running. Application domains help to isolate multiple applications running on a single process. Much like the modern-day Java 2 Enterprise Edition (J2EE) application servers, which use dynamic class loaders to isolate applications from one another, an application domain isolates applications in their own little world.
1.7 Runtime Host
The runtime host loads the runtime into a process, creates the application domains within the process, and loads user code into the application domains. The various runtime hosts are as follows:
ASP.NET loads the runtime into the process that is to handle the Web request. ASP.NET also creates an application domain for each Web application that will run on a Web server.
A shell executable invokes runtime hosting code to transfer control to the runtime each time an executable is launched from the shell.
Microsoft Internet Explorer creates application domains in which to run managed controls. The .NET Framework supports the downloading and execution of browser-based controls. The runtime interfaces with the extensibility mechanism of Microsoft Internet Explorer through a Multipurpose Internet Mail Extensions (MIME) filter to create application domains in which to run the managed controls. By default, one application domain is created for each Web site.
1.8 The Common Type System
As mentioned earlier, the CLR can provide infrastructure services to MSIL generated by any programming language (as long as the language can generate valid MSIL). Uniformity of data types becomes an issue when you're dealing with a standard for multiple languages. The Common Type System (CTS) is designed to streamline the types supported in the .NET world. The CTS defines how types are declared, used, and managed in the runtime, and it is also an important part of the runtime's support for cross-language integration. The CTS performs the following functions:
Establishes a framework that enables cross-language integration, type safety, and high-performance code execution.
Provides an object-oriented model that supports the complete
implementation of many programming languages.
Defines rules that languages must follow, something that helps to ensure that objects written in different languages can interact with one another.
A type can have several members:
Event: Defines an incident that can be responded to and defines methods for subscribing to, unsubscribing from, and firing the event. Events are often used to inform other types of state changes.
Field: Describes and contains the value of a type. Fields can be of any type supported by the runtime.
Nested type: Defines a type within the scope of the enclosing type.
Method: Describes operations available on the type. A method's signature specifies the allowable types of all its arguments and of its return value. A constructor is a special kind of method that initializes new instances of a type.
Property: Names a logical value or the state of the type and defines methods for getting or setting the property's value. Properties are often used to keep the public interface of a type independent from the type's actual representation. Type members have signatures and are inherited from their base type. Members such as methods can be overloaded and overridden.
1.8 Common Language Specification
The Common Language Specification (CLS) defines a set of rules for interoperability between components in different languages. Components written in other languages that adhere to this set of rules are said to be CLS-compliant and are accessible from other CLS-compliant languages.The CLS rules define a subset of the CTS; all the rules that apply to the Common Type System apply to the CLS, except where stricter rules are defined in the CLS. Most of the members defined by types in the .NET Framework are CLS-compliant. (These members are discussed later in this chapter.) Any language construct that would make it impossible to rapidly verify the type safety of code has been excluded from the CLS. As a result, all CLS-compliant languages can produce verifiable code.CLS compliance generally refers to the claim that CLS rules and restrictions are being followed. However, the concept has a more specific meaning, depending on whether you are describing CLS-compliant code or CLS-compliant development tools, such as a compiler. If you want your code to be CLS-compliant, you must expose functionality in a way that is CLS-compliant in the following places:
Definitions of your public classes
Definitions of the public members of public classes, and of members accessible to derived classes
Parameters and return types of public methods of public classes and of methods accessible to derived classes
The features you use in the definitions of your private classes, in the definitions of private methods on public classes, and in local variables do not have to follow the CLS rules. You can also use any language features you want in the code that implements your class and still have a CLS-compliant component. Code compliance is discussed in detail later, when we discuss the various code components, such as assemblies, methods,and types. For now, note that the C# language, which this book is about,has all the tools necessary to make your code CLS-compliant
