Обзор среды CLR

.NET предоставляет среду выполнения, называемую средой CLR, которая выполняет код и предоставляет службы, упрощающие процесс разработки.

Компиляторы и средства предоставляют функциональные возможности среды CLR и позволяют писать код, который использует управляемую среду выполнения. Код, разработанный с использованием языкового компилятора для среды выполнения, называют управляемым. В нем используются преимущества таких средств, как объединение языков программирования, объединенная обработка исключений, усиленная безопасность, поддержка отслеживания версий и развертывания, упрощенная модель взаимодействия компонентов, а также службы отладки и профилирования.

Компиляторы и средства могут создавать выходные данные, которые может использовать среда CLR, так как система типов, формат метаданных и среда времени выполнения (виртуальная система выполнения) определяются общедоступным стандартом, спецификацией ОБЩЕЯзыковой инфраструктуры ECMA. Дополнительные сведения см. в разделе Спецификации ECMA для C# и инфраструктуры Common Language Infrastructure (CLI).

Чтобы включить в среде выполнения предоставление служб управляемому коду, языковые компиляторы должны предоставлять метаданные с описанием типов, членов и ссылок в коде. Метаданные хранятся вместе с кодом. Они содержатся в каждом загружаемом переносимом исполняемом (PE) файле среды CLR. Метаданные в среде выполнения используются для поиска и загрузки классов, размещения экземпляров в памяти, разрешения имен при вызове методов, создания машинного кода, обеспечения безопасности и установки границ контекста времени выполнения.

Среда выполнения автоматически обрабатывает макет объектов и управляет ссылками на объекты, освобождая их, когда они больше не используются. Объекты, время жизни которых управляется подобным образом, называются управляемыми данными. Сборка мусора устраняет утечки памяти и некоторые другие распространенные ошибки программирования. Если ваш код является управляемым, в приложении .NET можно использовать управляемые, неуправляемые или как управляемые, так и неуправляемые данные. Поскольку компиляторы языка предоставляют собственные типы, такие как примитивные типы, возможно, вам не всегда нужно знать, управляются ли ваши данные.

Среда CLR упрощает разработку компонентов и приложений, объекты которых могут работать в разных языках. Объекты, написанные на разных языках, могут взаимодействовать друг с другом, а их поведение может быть тесно интегрировано. Например, разработчик может определить класс, а затем на другом языке создать производный от него класс или вызвать метод из исходного класса. Можно также передать экземпляр класса в метод класса, написанного на другом языке. Такая межязыковая интеграция возможна, так как языковые компиляторы и средства, предназначенные для среды выполнения, используют систему общих типов, определенную средой выполнения. Они следуют правилам среды выполнения для определения новых типов, а также для создания, использования, сохранения и привязки к типам.

В составе своих метаданных все управляемые компоненты содержат сведения о компонентах и ресурсах, на базе которых они построены. Среда выполнения использует эти сведения, чтобы обеспечить наличие всех необходимых ресурсов для компонента или приложения. Это снижает вероятность сбоев кода из-за каких-либо неудовлетворенных зависимостей. Сведения о регистрации и данные о состоянии больше не хранятся в реестре, где их может быть трудно установить и поддерживать. Вместо этого сведения об определяемых типах и их зависимостях хранятся в коде в виде метаданных. Таким образом, задача репликации и удаления компонентов будет менее сложной.

Языковые компиляторы и программы предоставляют функции среды выполнения так, чтобы они были полезны и интуитивно понятны для разработчиков. Некоторые функции среды выполнения могут быть более заметными в одной среде, чем в другой. Характеристики среды выполнения зависят от используемых языковых компиляторов и программ. Например, если вы разработчик Visual Basic, вы можете заметить, что в среде CLR язык Visual Basic имеет больше объектно-ориентированных функций, чем раньше. Среда выполнения предоставляет следующие преимущества:

• повышение производительности;
• возможность легко использовать компоненты, разработанные на других языках;
• расширяемые типы, предоставляемые библиотекой классов;
• языковые возможности (например, наследование, интерфейсы и перегрузку) для объектно-ориентированного программирования;
• Поддержка явного свободного потока, которая позволяет создавать многопоточные и масштабируемые приложения.
• поддержку структурированной обработки исключений;
• поддержку настраиваемых атрибутов;
• сборка мусора;
• использование делегатов вместо указателей на функции для повышения типобезопасности и уровня защиты. Подробнее о делегатах см. в разделе Система общих типов CTS.

Версии CLR

Выпуски .NET Core и .NET 5+ имеют одну версию продукта, то есть не существует отдельной версии среды CLR. Список версий .NET Core см. в разделе Загрузка .NET Core.

Однако номер версии платформы .NET Framework не всегда соответствует номеру версии среды CLR, которую он содержит. Список версий .NET Framework и соответствующих версий среды CLR см. в разделе Версии и зависимости платформы .NET Framework.

Связанные статьи

Заголовок	Описание
Процесс управляемого выполнения	Описание шагов, необходимых для использования преимуществ общеязыковой среды выполнения.
Автоматическое управление памятью	Описание выделения и освобождения памяти сборщиком мусора.
Общие сведения о платформе .NET	Описание ключевых понятий платформы .NET Framework: системы общих типов CTS, межъязыкового взаимодействия, управляемого выполнения, доменов приложений и сборок.
Система общих типов CTS	Описание того, как типы объявляются, используются и контролируются в среде выполнения в рамках поддержки межъязыковой интеграции.

Общеязыковая исполняющая среда CLR

Существует ряд средств, которые поддерживаются .NET, но не поддерживаются C#, и, возможно, вас удивит, что есть также средства, поддерживаемые C# и не поддерживаемые .NET (например, некоторые случаи перегрузки операций). Однако поскольку язык C# предназначен для применения на платформе .NET, вам, как разработчику, важно иметь представление о .NET Framework, если вы хотите эффективно разрабатывать приложения на C#. Поэтому давайте заглянем “за кулисы” .NET.

Центральной частью каркаса .NET является его общеязыковая исполняющая среда, известная как Common Language Runtime (CLR) или .NET runtime. Код, выполняемый под управлением CLR, часто называют управляемым кодом. С точки зрения программирования под термином может пониматься коллекция внешних служб, которые требуются для выполнения скомпилированной единицы программного кода. Например, при использовании платформы MFC для создания нового приложения разработчики осознают, что их программе требуется библиотека времени выполнения MFC (т.е. mfc42.dll). Другие популярные языки тоже имеют свою исполняющую среду: программисты, использующие язык VB6, к примеру, вынуждены привязываться к одному или двум модулям исполняющей среды (вроде msvbvm60.dll), а разработчики на Java — к виртуальной машине Java (JVM).

В составе .NET предлагается еще одна исполняющая среда. Главное отличие между исполняющей средой .NET и упомянутыми выше средами, состоит в том, что исполняющая среда .NET обеспечивает единый четко определенный уровень выполнения, который способны использовать все совместимые с .NET языки и платформы.

Однако перед тем как код сможет выполняться CLR, любой исходный текст (на C# или другом языке) должен быть скомпилирован. Компиляция в .NET состоит из двух шагов:

1. Компиляция исходного кода в Microsoft Intermediate Language (IL)

2. Компиляция IL в специфичный для платформы код с помощью CLR

Этот двухшаговый процесс компиляции очень важен, потому что наличие Microsoft Intermediate Language (IL) является ключом ко многим преимуществам .NET. Microsoft Intermediate Language (промежуточный язык Microsoft) разделяет с байт-кодом Java идею низкоуровневого языка с простым синтаксисом (основанным на числовых, а не текстовых кодах), который может быть очень быстро транслирован в родной машинный код.

Основной механизм CLR физически имеет вид библиотеки под названием mscoree.dll (и также называется общим механизмом выполнения исполняемого кода объектов — Common Object Runtime Execution Engine). При добавлении ссылки на сборку для ее использования загрузка библиотеки mscoree.dll осуществляется автоматически и затем, в свою очередь, приводит к загрузке требуемой сборки в память. Механизм исполняющей среды отвечает за выполнение целого ряда задач. Сначала, что наиболее важно, он отвечает за определение места расположения сборки и обнаружение запрашиваемого типа в двоичном файле за счет считывания содержащихся там метаданных. Затем он размещает тип в памяти, преобразует CIL-код в соответствующие платформе инструкции, производит любые необходимые проверки на предмет безопасности и после этого, наконец, непосредственно выполняет сам запрашиваемый программный код.

Помимо загрузки пользовательских сборок и создания пользовательских типов, механизм CLR при необходимости будет взаимодействовать и с типами, содержащимися в библиотеках базовых классов .NET. Хотя вся библиотека базовых классов поделена на ряд отдельных сборок, главной среди них является сборка mscorlib.dll. В этой сборке содержится большое количество базовых типов, охватывающих широкий спектр типичных задач программирования, а также базовых типов данных, применяемых во всех языках .NET. При построении .NET-решений доступ к этой конкретной сборке будет предоставляться автоматически.

На данной схеме наглядно видно, как выглядят взаимоотношения между исходным кодом (предусматривающим использование типов из библиотеки базовых классов), компилятором .NET и механизмом выполнения .NET.

Использование байт-кода с четко определенным универсальным синтаксисом дает ряд существенных преимуществ:

Независимость от платформы

Первым делом, это значит, что файл, содержащий инструкции байт-кода, может быть размещен на любой платформе; во время выполнения может быть легко проведена финальная стадия компиляции, что позволит выполнить код на конкретной платформе. Другими словами, компилируя в IL, вы получаете платформенную независимость .NET — во многом так же, как компиляция в байт-код Java обеспечивает независимость от платформы программам на Java.

Следует отметить, что независимость .NET от платформы в настоящее время является лишь теоретической, поскольку реализация .NET доступна только для ОС Windows. Однако уже существуют частичные реализации для других платформ (например, проект Mono — попытка создать реализацию .NET с открытым кодом).

Повышение производительности

Хотя язык IL выше сравнивался с Java, все же IL на самом деле более гибкий, чем байт-код Java. Код IL всегда компилируется оперативно (Just-In-Time, JIT-компиляция), в то время как байт-код Java часто интерпретируется. Одним из недостатков Java было то, что во время выполнения программ процесс трансляции байт-кода Java в родной машинный код приводил к снижению производительности (за исключением самых последних версий, где Java компилируется оперативно (JIT) на некоторых платформах).

Вместо компиляции всего приложения за один проход (что может привести к задержкам при запуске), JIT-компилятор просто компилирует каждую порцию кода при ее вызове (т.е. оперативно). Если промежуточный код однажды скомпилирован, то результирующий машинный исполняемый код сохраняется до момента завершения работы приложения, поэтому его перекомпиляция при повторных обращениях к нему не требуется. В Microsoft аргументируют, что такой процесс более эффективен, чем компиляция всего приложения при запуске, поскольку высока вероятность того, что крупные фрагменты кода приложения на самом деле не будут выполняться при каждом запуске. При использовании JIT-компилятора такой код никогда не будет скомпилирован.

Это объясняет, почему можно рассчитывать на то, что выполнение управляемого кода IL будет почти настолько же быстрым, как и выполнение родного машинного кода. Однако это не объясняет того, почему Microsoft ожидает повышения производительности. Причина состоит в том, что поскольку финальная стадия компиляции происходит во время выполнения, JIT-компилятор на этот момент уже знает, на каком типе процессора будет запущена программа. А это значит, что он может оптимизировать финальный исполняемый код, используя инструкции конкретного машинного кода, предназначенные для конкретного процессора.

Традиционные компиляторы оптимизируют код, но они могут проводить лишь оптимизацию, не зависящую от конкретного процессора, на котором код будет выполняться. Это происходит потому, что традиционные компиляторы генерируют исполняемый код до того, как он поставляется пользователям. А потому компилятору не известно, на каком типе процессора они будут работать, за исключением самых общих характеристик вроде того, что это будет х86-совместимый процессор либо же процессор Alpha.

COM и COM+

Формально СОМ и СОМ+ не являются технологиями, нацеленными на .NET, поскольку компоненты, основанные на них, не могут компилироваться в IL (хотя в определенной степени это и можно сделать, применяя управляемый С++, если исходный компонент СОМ+ был написан на С++). Однако СОМ+ остается важным инструментом, потому что его средства не дублируют .NET. К тому же компоненты СОМ будут по-прежнему работать, и .NET включает средства взаимодействия с СОМ, позволяющие управляемому коду вызывать компоненты СОМ и наоборот. Тем не менее, скорее всего, вы обнаружите, что в большинстве случаев удобнее кодировать новые компоненты в виде компонентов .NET, чтобы воспользоваться преимуществами базовых классов .NET, а также другими выгодами от запуска управляемого кода.

Common Language Runtime(CLR) DotNet

The term “runtime” can be understood as a collection of services that are required to execute a given compiled unit of code and .NET runtime provides a single ,well defined runtime layer that is shared

Programmers needed to perform a lot of the low-level work (plumbing) like custom security systems, implement error handling,thread handling , application hosting and manage memory.

CLR offer feature-rich set of plumbing services but the primary role is to locate,load and manage .NET objects on your behalf

Features

.NET Framework Class Library support:Contains built-in types and libraries to manage assemblies, memory, security, threading, and other runtime system support

Debugging: Facilities for making it easier to debug code.

Exception management:Allows you to write code to create and handle exceptions.

Execution management:Manages the execution of code

Garbage collection:Automatic memory management and garbage collection

InteropServices: The CLR can interoperate with various kinds of unmanaged code, such as Visual Basic, Visual C++, DLLs, or COM components. Interop allows your managed code to call these unmanaged components.Backward-compatibility with COM and Win32 code.

Just-In-Time (JIT) compilation: An efficiency feature for ensuring that the CLR only compiles code just before it executes

Security:Traditional role-based security support, in addition to Code Access Security (CAS).

Thread management:Allows you to run multiple threads of execution

Type loading: Finds and loads assemblies and types

Type safety: Ensures references match compatible types, which is very useful for reliable and secure code.

How CLR Locate,Load and Manage:

Windows (the OS) will be running at Start; the CLR won’t begin execution until Windows starts it. When an application executes, OS inspects the file to see whether it has a special header to indicate that it is a .NET application. If not, Windows continues to run the application.If an application is for .NET, Windows starts up the CLR and passes the application to the CLR for execution. The CLR loads the executable assembly, finds the entry point, and begins its execution process.

The executable assembly could reference other assemblies, such as dynamic link libraries (DLLs), so the CLR will load those. However, this is on an as-needed basis. An assembly won’t be loaded until the CLR needs access to the assembly’s code. It’s possible that the code in some assemblies won’t be executed, so there isn’t a need to use resources unless absolutely necessary.

As mentioned previously, the C# compiler produces IL as part of an assembly’s output. To execute the code, the CLR must translate the IL to binary code that the operating system understands. This is the responsibility of the JIT compiler.

As its name implies, the JIT compiler only compiles code before the first time that it executes. After the IL is compiled to machine code by the JIT compiler, the CLR holds the compiled code in a working set. The next time that the code must execute, the CLR checks its working set and runs the code directly if it is already compiled. It is possible that the working set could be paged out of memory during program execution, for various reasons that are necessary for efficient operation of the CLR on the particular machine it is running on. If more memory is available than the size of the working set, the CLR can hold on to the code. Additionally, in the case of Web applications where scalability is an issue, the working set can be swapped out due to periodic recycling or heavier load on the server, resulting in additional load time for subsequent requests.

The JIT compiler operates at the method level. If you aren’t familiar with the term method, it is essentially the same as a function or procedure in other languages. Therefore, when the CLR begins execution, the JIT compiler compiles the entry point (the Main method in C#). Each subsequent method is JIT compiled just before execution. If a method being JIT compiled contains calls to methods in another assembly, the CLR loads that assembly (if not already loaded).

This process of checking the working set, JIT compilation, assembly loading, and execution continues until the program ends.

The meaning to you in the CLR execution process is in the form of application design and understanding performance characteristics. In the case of assembly loading, you have some control over when certain code is loaded. For example, if you have code that is seldom used or necessary only in specialized cases, you could separate it into its own DLL, which will keep the CLR from loading it when not in use. Similarly, separating seldomly executed logic into a separate method ensures the code doesn’t JIT until it’s called.

There are three types of JIT compilation in the .NET framework:

Normal JIT Compilation

With the Normal JIT Compiler methods are compiled when called at runtime. After execution this method is stored in the memory and it is commonly referred as “jitted”. No further compilation is required for the same method. Subsequent method calls are accessible directly from the memory cache.

Econo JIT Compilation

It compiles methods when called at runtime and removes them from memory after execution.

Pre-JIT Compilation

It compiles the entire assembly instead of used methods. In .NET languages, this is implemented in Ngen.exe (Native Image Generator). All CIL instructions are compiled to native code before startup. This way the runtime can use native images from the cache instead of invoking the JIT Compiler.

При подготовке материала использовались источники:
https://learn.microsoft.com/ru-ru/dotnet/standard/clr
https://professorweb.ru/my/csharp/charp_theory/level1/1_4.php
https://medium.com/@mirzafarrukh13/common-language-runtime-dotnet-83e0218edcae