Friday, September 26, 2008

.NET Framework Common Language Runtime

1. Common Language Runtime (CLR)

Common Language Runtime (CLR) is a run-time environment provided by the .NET Framework , which runs the code and provides services that make the development process easier. CLR is a rich set of features for cross-language development and deployment. CLR supports both Object Oriented Languages as well as procedural languages. CLR provides security, garbage collection, cross language exception handling, cross language inheritance and so on.

1. Garbage Collection (GC) : CLR automatically manages memory in .NET framework. When objects are no longer in use Garbage Collection (GC) automatically releases those memories, which provides efficient memory management.
2. Code Access Security (CAS) : CAS determines whether a piece of code is allowed to run or not and what are the resources that it can use while running. CAS grants rights to program based upon security configuration of machine.
3. Code Verification : This ensures proper code execution and type safety while the code runs. It prevents the source code to perform illegal operation such as accessing invalid memory locations etc.
4. Microsoft Intermediate Language (MSIL) : CLR uses JIT compiler to compile the Intermediate Language code to machine code and then executes. CLR also determines depending on platform what is optimized way of running the IL code.

2. Microsoft Intermediate Language (MSIL)

Microsoft Intermediate Language is a platform independent language that gets compiled into platform dependent executable file or Dynamic Link Library. It is a CPU-independent set of instructions that can be efficiently converted to native code. MSIL includes instructions for loading, storing, initializing, and calling methods on objects, as well as instructions for arithmetic and logical operations, control flow, direct memory access, exception handling, and other operations. Before code can be run, MSIL must be converted to CPU-specific code, by a just-in-time (JIT) compiler. It means .NET compiler can generate code written using any of the CLR languages and finally convert it to the required machine code(native code) depending on the target machine.
3. Just-in-time (JIT) Compiler
A Just-In-Time (JIT) compiler is used to translate the MSIL code into native code during execution time. Before you can run MSIL, it must be converted by a .NET Framework just-in-time (JIT) compiler to native code, which is CPU-specific code that runs on the same computer architecture as the JIT compiler. Because the common language runtime supplies a JIT compiler for each supported CPU architecture, developers can write a set of MSIL that can be JIT-compiled and run on computers with different architectures.
Each method for which MSIL has been generated is JIT-compiled when it is called for the first time, and then run. The next time the method is run, the existing JIT-compiled native code is run.
JIT compilation takes into account the fact that some code might never get called during execution. Rather than using time and memory to convert all the MSIL in a portable executable (PE) file to native code, it converts the MSIL as needed during execution and stores the resulting native code so that it is
accessible for subsequent calls.

As part of compiling MSIL to native code, code must pass a verification process, that examines MSIL and metadata to find out whether the code is type safe.
4. Metadata
When a compiler produces MSIL, it also produces metadata. Metadata describes the types in your code, including the definition of each type, the signatures of each type's members, the members that your code references, and other data that the runtime uses at execution time. The MSIL and metadata are contained in a portable executable (PE) file. The presence of metadata in the file along with the MSIL enables your code to describe itself. The runtime locates and extracts the metadata from the file as needed during execution. Every type and member defined and referenced in a module or assembly is described within metadata. When code is executed, the runtime loads metadata into memory and references it to discover information about code's classes, members, inheritance, and so on.
Metadata provides the following major benefits :
Self-describing files : Common language runtime modules and assemblies are self-describing. A module's metadata contains everything needed to interact with another module. Runtime modules and assemblies do not even require registration with the operating system.
Language interoperability and easier component-based design : Metadata provides all the information required about compiled code for you to inherit a class from a PE file written in a different language. You can create an instance of any class written in any managed language.
Attributes : The .NET Framework allows you to declare specific kinds of metadata, called attributes, in your compiled file. Attributes can be found throughout the .NET Framework and are used to control in more detail how your program behaves at run time.
5. Managed code
Managed code is code that has its execution managed by the runtime. Code that you develop with a language compiler that targets the runtime is called managed code. During execution, managed code receives services such as garbage collection, security, interoperability with unmanaged code, cross-language debugging support, and enhanced deployment and versioning support. Managed code provides information (i.e., metadata) to allow the CLR to locate methods encoded in assembly modules, store and retrieve security information, handle exceptions, and walk the program stack.
Managed code can access both managed data and unmanaged data. Managed data can only be accessed by managed code. CLR automatically handles object layout and manages references to objects, releasing them when they are no longer being used. Objects whose lifetimes are managed in this way are called managed data. Using Garbage collection, CLR allocate and release memory and eliminates some other common programming errors.
6. Unmanaged Code
Code that runs outside the runtime is called unmanaged code. Code that is created without regard for the conventions and requirements of the common language runtime. Unmanaged code executes in the common language runtime environment with minimal services (for example, no garbage collection, limited debugging, and so on). COM components, ActiveX interfaces, and Win32 API functions are examples of unmanaged code.
7. Native code
Native code is computer programming code that is compiled to run with a particular processor and its set of instructions. If the same program is run on a computer with a different processor, software can be provided so that the computer emulates the original processor. In this case, the original program runs in "emulation mode" on the new processor and almost certainly more slowly than in native mode on the original processor. Native code, which is CPU-specific code that runs on the same computer architecture as the JIT compiler. Microsoft's .NET compilers for its Visual Basic, C#, and JavaScript languages produce MSIL that can be compiled into native code before execution by a just-in-time compiler for faster performance.
8. Common Type System (CTS)
The common type system defines how types are declared, used, and managed in the runtime, and is also an important part of the runtime's support for cross-language integration. CTS is a standard that specifies how Type definitions and specific values of Types are represented in computer memory. CTS describes how types are defined and how they behave in .NET Framework. The common type system performs the following functions:
  • To establishe a framework that helps enable cross-language integration, type safety, and high performance code execution.
  • To provide an object-oriented model that supports the complete implementation of many programming languages.
  • To define rules that languages must follow, which helps ensure that objects written in different languages can interact with each other.
The common type system supports two general categories of types:
Value types : Value types directly contain their data, and instances of value types are either
allocated on the stack or allocated inline in a structure. Value types can be built-in, user-defined, or enumerations.
Assigning one value type variable to another copies the contained value. It is not possible to derive a new type from a value type. It is not possible for a value type to contain the null value.Each value type has an implicit default constructor that initializes the default value of that type.
Reference types : Reference types store a reference to the value's memory address, and are
allocated on the heap. Reference types can be self-describing types, pointer types, or interface types. The type of a reference type can be determined from values of self-describing types. Self-describing types are further split into arrays and class types. The class types are user-defined classes, boxed value types, and delegates.
Assignment of reference type variables, copies a reference to the object but not the object itself.
Variables that are value types each have their own copy of the data, and therefore operations on one variable do not affect other variables. Variables that are reference types can refer to the same object; therefore, operations on one variable can affect the same object referred to by another variable.
9. Common Language Specification
The Common Language Specification (CLS) is a basic set of language features common to many programming languages and defines rules for how those features are used. It defines the mininum requirements of types that must be supported by any .NET language.
To fully interact with other objects regardless of the language they were implemented in, objects must expose to callers only those features that are common to all the languages they must interoperate with. For this reason, the Common Language Specification (CLS), has been defined. The Common Type System defines a set of rules compilers must follow for types so that objects of types written in different languages can interact. The CLS rules define a subset of the common type system.
The CLS helps enhance and ensure language interoperability. Language interoperability is the ability of code to interact with code that is written using a different programming language. The common language runtime provides the necessary foundation for language interoperability by specifying and enforcing a common type system and by providing metadata. The CLS also establishes requirements for CLS compliance. Components that adhere to the CLS rules and use only the features included in the CLS are said to be CLS-compliant components.
The common language runtime provides built-in support for language interoperability. However, this support does not guarantee that code you write can be used by developers using another programming language. To ensure that you can develop managed code that can be fully used by developers using any programming language, a set of language features and rules for using them, called the Common Language Specification (CLS), has been defined. Components that follow these rules and expose only CLS features are considered CLS-compliant.
10. Type safety
Type-safe code accesses only the memory locations it is authorized to access. For example, type-safe code cannot read values from another object's private fields. Type-safe code is code that accesses types only in well-defined, allowable ways.
JIT compilation performs an optional verification process that examines metadata and MSIL to determine whether the code is type-safe. Code that is proven during verification to be type-safe is called verifiably type-safe code. This process is skipped if the code has permission to bypass verification.
Type safety plays a crucial role in assembly isolation and security enforcement. When code is type safe, the common language runtime can completely isolate assemblies from each other. This isolation helps ensure that assemblies cannot adversely affect each other and it increases application reliability.

No comments: