Общеязыковая исполняющая среда 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-решений доступ к этой конкретной сборке будет предоставляться автоматически.

Механизм mscoree.dll

На данной схеме наглядно видно, как выглядят взаимоотношения между исходным кодом (предусматривающим использование типов из библиотеки базовых классов), компилятором .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, а также другими выгодами от запуска управляемого кода.