Предисловие

Управляемый модуль содержит управляемый код.

Управляемый код – это код, который выполняется в среде CLR. Код строится на основе объявляемых в исходном модуле структур и классов, содержащих объявления методов. Управляемому коду должен соответствовать определенный уровень информации (метаданных) для среды выполнения. Код C#, Visual Basic, и JScript является управляемым по умолчанию. Код Visual C++ не является управляемым по умолчанию, но компилятор может создавать управляемый код, для этого нужно указать аргумент в командной строке(/CLR). Одной из особенностей управляемого кода является наличие механизмов, которые позволяют работать с УПРАВЛЯЕМЫМИ ДАННЫМИ.

Управляемые данные – объекты, которые в ходе выполнения кода модуля размещаются в управляемой памяти (в управляемой куче) и уничтожаются сборщиком мусора CLR. Данные C#, Visual Basic и JScript .NET являются управляемыми по умолчанию. Данные C# также могут быть помечены как неуправляемые.

Сборка (Assembly) – базовый строительный блок приложения в .NET Framework. Управляемые модули объединяются в сборки. Сборка является логической группировкой одного или нескольких управляемых модулей или файлов ресурсов. Управляемые модули в составе сборок исполняются в Среде Времени Выполнения (CLR). Сборка может быть либо исполняемым приложением (при этом она размещается в файле с расширением .exe), либо библиотечным модулем (в файле с расширением .dll). При этом ничего общего с обычными (старого образца!) исполняемыми приложениями и библиотечными модулями сборка не имеет.

Декларация сборки (Manifest) – составная часть сборки. Это еще один набор таблиц метаданных, который:

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

Эта информация используется в период выполнения для поддержки корректной работы приложения.

Процессор НЕ МОЖЕТ выполнять IL-код. Перевод IL-кода осуществляется JIT-компилятором (Just In Time – в нужный момент), который активизируется CLR по мере необходимости и выполняется процессором. При этом результаты деятельности JIT-компилятора сохраняются в оперативной памяти. Между фрагментом оттранслированного IL-кода и соответствующим блоком памяти устанавливается соответствие, которое в дальнейшем позволяет CLR передавать управление командам процессора, записанным в этом блоке памяти, минуя повторное обращение к JIT-компилятору.

В среде CLR допускается совместная работа и взаимодействие компонентов программного обеспечения, реализованных на различных языках программирования.

На основе ранее сформированного блока метаданных CLR обеспечивает ЭФФЕКТИВНОЕ взаимодействие выполняемых .NET-приложений.

Для CLR все сборки одинаковы, независимо от того, на каких языках программирования они были написаны. Главное – это чтобы они соответствовали CLS. Фактически CLR разрушает границы языков программирования (cross-language interoperability). Таким образом, благодаря CLS и CTS, .NET-приложения оказываются приложениями на MSIL (IL).

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

• Проверка и динамическая (JIT) компиляция MSIL-кода в команды процессора.
• Управление памятью, процессами и потоками.
• Организация взаимодействия процессов.
• Решение проблем безопасности (в рамках существующей в системе политики безопасности).

Структура среды выполнения CLR (основные функциональные элементы среды) представлена на рисунке.

Строгий контроль типов, в частности, предполагает проверку соответствия типа объекта диапазону значений, которые могут быть присвоены данному объекту.

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

Функциональные блоки CLR Code Manager и Garbage Collector работают совместно: Code Manager обеспечивает размещение объектов в управляемой памяти, Garbage Collector – освобождает управляемую память.

Exception Manager включает следующие компоненты:

• finally handler (обеспечивает передачу управления в блок finally);
• fault handler (включается при возникновении исключения);
• type-filtered handler (обеспечивает выполнение кода соответствующего блока обработки исключения);
• user-filtered handler (выбор альтернативного блока исключения).

Ниже представлена схема выполнения .NET-приложения в среде CLR.

AppDomain (домен приложения) – это логический контейнер сборок, который используется для изоляции приложения в рамках адресного пространства процесса. Код, выполняемый в CLR (CLR-процесс), отделен от других процессов, выполняемых на компьютере в это же самое время. Обычный процесс запускается системой в рамках специально выделяемого процессу адресного пространства. CLR предоставляет возможность выполнения множества управляемых приложений в ОДНОМ ПРОЦЕССЕ. Каждое управляемое приложение связывается с собственным доменом приложения (сокращенно AppDomain). Все объекты, создаваемые приложением, создаются в рамках определенного домена приложения. Несколько доменов приложений могут существовать в одном процессе операционной системы. CLR изолирует приложения, управляя памятью в рамках домена приложения. В приложении, помимо основного домена, может быть создано несколько дополнительных доменов.