ЯЗЫК ПРОГРАММИРОВАНИЯ С# 2005 И ПЛАТФОРМА .NET 2.0. 3-е издание - Эндрю Троелсен
Шрифт:
Интервал:
Закладка:
Компоновочный блок также содержит метаданные, полностью описывающие форматы содержащихся в компоновочном блоке типов, а также форматы внешних типов, на которые ссылается данный компоновочный блок. Среда выполнения .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Мбайт, я уверен, вы поймете, в чем здесь преимущество.
Другим преимуществом многомодульных компоновочных блоков является то, что для них можно создавать модули на разных языках программирования .NET (что очень удобно в больших корпорациях, где разные подразделения могут отдавать предпочтение разным языкам .NET). После компиляции отдельных модулей эти модули можно логически "связать" в один компоновочный блок, используя, например, такой инструмент, как компоновщик (al.exe).
В любом случае следует понимать, что модули, которые образуют многомодульный компоновочный блок, не связаны непосредственно в один (больший) файл. Скорее, многомодульные компоновочные блоки связаны только логически информацией, содержащейся в манифесте первичного модуля. На рис. 11.4 показана схема многомодульного компоновочного блока, состоящего из трех модулей, каждый из которых написан на своем языке программирования .NET.
Рис. 11.4. Первичный модуль записывает информацию о вторичных модулях в манифест компоновочного блока
К этому моменту вы (я надеюсь) уже лучше понимаете внутреннюю структур двоичного файла .NET. Теперь "погрузимся" в обсуждение подробностей процесса построения и выбора конфигурации библиотек программного кода.
Создание и использование одномодульных компоновочных блоков
Чтобы инициировать процесс понимания компоновочных блоков .NET, мы с вами создадим одномодульный компоновочный блок *.dll (с именем CarLibrary), содержащий небольшой набор открытых типов. Чтобы построить библиотеку программного кода в Visual Studio 2005, выберите рабочую область Class Library (Библиотека классов) в окне Создания проектов (рис. 11.5).
Процесс разработки нашей библиотеки мы начнем с создания абстрактного базового класса Car (автомобиль), определяющего ряд защищенных членов-данных, доступных через пользовательские свойства.
Рис. 11.5. Создание библиотеки программного кода C#
Этот класс имеет один абстрактный метод TurboBoost(), в котором используется пользовательский перечень (EngineState), представляющий текущее состояние двигателя автомобиля.
using System;
namespace CarLibrary {
// Представляет состояние двигателя.
public enum EngineState { engineAlive, engineDead }
// Абстрактный базовый класс в данной иерархии.
public abstract class Car {
protected string petName;
protected short currSpeed;
protected short maxSpeed;
protected EngineState egnState = EngineState.engineAlive;
public abstract void TurboBoost();
public Car(){}
public Car(string name, short max, short curr) {
petName = name; maxSpeed = max; currSpeed = curr;
}
public string PetName {
get { return petName; }
set { petName = value; }
}
public short CurrSpeed {
get { return currSpeed; }
set { currSpeed = value; }
}
public short MaxSpeed { get { return maxSpeed; } }
public EngineState EngineState { get { return egnState; } }
}
}
Теперь предположим, что у вас есть два прямых "наследника" типа Car, имена которых MiniVan (минивэн) и SportsCar (спортивный автомобиль). Каждый из них подходящим образом переопределяет абстрактный метод TurboBoost().
using System;
using System.Windows.Forms;
namespace CarLibrary {
public class SportsCar: Car {
public SportsCar(){}
public SportsCar(string name, short max, short curr): base(name, max, curr) {}
public override void TurboBoost() {
MessageBox.Show("Скорость черепахи!", "Побыстрее бы…");
}
}
public class MiniVan: Car {
public MiniVan(){}
public MiniVan(string name, short max, short curr): base(name, max, curr){}
public override void TurboBoost() {
// Минивэн с турбонаддувом встретишь не часто!
egnState = EngineState.engineDead;
MessageBox.Show("Звoните в автосервис!", "Машина сломалась…");
}
}
}
Обратите внимание на то, что каждый из подклассов реализует TurboBoost() с помощью класса MessageBox, определенного в компоновочном блоке System. Windows.Forms.dll. Чтобы наш компоновочный блок мог использовать типы, определенные в рамках этого внешнего компоновочного блока, для проекта CarLibrary нужно указать ссылку на соответствующий двоичный файл в диалоговом окне Add Reference (Добавление ссылки), доступном в Visual Studio 2005 при выборе Project→Add Reference из меню (рис. 11.6).
