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

В своей базе компоновочный блок содержит программный код CIL, который, как вы помните, является промежуточным языком, не зависящим от платформы и процессора. В среде выполнения внутренний CIL-код компилируется "на лету" (с помощью JIT-компилятора [just-in-time compiler – оперативный компилятор]) в специфические для данной платформы и данного процессора инструкции. В рамках такого подхода компоновочные блоки .NET действительно могут выполняться в условиях самого широкого разнообразия архитектур, устройств и операционных систем. Вы можете вполне обойтись и без понимания особенностей языка программирования CIL, но, тем не менее, в главе 15 предлагается краткое введение в синтаксис и семантику CIL.

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

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

Замечание. К этому моменту, наверное, уже не нужно повторять, что для просмотра программного кода CIL компоновочного блока, метаданных типов иди манифеста можно использовать ildasm.exe. Я предполагаю, что вы будете часто использовать ildasm.exe при изучении примеров этой главы.

Наконец, компоновочный блок .NET может содержать любой набор встроенных ресурсов, таких как, например, пиктограммы приложении, графические файлы, звуковые фрагменты или таблицы строк. Платформа .NET обеспечивает поддержку сопутствующих компоновочных блоков, которые не содержат ничего, кроме локализованных ресурсов. Это может понадобиться тогда, когда требуется предоставить ресурсы на разных языках (английском, немецком и т.д.) при создании программного обеспечения, используемого в разных странах. Тема создания сопутствующих компоновочных блоков выходит за рамки этой книги, но при изучении GDI+ в главе 20 вы узнаете, как встроить ресурсы приложения в компоновочный блок.

Компоновочный блок можно скомпоновать из одного или нескольких модулей. Модуль – это просто обобщающий термин для обозначения двоичных файлов .NET. В большинстве случаев компоновочный блок компонуется из одного модуля. В таком случае наблюдается взаимно однозначное соответствие между (логическим) компоновочным блоком и лежащим в его основе (физическим) двоичным файлом (отсюда и появляется термин одномодульный компоновочный блок).

Одномодульные компоновочные блоки содержат все необходимые элементы (информация: заголовка, программный код CIL, метаданные типов, манифест и требуемые ресурсы) в одном пакете *.exe или *.dll. На рис. 11.3 показана композиционная схема одномодульного компоновочного блока.

Многомодульный компоновочный блок, напротив, является набором .NET-файлов *.dll, которые инсталлируются как одна логическая единица и контролируются по единому идентификатору версии. Формально один из этих файлов *.dll называется первичным модулем, он содержит манифест компоновочного блока (а также необходимый программный код CIL, метаданные, информацию заголовка и опциональные ресурсы). Манифест первичного модуля содержит записи о каждом из связанных файлов *.dll, от которых он зависит.

Рис. 11.3. Одномодульный компоновочный блок

По соглашению о выборе имен вторичные модули в многомодульном компоновочном блоке имеют расширение *.netmodule, однако это не является непременным требованием CLR. Вторичные файлы *.netmodule также содержат CIL-код и метаданные типов, а также манифест уровня модуля, в котором просто записана информация о внешних компоновочных блоках, необходимых для данного конкретного модуля.

Главное преимущество построения многомодульных компоновочных блоков заключается в том, что они обеспечивают очень эффективный способ загрузки содержимого. Предположим, например, что у нас есть машина, которая ссылается на удаленный многомодульный компоновочный блок, состоящий из трех модулей, причем первичный модуль установлен на машине клиента. Если клиент потребует тип из вторичного удаленного файла *.netmodule, среда CLR загрузит двоичный выполняемый файл на локальную машину по требованию в специальное место, называемое кэшем загрузки. Если каждый файл *.netmodule имеет объем 1Мбайт, я уверен, вы поймете, в чем здесь преимущество.