Установка четких границ типов
Из главы 3 вы узнали о формальных понятиях, лежащих в основе любого пространства имен .NET. Напомним, что абсолютное имя типа строится путем добавления префикса пространства имен (например, System) к имени типа (например, Console). Однако, строго говоря, компоновочный блок, содержащий данный тип, задает параметры дальнейшей идентификации типа. Например, если у вас есть два компоновочных блока с разными названиями (скажем, MyCars.dll и YourCars.dll), которые определяют пространство имен (CarLibrary), содержащее класс SportsCar, то эти классы во "вселенной" .NET будут считаться разными типами.
Управление версиями
Компоновочным блокам .NET назначается состоящий из четырех частей числовой идентификатор версии, имеющий вид ‹главный номер версии›.‹дополнительный номер версии›.‹номер компоновки›.‹номер варианта› (если вы не укажете явно идентификатор версии с помощью свойства [AssemblyVersion], компоновочный блок автоматически получит идентификатор версии 0.0.0.0). Этот идентификатор в совокупности с необязательным значением открытого ключа позволяет множеству версий одного и того же компоновочного блока сосуществовать на одной и той нее машине в полной гармонии, Компоновочные блоки, обеспечивающие информацию об открытом ключе, называются строго именованными. Как будет показано в этой главе позже, при наличии строго заданного имени среда CLR способна гарантировать, что по запросу вызывающего клиента будет загружена именно та версия компоновочного блока, которая требуется.
Самоописание
Компоновочные блоки считаются единицами с частичным самоописанием, поскольку в них содержится информация о внешних компоновочных блоках, необходимых для правильного функционирования компоновочного блока. Так что если вашему компоновочному блоку требуются System.Windows.Forms.dll и System. Drawing.dll, то информация о них будет записана в манифест компоновочного блока. Вспомните из главы 1, что манифест – это блок метаданных, описывающих сам компоновочный блок (имя, версия, информация о внешних компоновочных блоках и т.д.).
Кроме данных манифеста, компоновочный блок содержит метаданные, описывающие структуру каждого содержащегося типа (имена членов, реализуемые интерфейсы, базовые классы, конструкторы и т.д.). И поскольку компоновочный блок документируется настолько "красноречиво", среда CLR не обращается к реестру системы Win32 для выяснения размещения компоновочного блока (что принципиально отличается от предлагавшейся ранее Microsoft модели программирования COM). Из этой главы вы узнаете, что среда CLR использует совершенно новую схему получения информации о размещении внешних библиотек программного кода.
Средства конфигурации
Компоновочные блоки можно инсталлировать как "приватные" или как "общедоступные". Приватные компоновочные блоки размещаются в том же каталоге (или, возможно, подкаталоге), что и использующее их приложение-клиент. Общедоступные компоновочные блоки, напротив, являются библиотеками, доступными для многих приложений, и такие компоновочные блоки устанавливаются в специальный каталог, имеющий специальное название – глобальный кэш компоновочных блоков (CAG).
Независимо от вида инсталляция компоновочных блоков, вы можете создавать для них XML-файлы конфигурации. С помощью этих файлов можно дать среде CLR "указание" о том, где следует искать компоновочные блоки, какую версию соответствующего компоновочного блока следует загрузить для конкретного клиента, к какому каталогу на локальной машине, в вашей локальной сети или по какому заданному адресу URL в Web следует обратиться. Более подробную информацию о XML-файлах конфигурации вы получите в дальнейшем при изучении материала этой главы.
Формат компоновочного блока .NET
Теперь, когда вы знаете о некоторых преимуществах, обеспечиваемых компоновочными блоками .NET, давайте немного сместим акценты и попытаемся понять то, как устроены компоновочные блоки. С точки зрения внутренней структуры, компоновочный блок .NET (*.dll или *.exe) состоит из следующих элементов.
• Заголовок Win32
• Заголовок CLR
• CIL-код
• Метаданные типа
• Манифест компоновочного блока
• Необязательные встроенные ресурсы
Первые два элемента (заголовки Win32 и CLR) – это блоки данных, которыми вы можете обычно пренебречь, так что в отношении этих заголовков здесь предлагается только самая общая информация. С учетом этого мы и рассмотрим все указанные элементы по очереди.
Заголовок Win32
Заголовок Win32 декларирует, что компоновочный блок может загружаться и управляться средствами операционных систем семейства Windows. Данные этого заголовка также идентифицируют тип приложения (консольное, с графическим интерфейсом или библиотека программного кода *.dll). Чтобы увидеть информацию заголовка Win32 компоновочного блока, откройте компоновочный блок .NET с помощью утилиты dumpbin.exe (в окне командной строки .NET Framework 2.0 SDK) с флагом /headers. На рис. 11.1 показана часть информации заголовка Win32 для компоновочного блока CarLibrary.dll, который вы построите в этой главе немного позже.
Заголовок CLR
Заголовок CLR- это блок данных, который должны поддерживать все файлы .NET (и действительно поддерживают, благодаря компилятору C#), чтобы среда CLR имела возможность обрабатывать их. По сути, этот заголовок определяет множество флагов, позволяющих среде выполнения выяснить структуру данного управляемого файла. Например, существуют флаги, позволяющие идентифицировать размещение метаданных и ресурсов в файле, выяснить версию среды выполнения, для которой создавался компоновочный блок, значение (необязательного) открытого ключа и т.д. Если с dumpbin.exe использовать флаг /clrheader, вы получите внутреннюю информацию заголовка CLR для данного компоновочного блока .NET, как показано на рис. 11.2.
Заголовок CLR компоновочного блока представляется неуправляемой структурой C-типа (IMAGE _ COR20 _ HEADER), определенной в файле C-заголовка corhdr.h.
Рис. 11.1. Информация заголовка Win32 компоновочного блока
Рис. 11.2. Информация заголовка CLR компоновочного блока
Для заинтересованных читателей предлагаем ознакомиться с видом структуры, о которой здесь идет речь.
// Структура заголовка CLR 2.0.
typedef struct IMAGE_COR20_HEADER {
// Версии заголовка.
ULONG cb;
USHORT MajorRuntimeVersion;
USHORT MinorRuntimeVersion;
// Таблица символов и начальная информация.
IMAGE_DATA_DIRECTORY MetaData;
ULONG Flags;
ULONG EntryPointToken;
// Информация связывания.
IMAGE_DATA_DIRECTQRY Resources;
IMAGE_DATA_DIRECTORY StrongNameSignature;
// Стандартная информация адресации и связывания.
IMAGE_DATA_DIRECTQRY CodeManagerTable;
IMAGE_DATA_DIRECTORY VTableFixups;
IMAGE_DATA_DIRECTORY ExportAddressTableJumps;
// Информация прекомпилированного образа (только для
// внутреннего использования – обнуляется)
IMAGE_DATA_DIRECTORY ManagedNativeHeader;
} IMAGE_COR20_HEADER;
Снова обращаем ваше внимание на то, что вам, как разработчику .NET-приложений, не придется иметь дело с информацией заголовков Win32 и CLR (за исключением того случая, когда вы захотите построить новый управляемый компилятор). Вам достаточно понимать, что каждый компоновочный блок .NET обязательно содержит эти данные, используемые средой выполнения .NET и операционной системой Win32.
Программный код CIL, метаданные типа и манифест компоновочного блока
В своей базе компоновочный блок содержит программный код CIL, который, как вы помните, является промежуточным языком, не зависящим от платформы и процессора. В среде выполнения внутренний CIL-код компилируется "на лету" (с помощью JIT-компилятора [just-in-time compiler – оперативный компилятор]) в специфические для данной платформы и данного процессора инструкции. В рамках такого подхода компоновочные блоки .NET действительно могут выполняться в условиях самого широкого разнообразия архитектур, устройств и операционных систем. Вы можете вполне обойтись и без понимания особенностей языка программирования CIL, но, тем не менее, в главе 15 предлагается краткое введение в синтаксис и семантику CIL.
Компоновочный блок также содержит метаданные, полностью описывающие форматы содержащихся в компоновочном блоке типов, а также форматы внешних типов, на которые ссылается данный компоновочный блок. Среда выполнения .NET использует эти метаданные для нахождения типов (и их членов) в бинарном файле, для размещения типов в памяти удаленного вызова методов. Детали формата метаданных .NET будут изучаться в главе 12 при рассмотрении сервисов отображения.
