Наконец, в добавление к CIL и метаданным типов, сами компоновочные блоки также описываются с помощью метаданных, для которых используют специальное называние манифест (manifest). Манифест содержит информацию о текущей версии компоновочного блока, информацию о "культуре" (используемую для локализации строк и графических ресурсов) и список всех ссылок на внешние компоновочные блоки, которые требуются для правильного функционирования. Из следующих глав вы узнаете о различных инструментах, которые могут использоваться для исследования типов компоновочного блока, расшифровки его метаданных и манифеста.

Во многих случаях компоновочные блоки .NET- это просто файлы двоичного кода (*.dll или *.exe). Поэтому, если вы строите *.dll .NET, можно считать, что файл двоичного кода и компоновочный блок – это одно и то же. Точно также, если вы строите выполняемое приложение для настольной системы, файл *.exe тоже можно считать компоновочным блоком. Но из главы 11 вы узнаете, что указанное соответствие не столь однозначно. Строго говоря, если компоновочный блок состоит из одного модуля *.dll или *.exe, вы имеете одномодульный компоновочный блок. Одномодульный компоновочный блок содержит весь необходимый код CIL, метаданные и манифест в одном автономном отдельном пакете.

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

Но зачем создавать многомодульные компоновочные блоки? Когда вы делите компоновочный блок на отдельные модули, вы получаете более гибкие возможности инсталляции. Например, если пользователь ссылается на удаленный компоновочный блок, то среда выполнения загрузит на его машину только необходимые модули. Поэтому вы можете сконструировать свой компоновочный блок так, чтобы редко используемые типы (например, HardDriveReformatter) были выделены в отдельный автономный модуль.

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

Теперь, когда вы имеете начальное представление о компоновочных блоках .NET, давайте немного подробнее обсудим роль общего промежуточного языка (CIL). CIL- это язык, находящийся выше любого набора инструкций, специфического для конкретной платформы. Независимо от того, какой язык .NET вы выберете для использования, соответствующий компилятор сгенерирует инструкции CIL. Например, следующий программный код C# моделирует тривиальный калькулятор. Не пытаясь пока что полностью понять синтаксис этого примера, обратите внимание на формат метода Add в классе Calc.

После того как компилятор C# (csc.exe) скомпилирует этот файл исходного кода, вы получите состоящий из одного файла компоновочный блок *.exe, который содержит манифест, CIL-инструкции и метаданные, описывающие каждый аспект классов Calc и CalcApp. Например, если вы откроете этот компоновочный блок с помощью ildasm.exe (мы рассмотрим ildasm.exe немного позже в этой же главе), вы увидите, что метод Add в терминах CIL представляется так.