Architecture of CLR:

Common Type System (CTS)(Type Checker):In .Net framework 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 between the languages supported by the .net framework  visual basic, C#, J#, Visual C++. Microsoft thought it would be good to have it control the source code’s data as well. In Microsoft's .NET Framework, the Common Type System (CTS) is a standard that specifies how Type definitions and specific values of Types are represented in computer memory. This includes all numeric, string, and Boolean value types. It also defines the object, the core data storage unit in .NET. As used in programming languages, a Type can be described as a definition of a set of values and the allowable operations on those values. It is intended to allow programs written in different programming languages to easily share information Since the CLR is controlling our source code anyway.

The common type system divides all objects into two buckets.

Value types: stores actual data right in the bucket. If we have a 32-bit integer value, it gets put right in the value type bucket, ready for our immediate use. 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 (implemented by the runtime), user-defined, or enumerations.

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.

It seems like value types are easier to use, and they are, but they come with a few restrictions not imposed on reference types.

Programs and components written using the CTS standard can exchange data with one another without any hindrances or limitations. Suppose when we write our applications in Visual Basic, most of our code will appear in classes. Classes are reference types that include both data values and associated code.

The data values included in a class are most often the core CTS data types, but they can also contain objects that we design elsewhere in our application. Visual Basic also includes structures, the weaker yet quicker younger brother of classes. Structures implement value types, and also include both data and code.

Functions of the Common Type System

• To establish a framework that helps enable cross-language integration between the visual basic, c#, visual c++, j#, Jscript and many other language that support by .net framework
• To provide a framework that helps in type safety, and high performance code execution.
• To provide an object-oriented model that supports the complete implementation of many programming languages (visual basic, c#, visual c++, j#, Jscript etc).
• To define rules that languages must follow, which helps ensure that objects written in different languages like code written in Vb.net and code written in C#.net can interact with each other.
• The CTS also defines the rules that ensure that the data types of objects written in various languages like code written in Vb.net and code written in C#.net are able to interact with each other. Languages supported by .NET can implement all or some common data types
•  A few .NET data types fall outside the “core” CTS types, but we need to avoid them only when we want to specifically interact with components that can use only the core CTS types.

IL to Native Compiler:

       The compiled output of any MS.NET language (VB.NET, ASP.NET or C#) source code is PE (Portable Executable either in .exe file or .dll files) and it comprises of MSIL (Microsoft Intermediate Language) instructions and metadata in binary format.

The format of MSIL in PE is binary. The binary form of MSIL goes through the CLR (Common Language Runtime) and generates Native Code. This Native Code which is generated is what is actually executed.

• Metadata: Metadata contains some additional information regarding the compiled output.
• MSIL (Microsoft Intermediate Language) : MSIL is platform independent instruction set. It is generated by the compiler. The main advantage of using MSIL is it provides equal performance for multiple language programming, as code is compiled to native code i.e. performance-wise application developed in any of MS.NET language (VB.NET , C# ,etc)yields same performance results.

MSIL code is available in binary format in PE. To get MSIL code from binary format in text format, Microsoft gave a tool named ILDASM.exe. Also, to get back MSIL code in binary format from MSIL code in text format, Microsoft gave another tool called ILASM.exe.

 

For security purpose, it is not safe to get source code from MSIL Code in binary format, which is called Reverse Engineering. They are tools available in the market to avoid reverse engineering. One such tool is known as DOTNETFUSCATOR.

DOTNETFUSCATOR is a tool which does mangling in a PE file such that reverse engineering of it would not be possible. CLR understands it but no mangling can be done i.e.; source code cannot be obtained from MSIL code which is in binary format.

TYPES OF JIT COMPILERS:

             JIT Compiler (Just In Time) compiler is a part of CLR (Common Language Runtime). It is responsible for converting MSIL (binary format) to native code. It does this just before execution. If any earlier compiled code already which already exists, if needed, is used here.

               There are three types of JIT compilers:

Ø  Pre-JIT: Also known as NGEN.exe (Native Generator), given by Microsoft, which in one shot compiles complete MSIL code into native format (even before execution), so that even the first-time execution of code is unaffected in terms of performance. The compiled output is saved in GAC (Global Assembly Cash).

Ø  Econo-JIT: Econo-Jit compiles only those methods which are called at run-time and these methods are removed when they are not required. It is specially used in PDA’s; here Econo-JIT does not do caching.

Ø  Normal-JIT: It compiles methods which are called at run-time. These methods are called first time they are compiled and the results are stored in cache memory.

Garbage Collection:

The Garbage collector is .NET’s answer to memory management. This is a program whose purpose is to clean up memory. All the dynamically requested memory is allocated on the heap. This heap is managed by the CLR. When .NET detects that the managed heap for a given process is becoming full it calls the garbage collector. The garbage collector runs through variables currently in scope in your code, checks for the references to objects stored on the heap to see if they can be accessed from your code. Any objects that do not have any references in your code will be removed.

            Garbage Collection works in .NET because MSIL has been designed to facilitate the process. If any reference to an object exists then there is sufficient information in the reference to exactly determine the type of the object. Garbage collection is not deterministic which means you cannot guarantee when Garbage Collector will be called, it will be called when CLR decides that it is needed. We can also call explicitly GC through code.

Code Manager:

The common language runtime is an agent that manages code at execution time, providing core services such as memory management, thread management, and remoting, and also ensuring the type safety and security constraints. In fact, the concept of code management is a fundamental principle of the runtime. Code that targets the runtime is known as managed code, while code that does not target the runtime is known as unmanaged code.

In managed code execution process, a compiler is chosen that targets the runtime. During compilation the compiler translates the source code into MSIL (Microsoft Intermediate Language) and generates the required metadata. At the time of executing the code, the code is converted to the MSIL to CPU-specific code, by using a just-in-time (JIT) compiler. During this process, the code must pass a verification process to check whether the MSIL and metadata has performed any type safety in the code. For this CLR has to provide the JIT compilers and the supported architecture for it.

Class Loader:

Class Loader is a sub Component in CLR and is responsible for loading classes and other types as and when needed. It also loads the PE if it’s not already loaded.

COM Marshaler:

Marshaling is the act of transferring the data from the environment you are in to some other environment. In simple words Marshaling is nothing but transferring the data from the application domain you are working in to somewhere else.CLR contains a component called COM Marshaler that marshals the data types between application of different Languages.

E.g.: if a C++ application wants to interact with the .Net application then there should be certain mapping and conversions from C++ data type to .Net data type and vice versa .This is called Marshaling and it is done by COM Marshalling

Exception Support:

Exceptions are special cases that deviate from the normal behavior in a business process and need to be cared for exceptionally, normally by human intervention. Their cause might include: process deviation, malformed data, infrastructure or connectivity issues, poor quality business rules, etc. Exception Management is the practice of investigating, resolving and handling such occurrences by using skilled staff and software tools. Good exception management can contribute to efficiency of business processes.

Assemblies:

                 An assembly is the primary building block of a .NET Framework application. It is a collection of functionality that is built, versioned, and deployed as a single implementation unit.

There are two types of assemblies.

1. Process assemblies (EXE)

2. Library assemblies (DLL)

                 

                  A process assembly represents a process which will use classes defined in library assemblies. NET assemblies contain code in CIL, which is usually generated from a CLI language, and then compiled into machine language at runtime by the CLR just-in-time compiler.

The name of the assembly consist of four parts

1.     Short name. On Windows this is the name of the Portable Executable file without the extension.

2.     The culture.

3.     The version. This is a dotted number made up of 4 values — major, minor, build and revision.

4.     A public key token.

An assembly can consist of the following four elements:

1. Your code, compiled into MS intermediate language (MISL). This code file can be either an EXE file or a DLL file.
2. The assembly manifest, which is a collection of metadata that describes assembly name, culture settings, list of all files in the assembly, security identity, version requirements, and references to resources. The assembly manifest can be stored with the intermediate code, or in a standalone file that contains only assembly manifest information.
3. Type metadata.
4. Resources.

       The main and only required element of the above four elements is the assembly manifest. The remaining elements are optional depending on your requirements.

Benefits of assemblies in .net framework:

               Assemblies are mainly introduced to solve the problems of versioning, DLL conflicts, and simplifying the process of deployment.