Features of CLR (Common Language Runtime)

Acronym of CLR is Common Language Runtime. It is heart of the .NET framework. It is the runtime that converts a MSIL code into the host machine language code, which is then executed appropriately. All Language have runtime and it is the responsibility of the runtime to take care of the code execution of the Program. For example, VB6 has MSVBVM60.DLL and Java has Java Virtual Machine etc. Similarly, .NET has CLR. Following are the responsibilities of CLR.

- Support for developer services (profiling, debugging)
In unmanaged code, when a program generates an exception, the kernel suspends the execution of the process and passes the exception information to the debugger by using the Win32 debugging API. The CLR debugging API provides the same functionality for managed code. When managed code generates an exception, the CLR debugging API suspends the execution of the process and passes the exception information to the debugger.

- Code Access Security(CAS)
The common language runtime (CLR) supports a security model called code access security for managed code. In this model, permissions are granted to assemblies based on the identity of the code.

A code group contains a permission set (one or more permissions). Code that performs a privileged action will perform a code access demand which will cause the common language runtime (CLR) to walk up the call stack and examine the permission set granted to the assembly of each method in the call stack. The code groups and permission sets are determined by the administrator of the machine who defines the security policy.

The security policy that determines the permissions granted to assemblies is defined in three different places:
1. Machine policy
2. User policy
3. Host policy

- Exception handling
You can handle following type of exceptions using /clr
1. Structured Exception Handling (SEH).
2. C++ exception handling.
3. CLR exceptions.

A CLR exception is any exception thrown by a managed type.
The System::Exception class provides many useful methods for processing CLR exceptions and is recommended as a base class for user-defined exception classes.

- Code management
The Microsoft .NET Framework has two main components.
1. Common Language Runtime (CLR)
2. .NET Framework class library.

The concept of code management is a fundamental principle of the CLR, and applications that the CLR manages are called "managed applications" or "managed code."

- Application memory isolation
Application Memory Isolation means that applications does not need to worry about allocation/de-allocation of memory, everything will be handled by the CLR. GC is the component in CLR which takes care of memory management.

- Access to metadata (enhanced type information)

- Managing memory for managed objects
One of the major productivity benefits that the common language runtime (CLR) offers developers of managed code are:
1. Garbage Collector (GC) makes sure any memory allocated on the managed heap is cleaned up after it is no longer needed.
2. It saved countless hours of developers while debugging difficult problems arising from memory leaks.
3. It also saves time in released memory, and double-freeing memory.

Garbage collection is a mechanism that allows the computer to detect when an object can no longer be accessed. It then automatically releases the memory used by that object (as well as calling a clean-up routine, called a "finalizer," which is written by the user). Some garbage collectors, like the one used by .NET, compact memory and therefore decrease your program's working set.

- Conversion of IL to native code.

- Interoperation between managed code, COM objects, and pre-existing DLL's (unmanaged code and data)

- Automation of object layout

- Verification of type safety
Type-safe code is code that accesses memory structures only in well-defined ways. For example, given a valid object reference, type-safe code can access memory at fixed offsets corresponding to actual field members. However, if the code accesses memory at arbitrary offsets inside or outside the range of memory that belongs to the object, then it is not type-safe. When assemblies are loaded in the CLR, prior to the MSIL being compiled using just-in-time (JIT) compilation, the runtime performs a verification phase that examines code to determine its type-safety. Code that successfully passes this verification is called verifiably type-safe code.

- Host Protection Attributes (HPAs)
The CLR provides a mechanism to annotate managed APIs that are part of the .NET Framework with certain attributes that may be of interest to a host of the CLR. Examples of such attributes include:

1. SharedState, which indicates whether the API exposes the ability to create or manage shared state (for example, static class fields).
2. Synchronization, which indicates whether the API exposes the ability to perform synchronization between threads.
3. ExternalProcessMgmt, which indicates whether the API exposes a way to control the host process.

Given these attributes, the host can specify a list of HPAs, such as the SharedState attribute, that should be disallowed in the hosted environment. In this case, the CLR denies attempts by user code to call APIs that are annotated by the HPAs in the prohibited list.