Common Language Runtime in c#
What is Common Language Runtime (CLR)
The name of the environment is Common Language Runtime, CLR) – speaks for itself: it is an execution environment that is suitable for different programming languages. Key features of Common Language Runtime (memory management, Assembly downloads, security, exception processing, synchronization) are available in any programming languages that use this medium. For example, The work of errors, the execution environment relies on exceptions, which means that in all programming languages that use this execution environment, errors are transmitted through the exclusion mechanism. Or, for example, the environment execution allows you to create software streams, which means that in all programming languages that uses this environment can also be streamed.
In fact, during the program, it is not known in which programming language the CLR environment developer wrote the source code. Which means that you can choose any programming language that makes it easier solve a specific problem. Software can be developed in any programming language, if only the compiler used by this language supports Common Language Runtime.
So what is the advantage of one programming language over another? I see compilers as a means of controlling syntax and analysis “correct code.” Compilers check the source code, make sure that all written has some meaning, and then generate a code describing the solution task. Different programming languages allow you to develop software using different syntax. Don’t underestimate the importance of choosing the syntax of a programming language. For example, for math or financial applications expression of a programmer’s thoughts in the language APL can save many days of work compared to the application in this given Perl language situation.
Microsoft has developed compilers for the following programming languages used on this platform: C++ / CLI, C# (pronounced “c sharp”), Visual Basic, F# (pronounced “ef sharp”), Iron Python, Iron Ruby, and assembly language Intermediate Language (IL). In addition to Microsoft, several other companies and universities have created compilers designed for the CLR runtime. I know compilers for Ada, APL, Caml, COBOL, Eiffel, Forth, Fortran, Haskell, Lexico, LISP, LOGO, Lua, Mercury, ML, Mondrian, Oberon, Pascal, Perl, Php, Prolog, RPG, Scheme, Smalltalk, and Tcl/Tk.
Figure1 illustrates the process of compiling files with source code. As seen from the picture, the source code of the program can be written in any language, Common Language Runtime. The appropriate compiler is then checks the syntax and analyzes the source code of the program. Regardless of the type of compiler used will result from the compilation the “managed module” is a standard portable executable, PE) 32-bit (PE32) or 64-bit Windows (PE32) file, that requires Common Language Runtime to perform. By the way, managed builds are always take advantage of the security feature “preventing the execution of (DEP, Data Execution Prevention) and ASLR (Address Space) technology Layout Optimization), the use of these technologies enhances the information security of the entire system.
Machine code compilers produce code that targets a specific processor architecture, such as x86, x64, or ARM. In contrast, all CLR-compatible compilers generate IL code. IL code is sometimes called managed code because the Common Language Runtime controls its execution.
Part | Description |
PE32 header or PE32+ | A standard Windows PE header file, similar to the Common Object File Format (COFF) header. A file with a header in PE32 format can be executed in 32- and 64-bit versions of Windows, but with the PE32 + header – only in 64-bit. The header denotes the type of file: GUI, CUI or DLL, it also has a timestamp showing when the file was assembled. For modules containing only IL code, most of the information in the PE32 (+) header is ignored. In modules containing native code, this header contains information about the native code |
CLR header | Contains information (interpreted by the CLR and utilities) that makes this module manageable. The header includes the desired CLR version, some flags, a label Metadata MethodDef entry point into a managed module (Main method) as well as the location / size of the metadata module, resources, strong name, some flags, etc. |
Metadata | Each managed module contains metadata tables. There are two main types of tables – tables that describe data types and their members, defined in the source code, and so blitz describing data types and their members, for which there are links in the source code |
Intermediate code Language (IL) | Code generated by the compiler when compiling source code. The CLR then compiles the IL to machine commands |
Each compiler designed for CLR(Common Language Runtime), in addition to generating an IL code, should also create full metadata (metadata) for each managed Module. Simply put, metadata is a set of data tables that describe what what is defined in the module, such as the types and their members. There is also a tables indicating what the managed module refers to, such as portable types and their members. Metadata expands the possibilities of such old technologies like com and IDL (Interface Definition Language) libraries, interface description language). It is important to note that CLR(Common Language Runtime) metadata much more complete information. And unlike type and IDL libraries, they are always linked to a file that contains AN code. In fact, metadata is always built into the same EXE or DLL file as the code, so they can’t be separated. And because the compiler generates metadata and code at the same time and binds them to the final controlled module, the possibility of metadata out-of-sync and the IL they describe is excluded.
Metadata finds many uses. Let’s list just a few of them:
- Metadata eliminates the need for headline and library files compilation, as all information about the types/members mentioned is contained in a file with an IL that implements them. Compilers can read metadata straight from the controlled modules.
- Microsoft Visual Studio’s environment uses metadata to facilitate writing code. Its IntelliSense feature analyzes metadata and tells which methods, properties, events and fields are preferable in this case and what parameters are required by specific methods.
- In the code verification process, CLR(Common Language Runtime) uses metadata to make sure that the code only performs “type-safe” operations.
- Metadata allows you to serialize the fields of an object, and then transfer this data over the network to a remote computer and there to carry out the deserialization process, by restoring the object and its state on the remote computer.
- Metadata allows the garbage collector to track the life cycle of objects. The garbage collector can use metadata to determine the type of objects and find out exactly which fields in them refer to other objects.
modules that contain managed code (IL) and managed data (data that hold the garbage collection). To run any controllable module on the the end-user machine should be installed in the CLR(Common Language Runtime) environment (as part of the .NET Framework) – the same as for running MFC or Visual applications Basic 6.0 must be installed Microsoft Foundation Class Library (MFC) or visual basic DLL library.
By default, the Microsoft C ++ compiler generates EXE and DLL files that contain unmanaged code and unmanaged data. To execute them CLR(Common Language Runtime) not required. However, if you call the C ++ compiler with the / clr option in the command line, it will create managed modules (and of course, for these modules to work the CLR must be installed). The C ++ compiler stands alone among of all the compilers mentioned by Microsoft – only it allows developers write both managed and unmanaged code and embed it into a single module. It is also the only Microsoft compiler to allow programmers to define both managed and unmanaged in source code data types. The Microsoft Compiler provides the developer with unmatched flexibility by allowing existing unmanaged C /C ++ from managed code and gradually migrate to managed types.
How CLR(Common Language Runtime) manages field placement for type:
To improve performance, Common Language Runtime is given the right to set the order placing type fields. For example, Common Language Runtime can build fields in a way that links to objects will end up in the same group, and data and property fields will be even and packaged – in another. However, when describing the type, you can specify whether to maintain the order of this type of field, defined by the programmer, or allow CLR(Common Language Runtime) to do this work.
To tell the Common Language Runtime how to manage fields, specify in the description class or structure attribute System.Runtime.InteropServices.StructLayoutAttribute. For the order of the fields to be set by the CLR, you need to pass the LayoutKind.Auto parameter to the attribute constructor; to preserve the order set by the programmer, the LayoutKind.Sequential parameter, and the LayoutKind parameter. Explicit allows you to place fields in memory by explicitly specifying offsets. If the StructLayoutAttribute is not applied in the type description, the field order will be compiler.
For reference types (classes), the C# compiler chooses the LayoutKind option. Auto, and for value types (structures) – LayoutKind.Sequential. Obviously, compiler designers think that structs are usually used to interact with unmanaged code, which means that the fields should be arranged as defined by the developer. However, when creating a value type that doesn’t work in conjunction with unmanaged code, it is likely that the default compiler behavior will need to be changed, for example:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
using System; using System.Runtime.InteropServices; // Enable CLR to improve performance // set field order for this type [StructLayout (LayoutKind.Auto)] internal struct SomeValType { private readonly Byte m_b; private readonly Int16 m_x; ... } |
The StructLayoutAttribute also allows you to explicitly set the offset for all fields by passing to the LayoutKind.Explicit constructor. Then you can apply System.Runtime.InteropServices.FieldOffsetAttribute to all fields by passing the constructor of this attribute an Int32 value that defines the offset (in bytes) of the first byte of the field from the start of the instance. Explicit placement commonly used to simulate what is in unmanaged C / C ++ code was called union, that is, placing several fields from one offsets in memory, for example:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
using System; using System.Runtime.InteropServices; // The developer explicitly sets the order of the fields in the value type [StructLayout (LayoutKind.Explicit)] internal struct SomeValType { [FieldOffset (0)] private readonly Byte m_b; // Fields m_b and m_x overlap [FieldOffset (0)] private readonly Int16 m_x; // in instances of this class } |
A type definition in which reference and value overlap is not allowed. my types. It is possible to define a type in which several significant ones overlap types, however all overlapping bytes must be accessible through public fields to provide type verification.