CLR is the most important component of our .NET Framework. The CLR itself works to manage and execute the code written in a programming language supported by the .NET Framework, and the CLR is the basis of the .NET Architecture, just like the JVM of Java. The CLR itself activates various objects, performs security checks on them, loads them into memory, executes them, and unloads them from memory through Garbage Collector.
CLR Environment
The CLR is the basis of the .NET Infrastructure, which meets the various requirements related to executing a .NET application. The CLR manages the execution of any .NET Framework Application. We can represent CLR by the following figure:
As we can see in this picture, there are various .NET PE Files on the layer above the Common Language Runtime, which represents .NET Assemblies or Deployment Units of Applications developed in various .NET Supported Programming Languages.
The CLR is a Runtime Engine, which loads the classes required to execute a .NET Application Program, performs Just-In-Time Compilation for the methods required, Enforces Security Checks, And Accomplishes Other Runtime Functionalities.
CLR Executables
Microsoft .NET Executables are a bit different than other Windows Executables because they are not directly converted to Native Code but actually converted to Intermediate Byte Code, which contains Executable Codes as well as other Data and Metadata, which are CLR Instruction about how to execute the .EXE or .DLL file generated by compiling .NET application by .NET Programming Languages.
.NET Portable Executable (PE) File
.EXE or .DLL Windows Executable Files are created on the basis of a specific file format specification, which is called PE File Format. The Windows Operating System knows how to load and execute this file format. Therefore, for any compiler, who wants to generate Windows Executables, it is necessary to follow the PE / COFF specification.
Standard Windows PE Files are basically divided into two parts. The first section contains PE / COFF Headers, which refer to the content of the PE file. Whereas the Header Section, as the second section, also holds the information of .data, .rdata, .rsrc, and .text sections along with the information of various images used in the current application.
Both of these sections are standard sections of any Windows executable, but Microsoft’s C/C++ compilers also allow us to specify our own headers in a PE file using pragma statements. In this way, we can better represent the CLR Header and CLR Data Sections added by Microsoft in a Normal PE Format as in the following picture:
Where the CLR Header stores the information that indicates that the PE file is a .NET Executable file while the CLR Data section contains the METADATA and IL codes, both of which determine whether the current application is How will the program be executed?
.NET Assemblies
The code of all the .NET applications developed on the basis of the .NET Framework is executed by CLR, which is the runtime of .NET Platform. But to execute any code on the CLR, this code is translated into such a format that the CLR runtime can understand, and this format is called CIL or Common Intermediate Language.
In other words, it is also called MSIL or simply IL. Whereas the codes that run on the CLR are called Managed Codes because these codes are not Native Codes that can be directly executed on the Microprocessor of the Current Machine, but they require additional Runtime Infrastructure to be executed.
In addition to IL instructions, the CLR also requires some metadata to execute an application, which describes the organization and structure of the types or classes used in that application.
Because of using METADATA, we do not need to include Header Files in our programs because the CLR gets the type of information needed for the execution of the Current Application Program from METADATA.
Assemblies are only a single file; it is not necessary. Rather, the .NET Framework can also contain multiple assemblies, which are composed as a single module. In other words, for .NET Application Deployment, not the assembly but the Module is important, even if there is only one assembly in that Module.
The important thing is also that we cannot create Modules using Visual Studio; rather, we need to use Command Line Tools of .NET to create Modules.
Compiling programs made in Static Programming Languages like .NET Framework Supported VisualBasic.NET and C#, they get compiled as .EXE or .DLL Assemblies, which are all MSIL or IL and METADATA containers.
.NET Supported Dynamic Programming Languages behave in a slightly different way because Dynamic Programming Languages are generally Scripting Languages, which are not compiled but are directly loaded as a separate assembly in uncompiled runtime.
To handle many types of multiple dynamic languages at runtime, a common format is needed, which represents the codes of this type of scripting language and translates into CIL instruction during the execution of the program. We can better understand this process by the following picture.