Онлайн библиотека PLAM.RU


  • ГЛАВА 11. Компоновочные блоки .NET
  • Роль компоновочных блоков .NET
  • Расширенные возможности многократного использования программного кода
  • Установка четких границ типов
  • Управление версиями
  • Самоописание
  • Средства конфигурации
  • Формат компоновочного блока  .NET
  • Заголовок Win32
  • Заголовок CLR
  • Программный код CIL, метаданные типа и манифест компоновочного блока
  • Необязательные ресурсы компоновочного блока
  • Одномодульные и многомодульные компоновочные блоки
  • Создание и использование одномодульных компоновочных блоков
  • Анализ манифеста
  • Анализ CIL-кода
  • Анализ метаданных типов
  • Создание приложения-клиента в C#
  • Создание приложения-клиента в Visual Basic .NET
  • Межъязыковое перекрестное наследование
  • Создание и использование многомодульных компоновочных блоков
  • Анализ файла ufo.netmodule
  • Анализ файла airvehicles.dll
  • Использование многомодульного компоновочного блока
  • Приватные компоновочные блоки
  • Идентификация приватных компоновочных блоков
  • Процесс зондирования
  • Конфигурация приватных компоновочных блоков
  • Файлы конфигурации и Visual Studio 2005
  • Утилита конфигурации NET Framework 2.0
  • Общедоступные компоновочные блоки
  • Строгая форма имени
  • Создание строгого имени для CarLibrary.dll
  • Назначение строгого имени в Visual Studio 2005
  • Установка и удаление общедоступных компоновочных блоков
  • Отложенная подпись
  • Использование общедоступных компоновочных блоков
  • Анализ манифеста SharedCarLibClient
  • Конфигурация общедоступных компоновочных блоков
  • Фиксация версии общедоступного компоновочного блока
  • Создание общедоступного компоновочного блока версии 2.0.0.0
  • Динамическая привязка к конкретной версии компоновочного блока
  • Снова об утилите конфигурации .NET Framework 2.0
  • Анализ внутренней структуры GAC
  • Файлы политики публикации компоновочных блоков
  • Игнорирование файла политики публикации
  • Элемент ‹codeBase›
  • Пространство имен System.Configuration
  • Файл конфигурации машины
  • Общая схема связей компоновочных блоков
  • Резюме
  • ГЛАВА 12. Отображение типов, динамическое связывание и программирование с помощью атрибутов
  • Метаданные типов
  • Анализ метаданных перечня EngineState
  • Анализ метаданных типа Car
  • Анализ TypeRef
  • Представление метаданных компоновочного блока
  • Представление ссылок на другие компоновочные блоки
  • Представление строковых литералов
  • Отображение типов в .NET
  • Класс System.Type
  • Получение Туре с помощью System.Object.GetType()
  • Получение Туре с помощью System.Type.GetType()
  • Получение Туре с помощью typeof()
  • Создание пользовательского приложения для просмотра метаданных
  • Отображение методов
  • Отображение полей и свойств
  • Отображение реализованных интерфейсов
  • Отображение вспомогательной информации
  • Реализация Main()
  • Отображение параметров и возвращаемых значений методов
  • Динамически загружаемые компоновочные блоки
  • Отображение общедоступных компоновочных блоков
  • Динамическое связывание
  • Класс System.Activator
  • Вызов методов без параметров
  • Вызов методов с параметрами
  • Программирование с помощью атрибутов
  • Потребители атрибутов
  • Применение встроенных атрибутов C#
  • Параметры конструктора для атрибутов
  • Атрибут Obsolete в действии
  • Сокращенное представление атрибутов в C#
  • Создание пользовательских атрибутов
  • Применение пользовательских атрибутов
  • Ограничение использования атрибута
  • Атрибуты уровня компоновочного блока (и уровня модуля)
  • Файл AssemblyInfo.cs в Visual Studio 2005
  • Отображение атрибутов при статическом связывании
  • Отображение атрибутов при динамическом связывании
  • Перспективы отображения, статического и динамического связывания и пользовательских атрибутов
  • Создание расширяемого приложения
  • Создание CommonSnappableTypes.dll
  • Создание подключаемого компонента в C#
  • Создание подключаемого компонента в Visual Basic .NET
  • Создание расширяемого приложения Windows Forms
  • Резюме
  • ГЛАВА 13. Процессы, домены приложений, контексты и хосты CLR
  • Выполнение традиционных процессов Win32
  • Обзор потоков
  • Взаимодействие с процессами в рамках платформы .NET
  • Список выполняемых процессов
  • Чтение данных конкретного процесса
  • Список множества потоков процесса
  • Информация о наборе модулей процесса
  • Начало и остановка процессов с помощью программных средств
  • Домены приложений .NET
  • Список доменов приложения процесса
  • Программное создание новых доменов приложения
  • Программная выгрузка доменов приложения
  • Границы контекста объекта
  • Контекстно-независимые и контекстно-связанные типы
  • Определение контекстно-связанных объектов
  • Проверка контекста объекта
  • Еще несколько слов о процессах, доменах приложения и контекстах
  • Хостинг общеязыковой среды выполнения
  • Параллельное выполнение CLR
  • Загрузка конкретной версии CLR
  • Дополнительные хосты CLR
  • Резюме
  • ГЛАВА 14. Создание многопоточных приложений
  • Взаимосвязь процессов, доменов приложений, контекстов и потоков
  • Проблема конкуренции и роль синхронизации потоков
  • Краткий обзор делегатов .NET
  • Асинхронная природа делегатов
  • Методы BeginInvoke() и EndInvoke()
  • Интерфейс System.IAsyncResult
  • Асинхронный вызов методов
  • Синхронизация вызывающего потока
  • Роль делегата AsyncCallback
  • Роль класса AsyncResult
  • Передача и получение пользовательских данных состояния
  • Пространство имен System.Threading
  • Класс System.Threading.Thread
  • Получение информации об отдельном потоке
  • Свойство Name
  • Свойство Priority
  • Программное создание вторичных потоков
  • Работа с делегатом ThreadStart
  • Работа с делегатом ParameterizedThreadStart
  • Приоритетные и фоновые потоки
  • Проблема конкурентного доступа
  • Синхронизация с помощью ключевого слова lock в C#
  • Синхронизация с помощью типа System.Threading.Monitor
  • Синхронизация с помощью типа System.Threading.Interlocked
  • Синхронизация с помощью атрибута [Synchronization]
  • Программирование с помощью таймеров обратного вызова
  • Пул потоков CLR
  • Резюме
  • ГЛАВА 15. CIL и роль динамических компоновочных блоков
  • Природа программирования в терминах CIL
  • Директивы, атрибуты и коды операций CIL
  • Роль директив CIL
  • Роль атрибутов CIL
  • Роль кодов операций CIL
  • Различия между мнемоникой и кодом операции CIL
  • Добавление и извлечение данных: стековая природа CIL
  • Челночная технология разработки
  • Роль меток в программном коде CIL
  • Взаимодействие с CIL: модификация файла *.il
  • Компиляция CIL-кода с помощью ilasm.exe
  • Компиляция CIL-кода с помощью SharpDevelop
  • Компиляция CIL-кода с помощью ILIDE#
  • Роль peverify.exe
  • Директивы и атрибуты CIL
  • Ссылки на внешние компоновочные блоки
  • Определение текущего компоновочного блока
  • Определение пространств имен
  • Определение типов класса
  • Определение и реализация интерфейсов
  • Определение перечней
  • Компиляция файла CILTypes.il
  • Соответствие между типами библиотеки базовых классов .NET, C# и CIL
  • Определение членов типов в CIL
  • Определение полей данных
  • Определение конструкторов типов
  • Определение свойств
  • Определение параметров членов
  • Анализ кодов операций CIL
  • Директива .maxstack
  • Объявление локальных переменных
  • Связывание параметров с локальными переменными
  • Скрытая ссылка this
  • Представление итерационных конструкций
  • Создание компоновочного блока .NET в CIL
  • Создание CILCars.dll
  • Создание CILCarClient.exe
  • Динамические компоновочные блоки
  • Исследование пространства имен System.Reflection.Emit
  • Роль System.Reflection.Emit.ILGenerator
  • Генерирование динамического компоновочного блока
  • Генерирование компоновочного блока и набора модулей
  • Роль типа ModuleBuilder
  • Генерирование типа HelloClass и принадлежащей ему строковой переменной
  • Генерирование конструкторов
  • Генерирование метода HelloWorld()
  • Использование динамически сгенерированного компоновочного блока
  • Несколько слов о System.CodeDOM
  • Резюме
  • ЧАСТЬ III. Программирование компоновочных блоков .NET

    ГЛАВА 11. Компоновочные блоки .NET

    Любое из приложений, описанных в этой книге в предыдущих десяти главах, было обычным "автономным" приложением, вся программная логика которого целиком содержались в одном выполняемом файле (*.exe). Однако одной из главных задач платформы .NET является многократное использование программного кода, при котором приложения могут использовать типы, содержащиеся в различных внешних компоновочных блоках (называемых также библиотеками программного кода). Целью этой главы будет подробное рассмотрение вопросов создания, инсталляции и конфигурации компоновочных блоков .NET.

    Сначала мы рассмотрим различия между одномодульными и многомодульными компоновочными блоками, а также между "приватными" и "общедоступными" компоновочными блоками. Затем мы выясним, как среда, выполнений .NET определяет параметры размещения компоновочного блока, и попытаемся понять роль GAC (Global Assembly Cache – глобальный кэш компоновочных блоков), файлов конфигурации приложения (файлы *.config), политики публикации компоновочных блоков и пространства имен System.Configuration.

    Роль компоновочных блоков .NET

    Приложения .NET строятся путем связывания произвольного числа компоновочных блоков. С точки зрения упрощенного подхода компоновочный блок является двоичным файлом, включающим свое описание, снабженным номером версии и поддерживаемым средой CLR (Common language Runtime – общеязыковая среда выполнения). Несмотря на тот факт, что компоновочные блоки  .NET имеют такие же расширения (*.exe или *.dll), как и другие двоичные файлы Win32 (включая все еще используемые серверы COM), по сути, компоновочные блоки .NET имеют с ними очень мало общего. Поэтому для начала мы рассмотрим некоторые преимущества, обеспечиваемые форматом компоновочного блока.

    Расширенные возможности многократного использования программного кода

    При построений консольных приложений в предыдущих главах могло показаться, что в создаваемом вами выполняемом компоновочном блоке содержатся все функциональные возможности соответствующего приложения. На самом же деле ваши приложения использовали множество типов, предлагаемых всегда доступной библиотекой программного кода .NET, mscorlib.dll (напомним, что компилятор C# ссылается на mscorlib.dll автоматически), а также библиотекой System.Windows.Forms.dll.

    Вы, наверное, знаете, что библиотека программного кода (также называемая библиотекой классов) представляет собой файл *.dll, содержащий типы, доступные для использования внешними приложениями. При создании выполняемого компоновочного блока используются компоновочные блоки, предлагаемые системой, а также пользовательские компоновочные блоки. При этом файл библиотеки программного кода не обязательно имеет вид *.dll, поскольку выполняемый компоновочный блок может использовать и типы, определенные во внешнем выполняемом файле. В этой связи файл *.exe тоже можно считать "библиотекой программного кода".

    Замечание. До появления Visual Studio 2005 единственную возможность сослаться на выполняемую библиотеку программного кода обеспечивал флаг /reference компилятора C#. Но теперь ссылаться на компоновочные блоки *.exe позволяет и диалоговое окно Add Reference (Добавление ссылки) в Visual Studio 2005.

    Независимо от того, как упакована библиотека программного кода, платформа .NET позволяет использовать типы в независимой от языка форме. Например, можно создать библиотеку программного кода в C# и использовать эту библиотеку в любом другом языке программирования .NET. При этом можно не только создавать экземпляры типов в рамках других языков, но и получить производные таких типов. Базовый класс, определенный в C#, можно расширить с помощью класса, созданного в Visual Basic .NET. Интерфейсы, определенные в Pascal .NET, могут реализовываться структурами, определенными в C#. Смысл в том, что при разделении единого и монолитного выполняемого программного кода на множество компоновочных блоков .NET вы получаете языково-нейтральную форму программного кода, пригодного для многократного использования.

    Установка четких границ типов

    Из главы 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 при рассмотрении сервисов отображения.

    Кроме того, компоновочный блок должен содержать ассоциированный манифест (также называемый метаданными компоновочного блока). Манифест документирует все модули данного компоновочного блока, задает версию компоновочного блока, а также предлагает информацию обо всех внешних компоновочных блоках, да которые ссылается данный компоновочный блок (в отличие от библиотек 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).

    Рис. 11.6. Здесь добавляются ссылки на внешние компоновочные блоки .NET

    Очень важно понимать, что в списке компоновочных блоков диалогового окна Add Reference могут быть представлены не все компоновочные блоки .NET, имеющиеся на вашей машине. Диалоговое окно Add Reference не отображает созданные вами пользовательские компоновочные блоки и не отображает компоновочные блоки, размещенные в GAC. Это диалоговое окно предлагает список общих компоновочных блоков, на отображение которых запрограммирована система Visual Studio 2005. При построении приложения, для которого требуется компоновочный блок, не представленный в списке диалогового окна Add Reference, вам придется перейти на вкладку Browse (Просмотр) и вручную найти необходимый файл *.dll или *.exe.

    Замечание. Можно сделать так, чтобы пользовательские компоновочные блоки тоже появлялись в списке диалогового окна Add Reference, если установить их копии в папку C:\Program Files\Microsoft Visual Studio 8\Common7\lDE\PublicAssemblies, но большого смысла в этом нет. На вкладке Recent (Недавние ссылки) предлагается список компоновочных блоков, на которые вы недавно ссылались.

    Анализ манифеста

    Перед тем как использовать CarLibrary.dll в приложении-клиенте, давайте выясним, из чего скомпонована библиотека программного кода. Предположив, что наш проект уже скомпилирован, загрузим CarLibrary.dll в ildasm.exe (рис. 11.7).

    Рис. 11.7. Библиотека CarLibrary.dll в окне ildasm.exe

    Теперь откройте манифест файла CarLibrary.dll двойным щелчком на пиктограмме MANIFEST. В первом блоке программного кода манифеста указываются внешние компоновочные блоки, необходимые соответствующему компоновочному блоку для правильного функционирования. Как вы помните, CarLibrary.dll использует типы из mscorlib.dll и System.Windows.Forms.dll, и оба эти файла будут указаны в списке манифеста с помощью лексемы .assembly extern внешних связей компоновочного блока.

    .assembly extern mscorlib {

     .publickeytoken = (В7 7A 5C 56 19 34 E0 89)

     .ver 2:0:0:0

    }

    .assembly extern System.Windows.Forms {

     .publickeytoken = (B7 7A 5C 56 19 34 E0 89)

     .ver 2:0:0:0.

    }

    Здесь каждый блок .assembly extern снабжен директивами .publickeytoken и .ver. Инструкция .publickeytoken указывается только тогда, когда компоновочный блок имеет строгую форму имени (подробности будут приведены в этой главе позже). Лексема.ver обозначает (конечно же) числовой идентификатор версии.

    После списка каталогизации внешних ссылок вы обнаружите ряд лексем.custom, идентифицирующих атрибуты уровня компоновочного блока. Проверив файл AssemblyInfо.cs, созданный в Visual Studio 2005, вы обнаружите, что эти атрибуты представляют такую информацию о компоновочном блоке, как название компании, торговая марка и т.д. (все соответствующие поля в данный момент пусты). В главе 14 атрибуты будут рассматриваться подробно, поэтому пока что не обращайте на них большого внимания. Однако следует знать, что атрибуты из AssemblyInfo.cs добавляют в манифест ряд лексем .custom, например, [AssemblyTitle].

    .assembly CarLibrary {

     …

     .custom instance void [mscorlib]

     System.Reflection.AssemblyTitleAttribute::.ctor(string) = (01 00 00 00 00)

     .hash algorithm 0x00008004

     .ver 1:0:454:30104

    }

    .module CarLibrary.dll

    Наконец, вы можете заметить, что лексема .assembly используется для обозначения понятного имени компоновочного блока (CarLibrary), в то время как лексема .module указывает имя самого модуля (CarLibrary.dll). Лексема .ver определяет номер версии, назначенный для компоновочного блока в соответствии с атрибутом [AssemblyVersion] из AssemblyInfo.cs. Подробнее об управлении версиями компоновочного блока будет говориться в этой главе позже, а сейчас необходимо заметить, что групповой символ * в атрибуте [AssemblyVersion] информирует Visual Studio 2005 о необходимости в процессе компиляции выполнить приращение для идентификатора версии в отношении номеров компоновки и варианта.

    Анализ CIL-кода

    Напомним, что компоновочный блок не содержит специфических для платформы инструкций, а содержит независимый от платформы CIL-код. Когда среда выполнения .NET загружает компоновочный блок в память, этот CIL-код компилируется (с помощью JIT-компилятора) в инструкции, понятные для данной платформы. Если выполнить двойной щелчок на строке метода TurboBoost() класса SportsCar, с помощью ildasm.exe откроется новое окно, в котором будут показаны CIL-инструкции.

    .method public hidebysig virtual instance void TurboBoost() cil managed {

     // Code size 17 (0x11)

     .maxstack 2

     IL_0000: ldstr "Ramming speed!"

     IL_0005: ldstr "Faster is better…"

     IL_000a: call valuetype [System.Windows.Forms] System.Windows.Forms.DialogResult [System.Windows.Forms] System.Windows.Forms.MessageBox::Show(string, string)

     IL_000f: pop

     IL_0010: ret

    } // end of method SportsCar::TurboBoost

    Обратите внимание на то, что для идентификации метода, определенного типом SportsCar, используется лексема .method. Члены-переменные, определенные типом, обозначаются лексемой .field. Напомним, что класс Car определяет набор защищенных данных, например, таких как currSpeed.

    .field family int 16 currSpeed

    Свойства обозначены лексемой.property. Этот CIL-код описывает открытое свойство CurrSpeed (заметьте, что характеристики read/write свойства обозначаются лексемами .get и .set).

    .property instance int16 CurrSpeed() {

     .get instance int16 CarLibrary.Car::get_CurrSpeed()

     .set instance void CarLibrary.Car::set_CurrSpeed(int16)

    } // end of property Car::CurrSpeed

    Анализ метаданных типов

    Наконец, если вы сейчас нажмете комбинацию клавиш ‹Ctrl+M›, ildasm.exe отобразит метаданные для каждого из типов, имеющихся в компоновочном блоке CarLibrary.dll (рис. 11.8).

    Рис. 11.8. Метаданные для типов на CarLibrary.dll

    Теперь, после того как мы с вами заглянули внутрь компоновочного блока CarLibrary.dll, мы можем приступить в построению приложений клиента.

    Исходный код. Проект CarLibrary размещен в подкаталоге, соответствующем главе 11.

    Создание приложения-клиента в C#

    Ввиду тот, что все типы CarLibrary были объявлены с ключевым словом public, другие компоновочные блоки способны их использовать. Напомним, что вы можете также объявлять типы с использованием ключевого слова C# internal (именно этот режим доступа в C# используется до умолчанию, когда вы определяете тип без указания public). Внутренние типы могут использоваться только тем компоновочным блоком, в котором они определены. Внешние клиенты не могут ни видеть, ни создавать внутренние типы компоновочных блоков.

    Замечание. Сегодня .NET 2.0 предлагает возможность указать "дружелюбные" компоновочное блоки, которые позволяют использовать свои внутренние типы заданным компоновочным блокам. Подробности можно найти в разделе документации .NET Framework 2.0 SDK с описанием класса InternalsVisibleToAttribute.

    Для использования открытых типов CarLibrary создайте новый проект консольного приложения C# (CSharpCarClient). После этого добавьте ссылку на Carbibrary.dll на вкладке Browse диалогового окна Add Reference (если вы скомпилировали CarLibrary.dll в Visual Studio 2005, ваш компоновочный блок будет размещен в подкаталоге \Bin\Debug папки проекта CarLibrary). После щелчка на кнопке ОК Visual Studio 2005 поместит копию CarLibrary.dll в папку \Bin\Debug папки проекта CSharpCarClient (рис. 11.9).

    Рис. 11.9. Visual Studio 2005 копирует приватные компоновочные блоки в каталог клиента

    С этого момента вы можете компоновать приложение-клиент с использованием внешних типов. Модифицируйте свой исходный C#-файл так.

    using System;

    // Не забудьте 'использовать' пространство имен CarLibrary!

    using CarLibrary;

    namespace CSharpCarClient {

     public class CarClient {

      static void Main(string[] args) {

       // Создание спортивной машины.

       SportsCar viper = new SportsCar("Viper", 240, 40);

       viper.TurboBoost();

       // Создание минивэна.

       MiniVan mv = new MiniVan();

       mv.TurboBoost();

       Console.ReadLine();

      }

     }

    }

    Этот программный код очень похож на программный код приложений, создававшихся нами ранее. Единственным отличием является то, что теперь приложение-клиент C# использует типы, определенные в отдельном пользовательском компоновочном блоке. Запустите эту программу, и вы увидите на своем экране целый ряд окон сообщений.

    Исходный код. Проект CSharpCarClient размещён в подкаталоге, соответствующем главе 11.

    Создание приложения-клиента в Visual Basic .NET

    Чтобы продемонстрировать языковую независимость платформы .NET, создадим другое консольное приложение (VbNetCarClient) на этот раз с помощью Visual Basic .NET (рис. 11.10). Создав проект, укажите ссылку на CarLibrary.dll с помощью диалогового окна Add Reference.

    Рис. 11.10. Создание консольного приложения Visual Basic .NET

    Как и в C#, в Visual Basic .NET требуется указать список всех пространств имен, используемых в текущем файле. Но в Visual Basic .NET для этого предлагается использовать ключевое слово Imports, а не ключевое слово using, как в C#. С учетом этого добавьте следующий оператор Imports в файл программного кода Module1.vb.

    Imports CarLibrary

    Module Module1

     Sub Маin()

     End Sub

    End Module

    Обратите внимание на то, что метод Main() определен в рамках типа Module Visual Basic .NET (который не имеет ничего общего с файлами *.netmodule многомодульных компоновочных блоков). В Visual Basic .NET Module используется просто для обозначения определения изолированного класса, содержащего только статические методы. Чтобы сделать это утверждение более понятным, вот аналог соответствующей конструкции в C#.

    // 'Module' в VB .NET - это просто изолированный класс,

    // содержащий статические методы.

    public sealed class Module1 {

     public static void Main() {

     }

    }

    Так или иначе, чтобы использовать типы MiniVan и SportsCar в рамках синтаксиса Visual Basic .NET, измените метод Main() так, как предлагается ниже.

    Sub Main()

     Console.WriteLine("***** Забавы с Visual Basic .NET *****")

     Dim myMiniVan As New MiniVan()

     myMiniVan.TurboBoost()

     Dim mySportsCar As New SportsCar()

     mySportsCar.TurboBoost()

     Console.ReadLine()

    End Sub

    После компиляции и выполнения приложения вы снова увидите соответствующий набор окон с сообщениями.

    Межъязыковое перекрестное наследование

    Весьма привлекательной возможностью .NET является межъязыковое перекрестное наследование. Для примера давайте создадим новый класс Visual Basic .NET, который будет производным от SportsCar (напомним, что последний был создан в C#). Сначала добавим файл нового класса с именем PerformanceCar.vb в имеющееся приложение Visual Basic .NET (с помощью выбора Project>Add Class из меню). Обновим исходное определение класса путем получения производного типа из SportsCar, используя ключевое слово Inherits. Кроме того, переопределим абстрактный метод TurboBoost(), используя для этого ключевое слово Overrides.

    Imports CarLibrary

    ' Этот VB-тип является производным C#-типа SportsCar.

    Public Class PerformanceCar Inherits SportsCar

     Public Overrides Sub TurboBoost()

      Console.WriteLine("От нуля до 100 за какие-то 4,8 секунды…")

     End Sub

    End Class

    Чтобы проверить работу нового типа класса, обновите метод Main() модуля так.

    Sub Main()

     …

     Dim dreamCar As New PerformanceCar()

     ' Наследуемое свойство.

     dreamCar.PetName = "Hank"

     dreamCar.TurboBoost()

     Console.ReadLine()

    End Sub

    Обратите внимание на то, что объект dreamCar способен вызывать любые открытые члены (например, свойство PetName) по цепочке наследования, несмотря на то, что базовый класс определен на совершенно другом языке и в другой библиотеке программного кода.

    Исходный код. Проект VbNetCarClient размещен в подкаталоге, соответствующем Главе 11.

    Создание и использование многомодульных компоновочных блоков

    Теперь, когда вы научились строить и использовать одномодульные компоновочные блоки, рассмотрим процесс создания многомодульных компоновочных блоков, Напомним, что многомодульный компоновочный блок – это просто набор связанных модулей, инсталлируемых как цельная единица и контролируемых по единому номеру версии. На момент создания этой книги в Visual Studio 2005 не предлагался шаблон проекта дли многомодульного компоновочного блока C#. Поэтому для построения такого проекта вам придется использовать компилятор командной строки (csc.exe).

    Для примера мы с вами построим многомодульный компоновочный блок с названием AirVehicles (авиатранспорт). Первичный модуль (airvehicles.dll) будет содержать один тип класса Helicopter (вертолет). Соответствующий манифест (также содержащийся в airvehicles.dll) каталогизирует дополнительный файл *.netmodule с именем ufo.netmodule, который будет содержать другой тип класса, называющийся, конечно же, Ufo (НЛО). Эти два типа класса физически содержатся в отдельных двоичных файлах, но мы сгруппируем их в одном пространстве имен, названном AirVehicles. Наконец, оба класса будут созданы с помощью C# (хотя вы, если хотите, можете использовать и разные языки).

    Для начала откройте простой текстовый редактор (например, Блокнот) и создайте следующее определение класса Ufo, сохранив затем его в файле с именем ufo.cs.

    using System;

    namespace AirVehicles {

     public class Ufo {

      public void AbductHuman() {

       Console.WriteLine("Сопротивление бесполезно");

      }

     }

    }

    Чтобы скомпилировать этот класс в .NET-модуль, перейдите в папку, содержащую ufo.cs. и введите следующую команду компилятору C# (опция module флага /target "информирует" csc.exe о том, что необходимо построить файл *.netmodule, а не *.dll или *.exe).

    csc.exe /t:module ufo.cs

    Если теперь заглянуть в папку, содержащую файл ufo.cs, вы должны увидеть новый файл с именем ufo.netmodule (проверьте!). После этого создайте новый файл с именем helicopter.cs, содержащий следующее определение класса.

    using System;

    namespace AirVehicles {

     public class Helicopter {

      public void TakeOff() {

       Console.WriteLine("Вертолет на взлет!");

      }

     }

    }

    Поскольку название airvehicles.dll было зарезервировано для первичного модуля нашего многомодульного компоновочного блока, вам придется компилировать helicopter.cs с использованием опций /t:library и /out:. Чтобы поместить запись о двоичном объекте ufo.netmodule в манифест компоновочного блока, вы должны также указать флаг /addmodule. Все это делает следующая команда.

    csc /t:library /addmodule:ufo.netmodule /out:airvehicles.dll helicopter.cs

    К этому моменту ваш каталог должен содержать первичный модуль airvehicles.dll, а также вторичный ufo.netmodule.

    Анализ файла ufo.netmodule

    Теперь с помощью ildasm.exe откройте ufo.netmodule. Вы убедитесь, что *.netmodule содержит манифест уровня модуля, однако его единственной целью является указание списка всех внешних компоновочных блоков, на которые есть ссылки в соответствующем программном коде. Поскольку класс Ufo, по сути, выполняет только вызов Console.WriteLine(), вы обнаружите следующее.

    .assembly extern mscorlib {

     .publickeytoken = (B7 7A 5C 56 19 34 E0 89)

     .ver 2:0:0:0

    }

    .module ufo.netmodule

    Анализ файла airvehicles.dll

    Теперь в помощью ildasm.exe откройте первичный модуль airvehicles.dll и рассмотрите манифест уровня компоновочного блока. Вы увидите, что лексемы.file документируют ассоциированные модули многомодульного компоновочного блока (в данном случае ufo.netmodule). Лексемы.class extern используются для указания имен внешних типов из вторичного модуля (Ufo), на которые имеются ссылки.

    .assembly extern mscorlib {

     .publickeytoken = (B7 7A 5C 56 19 34 E0 89)

     .ver 2:0:0:0

    }

    .assembly airvehiсles {

     …

     .hash algorithm 0x00008004

     .ver 0:0:0:0

    }

    .file ufо.netmodule

    .class extern public AirVehicles.Ufo {

     .file ufo.netmodule

     .class 0x02000002

    }

    .module airvehicles.dll

    Снова подчеркнем, что манифест компоновочного блока является единственным объектом, связывающим airvehicles.dll и ufo.netmodule. Указанные два бинарных файла не содержатся в одном, большем *.dll.

    Использование многомодульного компоновочного блока

    Пользователей многомодульного компоновочного блока не должно заботить то, что компоновочный блок, на который они ссылаются, состоит из нескольких модулей. Чтобы пояснить ситуацию, мы построим новое приложение-клиент Visual Basic .NET с командной строки. Создайте новый файл Client.vb, содержащий приведенное ниже определение. Сохраните его в там месте, где находится ваш многомодульный компоновочный блок.

    Imports AirVehicles

     Module Module1

     Sub Main()

      Dim h As New AirVehicles.Helicopter()

      h.Takeoff()

      ' Это загрузит *.netmodule по требованию.

      Dim u As New UFO()

      u.AbductHuman()

      Console.ReadLine()

     End Sub

    End Module

    Чтобы скомпилировать этот выполняемый компоновочный блок с командной строки, используйте компилятор командной строки Visual Basic .NET vbc.exe со следующим набором команд.

    vbc /r:airvehicles.dll *.vb

    Обратите внимание на то, что при ссылке на многомодульный компоновочный блок компилятору нужно указать только имя первичного модуля (файлы *.netmodule загружаются по запросу программного кода клиента). В самих файлах *.netmodules нет индивидуального номера версии, и они не могут непосредственно загружаться средой CLR Файл *. netmodule может загружаться только первичным модулем (например, файлом, содержащим манифест компоновочного блока).

    Замечание. В Visual Studio 2005 позволяется ссылаться и на многомодульные компоновочные блоки. Используйте диалоговое окно Add Reference и выберите первичный модуль, В результате будут скопированы и все связанные файлы *.netmodule.

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

    Исходный код. Проект MultifileAssembly размещен в подкаталоге, соответствующем главе 11.

    Приватные компоновочные блоки

    Компоновочные блоки, которые создавались вами в этой главе до сих пор, инсталлировались, как приватные компоновочные блоки. Приватные компоновочные блоки должны размещаться в том же каталоге, что и приложение-клиент (такой каталог называется каталогом приложения) или в его подкаталоге. Напомним, что результатом добавления ссылки на CarLibrary.dll при построении приложений CSharpCarClient.exe и VbNetCarClient.exe в Visual Studio 2005 было копирование CarLibrary.dll в каталог приложения-клиента.

    Когда программа-клиент использует типы, определенные в этом внешнем компоновочном блоке, среда CLR просто загружает локальную копию CarLibrary.dll. Ввиду того, что среда выполнения .NET не использует реестр системы при поиске компоновочных блоков, вы можете переместить компоновочные блоки CSharpCarClient.exe (или VbNetCarClient.exe) вместе c CarLibrary.dll в другое место на своей машине и успешно запустить приложение.

    Деинсталляция (a также тиражирование) приложения, использующего исключительно приватные компоновочные блоки, не требует особых усилий: нужно просто удалить (или скопировать) папку приложения. В отличие от COM-приложений, здесь не нужно беспокоиться о десятках "осиротевших" параметров, разделов и ветвей реестра. Но еще более важно то, что удаление приватных компоновочных блоков никак не влияет на работоспособность других приложений, установленных на машине.

    Идентификация приватных компоновочных блоков

    Полный идентификатор приватного компоновочного блока состоит из понятного имени компоновочного блока и числового номера его версии, которые должны быть записаны в манифест компоновочного блока. Понятное имя (friendly name) – это просто имя модуля, содержащего манифест компоновочного блока, без файлового раcширения. Так, если вы проверите манифест компоновочного блока CarLibrary.dll, то обнаружите там следующее (ваша версия будет, скорее всего, другой).

    .assembly.CarLibrary {

     …

     .ver 1:0:454:30104

    }

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

    Процесс зондирования

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

    // Неявный запрос загрузки.

    .assembly extern CarLibrary

    {…}

    Явный запрос загрузки происходит при использовании в программе метода Load() или LoadFrom() типа System.Reflection.Assembly, обычно с целью динамического связывания и динамического вызова членов запрашиваемого типа. Мы рассмотрим эти темы позже в главе 12, а сейчас только приведем пример явного запроса загрузки в следующем фрагменте программного кода.

    // Явный запрос загрузки.

    Assembly asm = Assembly.Load("CarLibrary");

    В любом из этих случаев среда CLR извлекает понятное имя компоновочного блока и начинает зондирование каталога приложения-клиента в поисках файла с именем CarLibrary.dll. Если этот файл не обнаружен, делается попытка найти выполняемый компоновочный блок с тем же понятным именем (CarLibrary.exe). Если ни одного из указанных файлов в каталоге приложения не обнаруживается, среда выполнения прекращает попытки и генерирует исключение FileNotFound.

    Замечание. Если запрошенного компоновочного блока в каталоге приложения-клиента нет, среда CLR пытается проверить подкаталог клиента с именем, соответствующим понятному имени запрошенного компоновочного блока (скажем, C:\MyClient\CarLibrary). Если запрошенный компоновочный блок обнаружится в таком подкаталоге, среда CLR загрузит найденный компоновочный блок в память.

    Конфигурация приватных компоновочных блоков

    Конечно, можно инсталлировать .NET-приложение с помощью простого копирования всех требуемых компоновочных блоков в одну папку на жестком диске пользователя, но вы, скорее всего, предпочтете определить ряд подкаталогов для группировки взаимосвязанного содержимого. Предположим, например, что у вас есть каталог приложения C:\MyApp, содержащий CSharpCarClient.exe. В этом каталоге может быть подкаталог с именем MyLibraries, который содержит CarLibrary.dll.

    Несмотря на предполагаемую связь между этими двумя каталогами, среда CLR не будет зондировать подкаталог MyLibraries, если вы не создадите файл конфигурации с соответствующим требованием. Файлы конфигурации состоят из XML-элементов, позволяющих влиять на процесс зондирования. "По закону" файлы конфигурации должны иметь то же имя, что и соответствующе приложение, но иметь расширение *.config, и должны размещаться в каталоге приложения-клиента. Так, если вы хотите создать файл конфигурации для CSharpCarClient.exe, он должен называться CSharpCarClient.exe.config.

    Для иллюстрации создайте новый каталог на вашем диске C, назвав его MyApp (например, с помощью Windows Explorer). Затем скопируйте CSharpCarClient.exe и CarLibrary.dll в этот новый каталог и запустите программу на выполнение с помощью двойного щелчка на ее файле. Ваша программа должна выполниться успешно (вспомните о том, что компоновочные блоки не требуют регистрации!). Теперь создайте в C:\MyApp подкаталог, выбрав для него название MyLibraries (рис. 11.11), и переместите в него CarLibrary.dll.

    Рис. 11.11. Теперь CarLibrary.dll размещается в подкаталоге MyLibraries

    Попытайтесь выполнить программу снова. Ввиду того, что среда CLR не сможет найти "CarLibrary" непосредственно в каталоге приложения, вы получите необработанное исключение FileNotFound (файл не найден).

    Чтобы выправить ситуацию создайте новый файл конфигурации CSharpCarClient.exе.config и сохраните его в папке, содержащей приложение CSharpCarClient.exe (в данном случае это папка C:\MyApp). Откройте cозданный файл и введите в него следующий код в точности так, как показано ниже (язык XML является чувствительным к регистру символов).

    <configuration>

     ‹runtime›

      ‹assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"›

       ‹probing privatePath="MyLibraries"/›

      ‹/assemblyBinding›

     ‹/runtime›

    ‹/configuration›

    Файлы *.config .NET всегда начинаются корневым элементом ‹configuration›. Вложенный в него элемент ‹runtime› может содержать элемент ‹assemblyBinding›, который, в свою очередь, может содержать вложенный элемент ‹probing›. Для данного примера наиболее важным является атрибут privatePath, поскольку он используется для указания подкаталогов в каталоге приложения, где среда CLR должна осуществлять зондирование.

    Обратите особое внимание на то, что элемент ‹probing› не указывает, какой компоновочный блок размещается в соответствующем подкаталоге. Поэтому вы не можете сказать, что "CarLibrary размещается в подкаталоге MyLibraries, a MathUtils – в подкаталоге Bin". Элемент ‹probing› просто дает среде CLR "инструкцию" при поиске запрошенного компоновочного блока исследовать указанные подкаталоги, пока не обнаружится первое совпадение.

    Замечание. Атрибут privatePath нельзя использовать для указания ни абсолютного (C:\Папка\Подпапка), ни относительного (…\\ОднаПапка\\ДругаяПапка) пути! Если вы хотите указать каталог вне пределов каталога приложения-клиента, вам придется использовать другой XML-элемент – элемент ‹codeBase› (дополнительные подробности об этом элементе будут приведены в этой же главе немного позже).

    Чтобы указать с помощью атрибута privatePath множество подкаталогов, используйте список значений, разделенных точками с запятой. В данный момент у вас в этом нет никакой необходимости, но вот вам пример, в котором CLR дается указание проверить подкаталоги клиента MyLibraries и MyLibraries\Tests.

    ‹probing privatePath="MyLibraries; MyLibraries\Tests"/›

    После создания CSharpCarClient.exe.config выполните приложение-клиент с помощью двойного щелчка на выполняемом файле в программе Проводник Windows. Вы должны обнаружить, что теперь CSharpCarClient.exe выполняется без проблем (если это не так, проверьте введенные данные на отсутствие опечаток).

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

    Файлы конфигурации и Visual Studio 2005

    Вы, конечно, можете всегда создавать XML-файлы конфигурации вручную с помощью своего любимого текстового редактора, но Visual Studio 2005 позволяет создать файл конфигурации в процессе построения программы-клиента. Для примера загрузите в Visual Studio 2005 проект CSharpCarClient и добавьте в него новый элемент Application Configuration File (Файл конфигурации приложения), выбрав Project>Add New Item из меню. Перед тем как щелкнуть на кнопке ОК, обратите внимание на то, что файл получит название App.config (не переименовывайте его!). Если после этого заглянуть в окно Solution Explorer (Обозреватель решений), то вы увидите, что в текущий проект добавлен файл App.config (см. рис. 11.12).

    Рис. 11.12. Файл App.config в Visual Studio 2005

    После этого вы сможете ввести все необходимые XML-элементы для создаваемого клиента. И здесь следует отметать кое-что действительно интересное. Каждый раз при компиляции проекта Visual Studio 2005 будет автоматически копировать данные App.config в каталог \Bin\Debug, назначая копии имя с учетом соответствующего соглашения о назначении имен (например, имя CSharpCarClient.exe.config). Однако это происходит только в том случае, когда файл конфигураций называется Арр.config. При этом вам придется поддерживать только App.config, a Visual Studio 2005 гарантирует, что каталог приложения будет содержать самые последние и самые полные данные (даже если вы, например, переименуете свой проект).

    Утилита конфигурации NET Framework 2.0

    Создание файлов *.config вручную не является слишком большой проблемой, но, тем не менее, .NET Framework 2.0 SDK предлагает инструмент, который позволяет строить XML-файлы конфигурации в рамках графического интерфейса пользователя. Утилиту Microsoft .NET Framework 2.0 Configuration можно найти в папке Администрирование, размещенной в панели управления Windows. Запустив этот инструмент, вы увидите ряд опций конфигурации (рис. 11.13).

    Рис 11.13. Утилита конфигурации .NET Framework 2.0 Configuration

    Чтобы построить файл *.config клиента с помощью этой утилиты, первым шагом должно быть добавление того приложения, которое будет конфигурироваться. Для этого щелчком правой кнопки мыши откройте контекстное меню узла Applications (Приложения) и выберите пункт Add (Добавить). В появившемся диалоговом окне вы можете обнаружить приложение для конфигурации при условии, что оно выполнялось ранее с помощью программы Проводник Windows. Если это не так, щелкните на кнопке Other (Другие) и зайдите в папку программы-клиента, которую вы хотите конфигурировать. Для данного примера следует выбрать приложение VbNetCarClient.exe, созданное в этой главе ранее (поищите его в папке Bin). После этого вы должны увидеть новый дочерний узел, как показано на рис. 11.14.

    Рис. 11.14. Подготовка к изменению конфигурации VbNetCarClient.exe

    Если щелкнуть правой кнопкой мыши на узле VbNetCarClient и активизировать пункт контекстного меню Свойства, то внизу появившегося диалогового окна вы увидите текстовое поле, где можно ввести значения, которые будут приписаны атрибуту privatePath. Просто для проверки введите имя подкаталога TestDir (рис. 11.15).

    Рис. 11.15. Указание приватного пути зондирования в рамках графического интерфейса

    После щелчка на кнопке ОК вы можете посмотреть в каталог VbNetCarClient\ Debug и убедиться, что в типовой файл *.сonfig (который Visual Studio 2005 создает для программ VB .NET) был добавлен нужный элемент ‹probing›.

    Замечание. Как вы можете догадаться сами, XML-содержимое, сгенерированное утилитой конфигурации .NET Framework 2.0, можно скопировать в файл App.config Visual Studio 2005 для дальнейшего редактирования. Позволяя инструментам автоматизации генерировать начальное содержимое, вы, очевидно, уменьшаете для себя объем вводимого с клавиатуры текста.

    Общедоступные компоновочные блоки

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

    Так, многие приложения в этой книге указывают ссылку на System.Windows.Forms.dll. Но если заглянуть в каталоги этих приложений, вы не обнаружите там приватные копии этого компоновочного блока .NET. Причина в том, что System.Windows.Forms.dll инсталлируется, как общедоступный компоновочный блок. Очевидно, что именно такой подход нужна использовать при создании библиотеки классов, используемой на уровне всей машины.

    Общедоступный компоновочный блок не инсталлируется в каталог использующего его приложения. Общедоступные компоновочные блоки устанавливаются в GAC (Global Assembly Cache – глобальный кэш компоновочных блоков). Каталог GAC является подкаталогом с именем assembly в корневом каталоге Windows (например, C:\Windows\assembly), как показано на рис. 11.16.

    Рис. 11.16. Глобальный кэш компоновочных блоков

    Замечание. Выполняемые компоновочные блоки (*.exe) устанавливать в каталог GAC нельзя. Общедоступными компоновочными блоками могут быть только блоки, имеющие вид *.dll.

    Строгая форма имени

    Перед установкой компоновочного блока в GAC вы должны назначить компоновочному блоку строгое имя, которое уникальным образом идентифицирует издателя данного двоичного объекта .NET. При этом следует понимать, что "издателем" может быть и отдельный программист, и подразделение в рамках отдельной компании, и отдельная компания целиком.

    В некотором смысле строгое имя является современным .NET-эквивалентом схемы GUID-идентификации COM. Если вы имеете опыт работы с COM, вспомните о том, что AppID (идентификатор приложения) – это GUID (Globally Unique IDentifter – глобальный уникальный идентификатор), характеризующий конкретное COM-приложение. В отличие от GUID-значений в COM (которые являются ничем иным, как 128-разрядными числами), строгие имена создаются на основе двух связанных криптографических ключей (называемых открытым ключом и секретным ключом). Поэтому строгие имена оказываются гораздо более стойкими в отношении искажений и должны быть ближе к уникальности, чем простые GUID-значения.

    Формально строгое имя компонуется из набора связанных данных, в большинстве своем задаваемых следующими атрибутами уровня компоновочного блока.

    • Понятное имя компоновочного блока (которое, напоминаем, является именем компоновочного блока без расширения файла)

    • Номер версии компоновочного блока (назначаемый с помощью атрибута [AssemblyVersion])

    • Значение открытого ключа (назначаемое с помощью атрибута [AssemblyKeyFile])

    • Необязательное значение идентификатора культуры, используемого для локализации (назначаемое с помощью атрибута [AssemblyCulture])

    • Встроенная цифровая подпись, создаваемая с помощью хеширования всего содержимого компоновочного блока с использованием значения секретного ключа

    Чтобы создать строгое имя для компоновочного блока, вашим первым шагом должно быть генерирование пары ключей (открытого и секретного) с помощью утилиты sn.exe .NET Framework 2.0 SDK (что мы с вами сделаем чуть позже). Утилита sn.exe генерирует файл, обычно с расширением *.snk (Strong Name Key – ключ строгого имени), который содержит данные двух разных, но математически связанных ключей (это так называемые "открытый" и "секретный" ключи). Если компилятор C# получит информацию о месте нахождения файла *.snk, то во время компиляции значение открытого ключа будет записано в манифест создаваемого компоновочного блока с помощью лексемы .publickey.

    Компилятор C# также сгенерирует хешированный код на основе всего содержимого компоновочного блока (CIL-кода, метаданных и т.д.). Вы должны знать из главы 3, что хешированный код представляет собой числовое значение, уникальным образом характеризующее вводимые данные. Так, при изменении любой части компоновочного блока (даже одного-единственного символа строкового литерала) .NET-компилятор генерирует уже другой хешированный код. Этот хешированный код комбинируется с данными секретного ключа из файла *. snk для получения цифровой подписи, встраиваемой в CLR-заголовок компоновочного блока. Процесс создания строго именованного компоновочного блока схематически показан на рис. 11.17.

    Следует понимать, что данные секретного ключа нигде в манифесте представлены не будут – они используется только при создании цифровой подписи содержимого компоновочного блока (в совокупности с генерируемым хешированным кодом). Напомним, что основной целью применения криптографии на основе открытого и секретного ключей является гарантия того, что во "вселенной" .NET никакая пара компаний, подразделений или индивидуумов не получит одинаковых идентификаторов. Так или иначе, по завершении процесса создания строгого имени компоновочный блок можно будет установить в структуру GAC.

    Рис. 11.17. В процессе компиляции на основе открытого и секретного ключей генерируется цифровая подпись, которая затем встраивается в компоновочный блок

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

    Создание строгого имени для CarLibrary.dll

    Давайте продемонстрируем весь процесс назначения строгого имени компоновочному блоку CarLibrary, созданному в этой главе выше. Откройте соответствующий проект в той среде разработки, которую вы предпочитаете использовать. Первым делом нужно сгенерировать необходимые данные ключей с помощью утилиты sn.exe. Этот инструмент имеет множество опций командной строки, но нам сейчас понадобится только флаг -k, который дает команду генерировать новый файл, содержащий информацию открытого и секретного ключей. Создайте новую папку MyTestKeyPair на своем диске C и перейдите в нее в окне командной строки .NET. После этого, чтобы сгенерировать файл MyTestKeyPair.snk, введите следующую команду.

    sn -k MyTestKeyPair.snk

    Теперь, получив данные своего ключа, сообщите компилятору C# о том, где размещается файл MyTestKeyPair.snk. Обратите внимание на то, что при создании рабочего пространства для любого нового проекта C# в Visual Studio 2005 один из исходных файлов проекта получает имя AssemblyInfo.cs (он размещается в рамках узла Properties в окне Solution Explorer). Этот файл содержит ряд свойств, описывающих компоновочный блок. Атрибут AssemblyKeyFile уровня компоновочного блока можно использовать для информирования компилятора о месте расположения файла *.snk. Просто укажите путь в виде строкового параметра, например:

    [assembly: AssemblyKeyFile (@"C:\MyTestKeyPair\MyTestKeyPair.snk".)]

    Поскольку одной из составляющих строгого имени общедоступного компоновочного блока является идентификатор версии, мы укажем его и для CarLibrary.dll. В файле AssemblyInfo.cs найдите другое свойство, имя которого AssemblyVersion. Изначально его значением является 1.0.*.

    [assembly: AssemblyVersion("1.0.*")]

    Напомним, что идентификатор версии .NET компонуется из четырех числовых значений. По умолчанию Visual Studio 2005 автоматически будет выполнять приращение номеров компоновки и варианта (что обозначается групповым символом "*") при каждой компиляции. Чтобы установить фиксированное значение идентификатора версии для компоновочного блока, замените групповой символ конкретными значениями номера компоновки и варианта.

    // Формат номера версии;

    // ‹главный›.‹дополнительный›.‹компоновка›.‹вариант›

    // Для каждого элемента допустимы значения от 0 до 65535.

    [.assembly: AssemblyVersion ("1.0.0.0")]

    Теперь компилятор C# имеет всю информацию, необходимую для генерирования данных строгого имени (поскольку вы не указали уникального значения для параметра локализации с помощью атрибута [AssemblyCulture], будут "унаследованы" текущие параметры локализации вашей машины). Выполните компиляцию библиотеки программного кода CarLibrary и с помощью ildasm.exe откройте ее манифест. Вы увидите, что в нем теперь используется лексема .publickey, с помощью которой документируется информация открытого ключа, а с помощью.ver представлен номер версии, указанный атрибутом [AssemblyVersion] (рис. 11.18).

    Рис. 11.18. Строго именованный компоновочный блок записывает открытый ключ в манифест

    Назначение строгого имени в Visual Studio 2005

    Перед тем как установить CarLibrary.dll в структуру GAC, заметим, что Visual Studio 2005 позволяет указать место расположения файла *.snk на странице Properties (Свойства) проекта (в Visual Studio 2005 такой подход оказывается более предпочтительным, поскольку при использовании атрибута [AssemblyKeyFile] генерируется предупреждение компилятора). Выберите вкладку Signing (Подписи) и, указав путь к файлу *.snk, установите флажок Sign the assembly (Подписать компоновочный блок), как показана на рис. 11.19.

    Рис. 11.19. Информация о файле *.snk на странице свойств проекта

    Установка и удаление общедоступных компоновочных блоков

    Заключительным шагом будет установка (теперь уже строго именованной) библиотеки CarLibrary.dll в структуру GAC. Проще всего установить общедоступный компоновочный блок в структуру GAС, перетащив файл компоновочного блока с помощью мыши в папку C:\Windows\assembly в программе Проводник Windows (это очень удобно при тестировании).

    Кроме этого, .NET Framework 2.0 SDK предлагает утилиту командной строки gacutil.exe, которая позволяет просматривать изменять содержимое GAC. В табл. 11.1 показаны некоторые опции gacutil.exe (используйте флаг /?, чтобы увидеть все опции),

    Таблица 11.1. Опции gacutil.exe

    Опция Описание
    /i Устанавливает строго именованный компоновочный блок в структуру GAC
    /u Удаляет компоновочный блок из структуры GAC
    /l Отображает компоновочные блоки (или конкретный компоновочный блок) в структуре GAC

    Используя любой из указанных подходов, установите CarLibrary.dll в структуру GAC. После этого вы должны увидеть, что ваша библиотека в структуре присутствует и учитывается (рис. 11.20).

    Рис. 11.20. Строго именованная общедоступная библиотека CarLibrary (версия 1.0.0.0)

    Замечание. При щелчке правой кнопкой мыши на пиктограмме любого компоновочного блока открывается контекстное меню, с помощью которого можно открыть страницу свойств компоновочного блока или деинсталлировать соответствующую версию (это эквивалентно использования флага /u с утилитой gacutil.exe).

    Отложенная подпись

    При создании своих собственных компоновочных блоков .NET вы можете назначать строгие имена, используя свой персональный файл *.snk. Но ваша компания или подразделение могут отказать вам в доступе к главному файлу *. snk. Ввиду исключительной важности файла, содержащего открытый и секретный ключи, этому удивляться не следует, но это, очевидно, является проблемой, поскольку у вас (как у разработчика) будет часто возникать необходимость установки компоновочных блоков в структуру GAC с целью тестирования. Чтобы позволить такое тестирование без предоставления настоящего файла *.snk, вы можете использовать метод отложенной подписи. В случае с файлом CarLibrary.dll в использовании такого подхода нет никакой необходимости, но мы все же предоставим краткое описание соответствующей процедуры.

    Процедура отложенной подписи начинается правомочным лицом, имеющим доступ к файлу *.snk, с извлечения из этого файла значения открытого ключа. Для этого используется sn.exe с опцией -р, позволяющей создать новый файл, содержащий значение открытого ключа.

    sn -p myKey.snk testPublicKey.snk

    Файл testPublicKey.snk можно предоставить всем разработчикам для создания и проверки строго именованных компоновочных блоков. Чтобы сообщить компилятору C# о том, что соответствующий компоновочный блок должен использовать процедуру отложенной подписи, разработчик должен установить для атрибута AssemblyDelaySign значение true (истина), а также указать файл с псевдоключом, как параметр атрибута AssemblyKeyFile. Ниже показаны строки, которые следует ввести в файл AssemblyInfo.cs проекта.

    [assembly: AssemblyDelaySign(true)]

    [assembly: AssemblyKeyFile(@"C:\MyKey\testPublicKey.snk)]

    Замечание. При использовании Visual Studio 2005 те же атрибуты можно создать "визуально", используя возможности, предлагаемые на странице свойств проекта.

    После разрешения отложенной подписи для компоновочного блока следующим шагом является отключение процесса проверки подписи, который для компоновочных блоков, установленных в GAC, выполняется автоматически. Чтобы пропустить процесс проверки подписи на текущей машине, укажите (для sn.exe) опцию -vr.

    sn.exe -vr MyAssembly.dll

    По завершении тестирования компоновочный блок можно отправить уполномоченному объекту, имеющему доступ к настоящему файлу с открытым и секретным ключами, чтобы обеспечить двоичному файлу настоящую цифровую подпись. Здесь снова необходимое решение обеспечивает sn.exe, на этот раз при использовании флата -r.

    sn.exe -r MyAssembly.dll C:\MyKey\myKey.snk

    Чтобы в заключение активизировать процесс проверки подписи, применяется флаг -vu.

    sn.exe -vu MyAssembly.dll

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

    Использование общедоступных компоновочных блоков

    При построении приложений, использующих общедоступные компоновочные блоки, единственное отличие от случая использования приватного компоновочного блока заключается в том, как вы ссылаетесь на соответствующую библиотеку в Visual Studio 2005. Фактически с точки зрения используемого инструмента никакой разницы нет (вы все равно используете диалоговое окно Add Reference). Важно понять то, что это диалоговое окно не позволит вам сослаться на компоновочный блок путем просмотра папки assembly. Попытки сделать это будут бесполезными – возможность сослаться на выделенный компоновочный блок предоставлена не будет (рис. 11.21).

    Рис. 11.21. Неправильно! Visual Studio 2005 не позволяет сослаться на общедоступный компоновочный блок путем перехода в папку assembly

    Вместо этого на вкладке Browse нужно перейти в каталог \Bin\Debug оригинального проекта (рис. 11.22).

    Рис. 11.22. Правильно! В Visual Studio 2005 для ссылки на общедоступный компоновочный блок нужно перейти в каталог \Bin\Debug соответствующего проекта

    Учитывая этот (раздражающий) факт, создайте новое консольное приложение C# с именем SharedCarLibClient и проверьте возможность использования своих типов.

    using CarLibrary;

    namespace.SharedCarLibClient {

     class Program {

     static void Main(string[] args) {

      SportsCar c = new SportsCar();

      Console.ReadLine();

      }

     }

    }

    После компиляции приложения-клиента, в программе Проводник Windows перейдите в каталог, содержащий файл SharedCarLibClient.exe, и убедитесь в том, что Visual Studio 2006 не скопировала CarLibrary.dll в каталог приложения-клиента. При ссылке на компоновочный блок, манифест которого содержит значение .publickey, Visual Studio 2005 предполагает, что строго именованный компоновочный блок, вероятнее всего, установлен в структуре GAC и поэтому не "утруждает" себя копированием двоичного файла.

    Pиc. 11.23. С помощью свойства Copy Local можно "заставить" систему выполнить копирование строго именованной библиотеки программного кода

    В качестве краткого замечания укажем на то, что можно "заставить" Visual Studio 2005 скопировать общедоступный компоновочный блок в каталог клиента. Для этого нужно выбрать компоновочный блок из узла References в окне Solution Explorer, а затем в окне Properties (рис. 11.23) установить для свойства Copy Local (копировать в локальную папку) значение True (истина) вместо значения False (ложь).

    Анализ манифеста SharedCarLibClient

    Напомним, что при генерировании строгого имени компоновочного блока в манифест компоновочного блока записывается значение открытого ключа. Точно так же, когда клиент ссылается на строго именованный компоновочный блок, в его манифест записывается "конденсированное" хешированное значение открытого ключа, обозначенное лексемой .publickey. Если с помощью ildasm.exe открыть манифест SharedCarLibClient.exe, вы увидите там следующее.

    .assembly extern CarLibrary {

     .publickeytoken = (21 9E F3 80 C9 34 8A 38)

     .ver 1:0:0:0

    }

    Если сравнить код открытого ключа, записанный в манифесте клиента со значением для открытого ключа, показанным структурой GAC, вы обнаружите полное совпадение. Напомним, что открытый ключ является одной из составляющих строгого имени, идентифицирующего компоновочный блок. С учетом этого среда CLR загрузит только версию 1.0.0.0 компоновочного блока CarLibrary, открытый ключ которого имеет хешированное значение 219EF380C9348A38. Если среда CLR не найдет компоновочный блок, имеющий такое описание в рамках GAC (и не найдет приватного компоновочного блока с именем CarLibrary в каталоге клиента), то будет сгенерировано исключение FileNotFound (файл не найден).

    Исходный код. Проект SharedCarLibClient размещен в подкаталога, соответствующем главе 11.

    Конфигурация общедоступных компоновочных блоков

    Подобно приватным компоновочным блокам, открытый компоновочный блок можно конфигурировать с помощью файла *.config клиента. Конечно, ввиду того, что открытые компоновочные блоки находятся по известному адресу (в структуре GAC), для них не указывается элемент ‹privatePath›, как это делается для приватных компоновочных блоков (хотя, если клиент использует как общедоступные, так и приватные компоновочные блоки, элемент ‹privatePath› в файле *.config может присутствовать).

    Файлы конфигурации приложения можно использовать в совокупности с общедоступными компоновочными блоками для того, чтобы дать указание среде CLR выполнить привязку к другой версии конкретного компоновочного блока, т.е. чтобы обойти значение, записанное в манифест клиента. Это может понадобиться по целому ряду причин. Например, представьте себе, что вами была выпущена версия 1.0.0.0 компоновочного блока, а через некоторое время вы обнаружили в ней дефект. Одной из возможностей исправления ситуации может быть перекомпоновка приложения-клиента, чтобы оно ссылалось на новую версию компоновочного блока (скажем, 1.1.0.0). свободную от дефекта, и переустановка обновленного клиента и новой библиотеки на всех соответствующих машинах.

    Другим вариантом является поставка новой библиотеки программного кода с файлом *.config, который автоматически даст среде выполнения инструкцию по привязке к новой версий (свободной от соответствующего дефекта). После установки новой версии библиотеки в структуру GAC оригинальный клиент сможет работать без повторной компиляции и переустановки, а вы не будете опасаться за свою репутацию.

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

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

    Фиксация версии общедоступного компоновочного блока

    Чтобы показать, как осуществляется динамическая привязка к конкретной версии общедоступного компоновочного блока, откроите программу Проводник Windows в скопируйте текущую версию CarLibrary (1.0.0.0) в другой подкаталог (здесь для него выбрано название "Версия 1") корневой папки проекта, чтобы зафиксировать эту версию (рис. 11.24).

    Рис. 11.24. Фиксация текущей версии CarLibrary dll

    Создание общедоступного компоновочного блока версии 2.0.0.0

    Теперь обновите свой проект CarLibrary, добавив в него определение нового перечня MusicMedia, определяющего четыре возможных музыкальных устройства.

    // Содержит информацию об источнике музыки.

    public enum MusicMedia {

     musicCd,

     musicTape,

     musicRadio,

     musicMp3

    }

    Также добавьте для типа Car новый открытый метод, который позволит вызывающей стороне включить один из имеющихся проигрывателей.

    public abstract class Car {

     …

     public void TurnOnRadio(bool musicOn, MusicMedia mm) {

      if (musicOn) MessageBox.Show(string.Format("Шум {0}", mm));

      else MessageBox.Show("И тишина…");

     }

     …

    }

    Измените конструкторы класса Car, чтобы отображалось окно MessageBox, в котором подтверждается использование CarLibrary именно версии 2.0.0.0.

    public abstract class Car {

     …

     public Car() {

      MessageBox.Show("Car 2.0.0.0");

     }

     public Car(string name, short max, short curr) {

      MessageBox.Show("Car 2.0.0.0");

      petName = name; maxSpeed = max; currSpeed = curr;

     }

     …

    }

    Наконец, до начала новой компиляции не забудьте изменить значение версии этого компоновочного блока на 2.0.0.0 с помощью изменения значения, передаваемого атрибуту [AssemblyVersion].

    // CarLibrary версии 2.0.0.0 (теперь с музыкой!).

    [assembly: Assembly-Version("2.0.0.0"]

    Если вы теперь заглянете в папку \Bin\Debug проекта, то увидите, что там присутствует новая версия компоновочного блока (2.0.0.0), в то время как версия 1.0.0.0 в полной безопасности хранится в подкаталоге Версия 1. Установите этот новый компоновочный блок в папку GAC в соответствии с инструкциями, предложенными в этой главе выше. Обратите внимание на то, что теперь вы будете иметь две версии одного и того же компоновочного блока (рис. 11.25).

    Рис. 11.25. Параллельное выполнение

    Если теперь в программе Проводник Windows выполнить имеющуюся программу SharedCarLibClient.exe с помощью двойного щелчка на ее пиктограмме, вы не увидите окно с сообщением "Саr 2.0.0.0", поскольку соответствующий манифест специально запрашивает версию 1.0.0.0. Так как же тогда дать указание среде CLR о том, чтобы среда выполнила привязку к версии 2.0.0.0? Я рад, что вы об этом спрашиваете.

    Динамическая привязка к конкретной версии компоновочного блока

    Для того чтобы среда CLR загружала общедоступный компоновочный блок определенной версии, отличной от той версии, которая указана в манифесте компоновочного блока, следует создать файл *.config с элементом ‹dependentAssembly› внутри. В рамках этого элемента нужно задать элемент ‹assemblyIdentity›, который укажет понятное имя компоновочного блока из соответствующего манифеста клиента (в нашем примере это CarLibrary) и, возможно, необязательное значение атрибута culture (ему можно назначить пустую строку, а можно вообще опустить, если предполагается использовать параметры, предусмотренные для данной машины по умолчанию). Кроме того, в рамках элемента ‹dependentAssembly› следует задать элемент ‹bindingRedirect›, указывающий версию, которая задана в манифесте в настоящий момент (атрибут oldVersion), и версию из структуры GAC, которую нужно загружать вместо версии, указанной в манифесте (атрибут newVersion).

    В каталоге приложения SharedCarLibClient создайте новый файл конфигурации SharedCarLibClient.exe.config и поместите в него следующие XML-данные. Конечно, значение вашего открытого ключа будет отличаться от того, которое содержится в показанном ниже примере программного кода, но это значение вы можете выяснить путем просмотра манифеста клиента с помощью ildasm.exe или в структуре GAC.

    ‹configuration›

     ‹runtime›

      ‹assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"›

       ‹dependentAssembly›

        ‹assemblyIdentity name="CarLibrary" publicKeyToken="191ebf55656e0a43" culture="/›

        ‹bindingRedirect oldVersion= "1.0.0.0" newVersion= "2.0.0.0"/›

       ‹/dependentAssembly›

      ‹/assemblyBinding›

     ‹/runtime›

    ‹/configuration›

    Снова выполните программу SharedCarLibClient.exe. Вы должны увидеть сообщение о том, что загружена версия 2.0.0.0. Если же для атрибута newVersion вы укажете значение 1.0.0.0 (или просто удалите файл *.config), будет загружена версия 1.0.0.0. поскольку среда CLR найдет в манифесте клиента указание о том, что необходимо использовать версию 1.0.0.0.

    В файле конфигурации клиента может присутствовать несколько элементов ‹dependentAssembly›. В нашем случае никакой необходимости в этом нет, но предположим, что манифест SharedCarLibClient.exe ссылается также на общедоступный компоновочный блок MathLibrary версии 2.6.0.0. Если вы захотите перенаправить клиент на использование MathLibrary версии 3.0.0.0 (вдобавок к использованию CarLibrary версии 2.0.0.0), то в этом случае файл SharedCarLibClient.exe.config должен выглядеть так.

    ‹configuration›

     ‹runtime›

      ‹assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"›

       ‹dependentAssembly›

        ‹assemblyIdentity name="CarLibrary" publicKeyToken="191ebf55656e0a43" culture="/›

        ‹bindingRedirect oldVersion= "1.0.0.0" newVersion= "2.0.0.0"/›

       ‹/dependentAssembly›

       ‹dependentAssembly›

        ‹assemblyIdentity name="MathLibrary" publicKeyToken="191ebf55656e0a43" culture="/›

        ‹bindingRedirect oldVersion="2.5.0.0" newVersion= "3.0.0.0"/›

       ‹/dependentAssembly›

      ‹/assemblyBinding›

     ‹/runtime›

    ‹/configuration›

    Снова об утилите конфигурации .NET Framework 2.0

    Вы вправе надеяться, что должна быть какая-то возможность генерирования файлов *.config общедоступных компоновочных блоков с помощью средств графического интерфейса утилиты .NET Framework 2.0 Configuration. Подобно построению файла *.сonfig для приватных компоновочных блоков, первый шагом здесь является ссылка на соответствующий файл *.exe, для которого выполняется конфигурация. Для примера удалите только что созданный вами файл SharedCarLibClient.exe.config. Теперь в окне утилиты .NET Framework 2.0 Configuration добавьте ссылку на SharedCarLibClient.exe, щелкнув правой кнопкой мыши в строке узла Applications (Приложения). Затем раскройте пиктограмму (+) и выберите подузел Configured Assemblies (Сконфигурированные компоновочные блоки). После этого щелкните на ссылке Configure an Assembly (Сконфигурировать компоновочный блок) в правой части окна утилиты.

    Вы увидите диалоговое окно, которое позволит вам создать элемент ‹dependentAssembly› с помощью ряда элементов графического интерфейса. Сначала с помощью кнопки переключателя выберите Choose an assembly from the list of assemblies this application uses (Выбрать компоновочный блок из списка компоновочных блоков, используемых данным приложением), что, по сути, означает требование показать манифест. Затем щелкните на кнопке Choose Assembly (Выбрать компоновочный блок).

    Появившееся диалоговое окно отобразит не только компоновочные блоки, явно указанные в манифесте клиента, но и компоновочные блоки, на которые указанные компоновочные блоки ссылаются. Для нашего примера выберите CarLibrary. После щелчка на кнопке Finish (Готово) будет показана страница свойств для выбранного объекта манифеста клиента. Там, используя возможности вкладки Binding Policy (Политика привязки ресурсов), вы сможете сгенерировать ‹dependentAssembly›.

    На вкладке Binding Policy вы можете установить значения атрибута oldVersion (укажите 1.0.0.0) в текстовом поле Requested Version (Запрошенная версия) и атрибута newVersion (2.0.0.0) текстовом поле New Version (Новая версия). После ввода указанных параметров, вы обнаружите следующий файл конфигурации, сгенерированный для вас системой.

    ‹?xml version="1.0"?›

    ‹configuration›

     ‹runtime›

      ‹assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"›

       ‹dependentAssembly›

        ‹assemblyIdentity name="CarLibrary" publicKeyToken="l91ebf55656e0a43" /›

        ‹publisherPolicy аррlу="yes" /›

        ‹bindingRedirect oldVersion= "1.0.0.0" newVersion="2.0.0.0" /›

       ‹/dependentAssembly›

      ‹/assemblyBinding›

     ‹/runtime›

    ‹/configuration›

    Анализ внутренней структуры GAC

    Итак, все работает. Теперь давайте посмотрим на внутреннюю структуру GAC. При просмотре папки GAG в программе Проводник Windows вы видите ряд пиктограмм, изображающих каждый из общедоступных компоновочных блоков всех имеющихся версий. Эта графическая оболочка обеспечивается COM-сервером shfusion.dll. Но, как вы можете подозревать, за этими пиктограммами должна скрываться сложная (хотя и вполне логичная) структура каталогов.

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

    cd c:\windows\assembly

    Выберите в командной строке команду dir. В этом каталоге, среди прочего, вы обнаружите папку с названием GAC_MISL (рис. 11.26).

    Рис. 11.26. Скрытый подкаталог GAC_MSIL

    Перейдите в каталог GAC_MSIL и снова выберите команду dir. Теперь вы увидите список подкаталогов, которые имеют в точности такие же имена, как и пиктограммы, отображаемые сервером shfusion.dll. Перейдите в подкаталог CarLibrary и снова выберите команду dir (рис. 11.27).

    Рис. 11.27. Внутри скрытого подкаталога CarLibrary

    Как видите, в структуре GAC для каждой версии общедоступного компоновочного блока создается свой подкаталог, имя которого выбирается по правилу ‹версияКомпоновочногоБлока›__кодОткрытогоКлюча. Если из текущего каталога вы перейдете в каталог CarLibrarу версии 1.0.0.0, то обнаружите там копию соответствующей библиотеки программного кода (рис .11.28).

    Рис. 11.28. Смотрите! Внутренняя копия GAC библиотеки CarLibrary.dll!

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

    Файлы политики публикации компоновочных блоков

    Следующий вопрос, который мы должны рассмотреть в рамках обсуждения возможностей конфигурации, это роль политики публикации компоновочных блоков. Вы только что убедились, что с помощью файлов *.config можно выполнить привязку к конкретной версии общедоступного компоновочного блока в обход версии, указанной в манифесте клиента. Все это просто прекрасно, но представьте себе, что вы являетесь администратором, которому придется переконфигурировать все приложения клиента на данной машине так, чтобы эти приложения использовали компоновочный блок CarLibrary.dll версии 2.0.0.0. Ввиду принятого соглашения для имен файлов конфигурации, вам придется многократно копировать одно и то же XML-содержимое во множество мест (еще и предполагается, что вы должны знать, где находятся все файлы, использующие CarLibrary!). Очевидно, что для администратора это будет просто кошмаром.

    Политика публикации позволяет "издателю" данного компоновочного блока (вам, вашему подразделению, вашей компании или другому конкретному поставщику) предложить бинарную версию файла *.config, которая устанавливается в структуру GAC вместе с новейшей версией соответствующе-то компоновочного блока. Преимущество такого подхода в том, что тогда отпадает необходимость в наличии специальных файлов *.config в каталогах приложений клиента. Среда CLR читает текущий манифест и пытается найти запрошенную версию в структуре GAC. Но если при этом среда CLR обнаруживает файл политики публикации, читаются встроенные в этот файл XML-данные и выполняется соответствующее перенаправление на уровне GAC.

    Файлы политики публикации создаются средствами командной строки с помощью .NET-утилиты al.exe (это редактор связей компоновочного блока). Этот инструмент имеет очень много опций, но для построения файла политики публикации потребуются указать только следующие данные:

    • информацию о размещении файла *.config или *.xml, содержащего инструкции перенаправления;

    • имя файла, задающего новые параметры политики публикации;

    • информацию о размещении файла *.snk, используемого для создания подписи файла политики публикации;

    • номера версии, назначаемой создаваемому файлу политики публикации.

    Чтобы построить файл политики публикации, контролирующий библиотеку CarLibrary.dll, нужно использовать следующую команду.

    al /link: CarLibraryPolicy.xml /out:policy.1.0.CarLibrary.dll /keyf: C:\MyKey\myKey.snk /v:1.0.0.0

    Здесь XML-содержимое включено в файл с именем CarLibraryPolicy.xml. Имя выходного файла, которое должно иметь формат policy.‹главный(номер версии)›. ‹дополнителъный(номер версии)›.конфигурируемыйКомпоновочныйБлок), указывается с помощью флага /out. Обратите также внимание на то, что имя файла, содержащего значения открытого и секретного ключей, тоже должно быть представлено, но с помощью опции /keyf. (Поскольку файлы политики публикации являются общедоступными, они должны быть строго именованными.)

    В результате использования al.exe вы получите новый компоновочный блок, который можно разместить в структуре GAC для того, чтобы, не используя отдельные файлы конфигурации для каждого приложения, "заставить" все клиенты использовать CarLibrary.dll версии 2.0.0.0.

    Игнорирование файла политики публикации

    Теперь предположим, что вы (как администратор системы) установили файл политики публикации (и новую, более позднюю версию компоновочного блока) на машине клиента. Как обычно и случается, девять из десяти соответствующих приложений перешли к использованию версии 2.0.0.0 без всяких ошибок. Однако в одном из приложений клиента при доступе к CarLibrary.dll версии 2.0.0.0 возникли проблемы (мы с вами знаем, что создать программное обеспечение, которое будет демонстрировать 100%-ную обратную совместимость, практически невозможно).

    В таком случае можно построить файл конфигурации для данного "проблемного" клиента с инструкциями, которые позволят среде CLR игнорировать установленные в GAC файлы политики публикации. При этом другие приложения клиента, которые могут использовать новый компоновочный блок .NET, с помощью установленного файла политики публикации будут перенаправлены на новый компоновочный блок. Чтобы отключить политику публикации для отдельного клиента, создайте файл *.сonfig (с подходящим именем), в котором рамках элемента ‹publisherPolicy› установите для атрибута apply значение no. После этого среда CLR будет загружать компоновочный блок той версии, которая указана в манифесте клиента.

    ‹configuratоn›

     ‹runtime›

      ‹assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"›

       ‹publisherPolicy apply="no" /›

      ‹/assemblуВinding›

     ‹/runtime›

    ‹/configuration›

    Элемент ‹codeBase›

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

    Замечание. Если значение, присвоенное в рамках элемента ‹codeBase›, указывает на удаленную машину, компоновочный блок будет загружен по требованию в специальный каталог структуры GAC, имеющий специальное название – кэш загрузки. Увидеть содержимое кэша загрузки можно с помощью gacutil.exe, указав при запуске этой утилиты опцию /ldl.

    С учетом того, что вы уже знаете об установке компоновочных блоков в GAC, будет ясно, что компоновочные блоки, загружаемые с помощью элемента ‹codeBase›, должны быть строго именованными (в конце концов, как же иначе среда CLR смогла бы установить удаленные компоновочные блоки в структуру GAC?).

    Замечание. Строго говоря, элемент ‹codeBase› можно использовать и для зондирования компоновочных блоков, которые не являются строго именованными. Однако в таком случае адрес компоновочного блока должен задаваться относительно каталога приложения клиента (в этом отношении данный элемент предлагает более широкие возможности, чем элемент ‹privatePath›).

    Создайте консольное приложение с именем СodeBaseСlient, установите для него ссылку на CarLibrary.dll версии 2.0.0.0 и измените исходный файл так.

    using CarLibrary;

    namespace CodeBaseClient {

     class Program {

      static void Main(string[] args) {

       Console.WriteLine("***** Забавы с CodeBase *****");

       SportsCar с = new SportsCar();

       Console.WriteLine("Создана спортивная машина.");

       Console.ReadLine();

      }

     }

    }

    Поскольку библиотека CarLibrary.dll была установлена в структуру GAC, вы уже можете выполнить программу. Но для демонстрации применения элемента ‹codeBase› создайте новую папку на своем диске C (например, папку C:\MyAsms) и поместите в эту папку копию CarLibrary.dll версии 2.0.0.0.

    Теперь добавьте в проект CodeBaseClient файл App.config (в соответствии с инструкциями, предложенными в этой главе выше) и добавьте в этот файл следующее XML-содержимое (не забывайте о том, что ваше значение .publickeytoken будет другим, и вы можете выяснить его в структуре GAC).

    ‹configuration›

     ‹runtime›

      ‹assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"›

       ‹dependentAssembly›

        ‹assemblyIdentity name="SharedAssembly" publicKeyToken="191ebf55656e0a43." /›

         ‹codeBase version="2.0.0.0" href="href="file:///C:\MyAsms\CarLibrary.dll" />

       </dependentAssembly>

      </assemblyBinding>

     </runtime>

    </configuration>

    Как видите, элемент <codeBase> вложен в элемент <assemblyIdentity>, ис­пользующий атрибуты name и publicKeyToken для указания понятного имени компоновочного блока и соответствующего кода открытого ключа. Сам элемент <codeBase> указывает версию и (с помощью атрибута href) адрес загружаемого компоновочного блока. Если вы удалите CarLibrary.dll версии 2.0.0.0 из струк­туры GAC, этот клиент все равно будет выполняться успешно, поскольку среда CLR сможет найти внешний компоновочный блок в C:\MyAsms.

    Однако если вы удалите каталог MyAsms со своей машины, то клиент работать не сможет. Очевидно, что элементы <codeBase> (если таковые присутствуют) име­ют преимущество по сравнению с проверкой GAC.

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

    Элемент <codeBase> может оказаться полезным при ссылках на компоновоч­ные блоки, размещенные в сети на удаленной машине. Предположим, что у нас есть доступ к папке, размещенной по адресу http://www.intertechTraining.com. В таком случае для загрузки удаленного файла *.dll в кэш загрузки GAC на ло­кальной машине следует изменить элемент <codeBase> так.

    <codeBase version="2.0.0.0" href="http://www.IntertechTraining.com/Assemblies/CarLibrary.dll"  />

    Исходный код. Проект CodeBaseClient размещен в подкаталоге, соответствующем главе 11.

    Пространство имен System.Configuration

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

    Пространство имен Sуstem.Configuration определяет небольшой набор типов, которые можно использовать для чтения пользовательских установок из файла *.config клиента. Эти пользовательские установки должны задаваться в контексте элемента <appSettings>. Элемент <appSettings> может содержать произвольное числа элементов <add>, определяющих пары ключей и значений, которые могут извлекаться программными средствами.

    Предположим, что у нас есть файл *.сonfig дата консольного приложения AppConfigReaderApp, в котором определяется строка связи с базой данных и ука­затель на данные timesToSayHello.

    <configuration>

     <appSettings>

      <add key="AppConStr" value="server=localhost;uid='sa';pwd='';database=Cars" />

      <add key="timeToSayHello" value="8" />

     </appSettings>

    </сonfiguration>

    Чтение этих значений для использования приложением клиента осуществляет­ся простым вызовом метода экземпляра GetValue() типа System.Configuration. AppSettingsReader. Как показывает следующий пример программного кода, пер­вый параметр: GetValue() задает имя ключа в файле *.config, а второй параметр представляет соответствующий тип ключа (получаемый в C# в результате применении операции typeof).

    class Program {

     static void Main(string[] args) {

      // Создание средства чтения и получение строки соединения.

      AppSettingsReader ar = new AppSettingsReader();

      Console.WriteLine(ar.GetValue("appConstr", typeof(string)));

      // Получение числа повторений приветствия и выполнение.

      int numbOfTimes = (int)ar.GetValue("timesToSayHello", typeof(int));

      for (int i = 0; i ‹ numbOfTimes; i++) Console.WriteLine("Йо!");

      Console.ReadLine();

     }

    }

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

    Замечание. В ходе нашего обсуждения ADO.NET (см. главу 22) вы узнаете об элементе конфигурации ‹connectionStrings› и о других типах пространства имен System.Configuration. Эти элементы, появившиеся в .NET 2.0, предлагают стандартный метод обработки строк соединений.

    Исходный код. Проект AppConfigReaderApp размещен в подкаталоге, соответствующем главе 11.

    Файл конфигурации машины

    Файлы конфигурации, которые мы с вами рассмотрели в этой главе, имеют одно общее свойство: они относятся к конкретному приложению (вот почему они имеют то же имя, что и соответствующее приложение). Но каждая поддерживающая .NET машина имеет еще и файл, имеющий имя machine.config, который содержит множество параметров конфигурации для управления работой всей платформы .NET (многие из этих параметров не имеют ничего общего с разрешением ссылок на внешние компоновочные блоки).

    Платформа .NET использует файл *.config для каждой своей версии, установленной на локальной машине. Файл machine.config для .NET2.0 можно найти в каталоге C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIG (номер вашей версии может быть другим). Открыв указанный файл, вы увидите множество XML-элементов, задающих установки ASP.NET, различные параметры безопасности, поддержку отладки и т.д. Но если вы захотите добавить в файл machine.config (с помощью элемента ‹appSettings›) установки для приложений, применимые в рамках всей машины, вы можете сделать и это.

    Этот файл можно редактировать непосредственно, используя программу Блокнот, но следует иметь в виду, что при некорректном изменении этого файла вы можете нарушить работу среды выполнения. Ошибки в этом сценарии могут иметь гораздо более серьезные последствия, чем ошибки в файле *.config приложения, поскольку ошибки XML в файле конфигурации приложения влияют только на данное приложение, в то время как неправильный XML-код в файле machine.config может вообще блокировать работу конкретной версии .NET.

    Общая схема связей компоновочных блоков

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

    Рис. 11.29. Метод разрешения ссылок компоновочного блока в среде CLR

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

    Резюме

    Эта глава посвящена тому, как среда CLR разрешает ссылки на внешние компоновочные блоки. Глава начинается с рассмотрения содержимого компоновочного блока: заголовка, метаданных, манифеста и CIL-кода. Затем рассматриваются создание одномодульных и многомодульных компоновочных блоков, а также нескольких приложении клиента (на разных языках).

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

    ГЛАВА 12. Отображение типов, динамическое связывание и программирование с помощью атрибутов

    Как показано в предыдущей главе, компоновочные блоки являются базовыми элементами установки и среде .NET. С помощью интегрированного обозревателя объектов в Visual Studio 2005 можно рассмотреть открытые типы тех компоновочных блоков, на которые ссылается проект. Внешние средства, такие как ildasm.exe, позволяют увидеть соответствующий CIL-код, метаданные типов и содержимое манифеста компоновочного блока любого бинарного файла .NET, Вдобавок к этим возможностям, доступным во время проектирования компоновочного блока .NET, вы можете получить ту же информацию программными средствами, используя объекты пространства имен System.Reflection. В связи с этим мы выясним роль отображения типов и необходимость использования метаданных .NET.

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

    Метаданные типов

    Возможность полного описания типов (классов, интерфейсов, структур, перечней и делегатов) с помощью метаданных является главной особенностью платформы .NET. Многие .NET-технологии, такие как сериализация объектов, удаленное взаимодействие .NET и Web-сервисы XML, требуют, чтобы среда выполнения имела возможность выяснить форматы используемых типов. Возможности межъязыкового взаимодействия, поддержка компилятора и возможности IntelliSense среды разработки тоже зависят от конкретного описания типов.

    Важность метаданных очевидна и, возможно, именно поэтому они не являются новой идеей, предложенной в рамках .NET Framework. Технологии Java, CORBA и COM уже использовали аналогичные понятия. Например, для описания типов, содержащихся в серверах COM, используются библиотеки COM-типов (по сути, они представляют собой просто скомпилированный IDL-код). Как и COM, библиотеки программного кода .NET также поддерживают метаданные типов. Конечно, метаданные .NET синтаксически совершенно не похожи на IDL (Interface Definition Language – язык описания интерфейсов, используется в COM-технологиях для спецификации интерфейсов объектов COM). Напомним, что просматривать метаданные типов компоновочного блока позволяет утилита ildasm.exe (см. главу 1), Если вы откроете с помощью ildasm.exe любой компоновочный блок *.dll или *.exe, созданный вами в процессе изучения материала этой книги (например, CarLibrary.dll), и нажмете комбинацию клавиш ‹Ctrl+M›, то увидите соответствующие метаданные (рис. 12.1).

    Рис. 12.1. Просмотр метаданных компоновочного блока

    Как видите, ildasm.exe отображает метаданные .NET-типа очень подробно (двоичный формат оказывается гораздо более компактным). Если бы здесь потребовалось привести описание метаданных компоновочного блока CarLibrary.dll целиком, оно бы заняло несколько страниц. Это было бы лишней тратой вашего времени (и бумаги тоже), так что давайте рассмотрим метаданные только ключевых типов из компоновочного блока CarLibrary.dll.

    Анализ метаданных перечня EngineState

    Каждый тип, определенный в компоновочном блоке, обозначен маркером "TypeDef #n" (где TypeDef – это сокращение от type definition, что в переводе означает определение типа). Если описываемый тип использует тип, определённый в рамках другого компоновочного блока .NET, то для ссылки на такой тип используется "TypeRef #n" (где TypeRef – это сокращение от type reference, в переводе ссылка на тип). Если хотите, TypeRef можно считать указателем на полное определение метаданных соответствующего типа. По существу, метаданные .NET представляют собой множество таблиц, явно описывающих все определения типов (TypeDef) и все типы, на которые имеются ссылки (TypeRef). Все это можно увидеть в окне просмотра метаданных ildasm.exe.

    В случае CarLibrary.dll одно из описаний TypeDef в метаданных соответствуeт перечню CarLibrary.EngineState (у вac номер TypeDef может быть другим: нумерация TypeDef соответствует порядку, в котором компилятор C# обрабатывает соответствующие типы).

    TypeDef #1

    -------------------------------------------------------------

     TypDefName: CarLibrary.EngineState (020000002)

     Flags: [Public] [AutoLayout] [Class] [Sealed] [AnsiClass] (00000101)

     Extends: 01000001 [TypeRef] System.Enum

     Field #2

     -------------------------------------------------------------

     Field Маше: engineAlive (04000002)

     Flags: [Public] [Static] [Literal] [HasDefault] (00008056)

     DefltValue: (I4) 0

     CallCnvntn: [FIELD]

     Field type: ValueClass CarLibrary.EngineState

    Метка TypDefName используется для имени типа. Метка метаданных Extends используется для указания базового класса данного типа .NET (в данном случае это тип System.Enum, обозначенный как TypeRef). Каждое поле перечня обозначено меткой "Field #n". Для примера здесь представлены только метаданные поля EngineState.engineAlive.

    Анализ метаданных типа Car

    Вот часть дампа типа Car, которая иллюстрирует следующее:

    • способ определения полей в терминах метаданных .NET;

    • представление методов в метаданных .NET;

    • отображение свойства типа в пару специальных членов-функций.

    TypeDef #3

    -------------------------------------------------------------

     TypDefName: CarLibrary.Car (02000004)

     Flags: [Public] [AutoLayout] [Class] [Abstract] [AnsiClass] (00100081)

     Extends: 01000002 [TypeRef] System.Object

     Field #1

     -------------------------------------------------------------

      Field Name: petName (04000008)

      Flags: [Family] (00000004)

      CallCnvntn: [FIELD]

      Field type: String

     Method #1

     -------------------------------------------------------------

      MethodName:.ctor (06000001)

      Flags: [Public] [HideBySig] [ReuseSlot] [SpecialName] [RTSpecialName] [.ctor] (00001886)

      RVA: 0x00002050

      ImplFlags: [IL] [Managed] (00000000)

      CallCnvntn: [DEFAULT]

      hasThis

      ReturnType: Void

      No arguments.

     Property #1

     -------------------------------------------------------------

      Prop.Name: PetName (17000001)

      Flags: [none] (00000000)

      CallCnvntn: [PROPERTY]

      hasThis

      ReturnType: String

      No arguments.

      DefltValue:

      Setter: (06000004) set_PetName

      Getter: (06000003) get_PetName

      0 Others

    Прежде всего, отметьте то, что метаданные класса Car указывают базовый класс типа и включают различные флаги, использовавшиеся конструктором типа при его создании (такие как [public], [abstract] и т.п.). Методы (например, конструктор класса Car) описаны с учетом их имени, параметров и возвращаемого значения. Наконец, обратите внимание на то, что свойства представляются внутренними методами get_ /set_ с использованием меток Setter/Getter метаданных .NET. Как и следует ожидать, производные типы Car (это SportsCar и MiniVan) описываются аналогично.

    Анализ TypeRef

    Напомним, что метаданные компоновочного блока описывают не только множество внутренних типов (Car, EngineState и т.д.), но и внешние типы, на которые ссылается данный компоновочный блок. Например, поскольку CarLibrary.dll Определяет два перечня, в описании присутствует блок TypeRef для типа System.Enum.

    TypeRef #1 (01000001)

    -------------------------------------------------------------

    Token: 0x01000001

    ResolutionScope: 0x23000001

    TypeRefName: System.Enum

     MemberRef #1

     -------------------------------------------------------------

     Member: (0a00000f) ToString:

     CallCnvntn: [DEFAULT] hasThis

     ReturnType: String

     No arguments.

    Представление метаданных компоновочного блока

    Окно метаданных ildasm.exe позволяет также просмотреть метаданные самого компоновочного блока, для обозначения которых используется метка Assembly. Следующий фрагмент листинга показывает, что информация, представленная в таблице Assembly, аналогична информации, получаемой в окне ildasm.exe через пиктограмму MANIFEST (и это совсем не удивительно). Вот часть манифеста CarLibrary.dll (версии 2.0.0.0).

    Assembly

    -------------------------------------------------------------

     Token: 0x20000001

     Name: CarLibrary

     Public Key: 00 24 00 00 04 80 00 00 // и т.д.

     Hash Algorithm: 0x00008004

     Major Version: 0x00000002

     Minor Version: 0x00000000

     Build Number: 0x00000000

     Revision Number: 0x000000000

     Locale: ‹null›

     Flags: [SideBySideCompatible] (00000000)

    Представление ссылок на другие компоновочные блоки

    Вдобавок к метке Assembly и набору меток TypeDef и TypeRef метаданные .NET используют метки "AssemblyRef #n", чтобы обозначить внешние компоновочные блоки. Например, поскольку CarLibrary.dll использует тип MessageBox, в окне метаданных вы обнаружите метку AssemblyRef для System.Windows.Forms.

    AssemblyRef #2

    -------------------------------------------------------------

     Token: 0x23000002

     Public Key or Token: b7 7a 5c 56 19 34 e0 89

     Name: System.Windows.Forms

     Version: 2.0.3600.0

     Major Version: 0x00000002

     Minor Version: 0x00000000

     Build Number: 0x00000e10

     Revision Number: 0x00000000

     Locale: ‹null›

     HashValue Blob:

     Flags: [none] (00000000)

    Представление строковых литералов

    В заключение нашего обсуждения метаданных .NET укажем на то, что все строковые литералы базового программного кода представляются в окне метаданных ildasm.exe под знаком метки User Strings, как показано ниже[1].

    User Strings

    70000001: (11) L"Car 2.0.0.0"

    70000019: (11) L"Jamming {0}"

    70000031: (13) L"Quiet time…"

    7000004d: (14) L"Ramming speed!"

    7000006b: (19) L"Faster is better."

    70000093: (16) L"Time to call AAA"

    700000b5: (16) L"Your car is dead"

    700000d7: (9) L"Be quiet "

    700000eb: (2) L"!!"

    Пока что не слишком беспокойтесь о точном синтаксисе каждого элемента метаданных .NET. Более важно то, что метаданные .NET дают очень подробное описание всех типов, определенных внутри базового кода, и всех данных, на которые в этом базовом коде имеются ссылки.

    Теперь у вас должен возникнуть следующий вопрос: если вообще нужно что-то знать о метаданных, то как использовать эту информацию в приложениях? Чтобы получить ответ, давайте рассмотрим такое понятие, как сервисы отображения .NET. А вопрос о пользе предлагаемых ниже подходов мы оставим открытым до рассмотрения соответствующих примеров в конце этой главы. Поэтому наберитесь терпения.

    Замечание. В окне MetaInfo утилиты ildasm.exe вы обнаружите также ряд меток CustomAttribute, которые используются для обозначения атрибутов, примененных в базовом программном коде. Роль атрибутов .NET мы обсудим в этой главе немного позже.

    Отображение типов в .NET

    В терминах .NET отображение обозначает процесс выяснения параметров типа средой выполнения. Используя сервисы отображения, ту же информацию метаданных, которая отображается с помощью ildasm.exe, вы можете получить программно. Например с помощью отображения можно получить список всех типов, содержащихся в данном компоновочном блоке (или в файле *.netmodule), включая методы, поля, свойства и события, определенные данным типом. Можно также динамически выяснить, какой набор интерфейсов поддерживается данным классом (или структурой), выяснить параметры метода и другие аналогичные подробности (базовые классы, информацию пространства имен, данные манифеста и т.д.).

    Подобно любому другому пространству имен, System.Reflection содержит ряд связанных типов. В табл. 12.1 приводится список элементов этого пространства имен, о которых вам следует знать.

    Таблица 12.1. Некоторые элементы пространства имен System.Reflection

    Тип Описание
    Assembly Этот класс (вместе с множеством связанных типов) предлагает ряд методов, позволяющих загружать, исследовать и обрабатывать компоновочный блок
    AssemblyName Класс, позволяющий выяснить многочисленные подробности, касающиеся идентификации компоновочного блока (информацию о версии, параметры локализации и т.д.)
    EventInfo Класс, содержащий информацию об указанном событии
    FieldInfo Класс, содержащий информацию об указанном поле
    MemberInfо Абстрактный базовый класс, определяющий общие характеристики поведения для типов EventInfo, Fieldlnfo, MethodInfo и PropertyInfo
    MethodInfo Класс, содержащий информацию об указанном методе
    Module Класс, позволяющий получить доступ к указанному модулю многомодульного компоновочного блока
    ParameterInfo Класс, содержащий информацию об указанном параметре
    PropertyInfo Класс, содержащий информацию об указанном свойстве

    Чтобы понять, как использовать пространство имен System.Reflection для чтения метаданных .NET программными средствами, мы с вами должны сначала ознакомиться с возможностями класса System.Type.

    Класс System.Type

    Класс System.Type определяет ряд членов, которые могут использоваться для чтения метаданных типа, и многие из этих членов возвращают типы из пространства имен System.Reflection. Например, тип Type.GetMethods() возвращает массив типов MethodInfo, тип Type.GetFields() возвращает массив типа FieldInfo и т.д. Полный набор открытых членов System.Type очень велик. В табл. 12.2 предлагается небольшой список наиболее важных из них (подробности описания можно найти в документации .NET Framework 2.0 SDK).

    Таблица 12.2. Избранные члены System.Type

    Тип Описание
    IsAbstract IsArray IsClass IsCOMObject IsEnum IsGenerlcTypeDefinition IsGenericParameter Islnterface IsPrimitive IsNestedPrivate IsNestedPublic IsSealed IsValueType Эти свойства (наряду с другими аналогичными) позволяют выяснить ряд основных характеристик соответствующего объекта Туре (например, является ли этот объект абстрактным методом, массивом, вложенным классом и т.д.)
    GetConstructors() GetEvents() GetFields() GetInterfaces() GetMembers() GetMethods() GetNestedTypes() GetProperties() Эти методы (наряду с другими аналогичными) позволяют получить массив, представляющий все элементы соответствующего вида (интерфейсы, методы, свойства и т.п.). Каждый метод возвращает свой массив (например, GetFields() возвращает массив FieldInfо, GetMethods() возвращает массив MethodInfo и т.д.). Каждый из этих методов имеет также форму единственного числа (GetMethod(), GetProperty() и т.д.), которая позволяет извлечь один конкретный элемент по имени, а не все связанные элементы
    FindMembers() Возвращает массив типов MemberInfo на основе заданных критериев поиска
    GetType() Статический метод, возвращающий экземпляр Туре по заданному строковому имени
    InvokeMember() Позволяет выполнить динамическую привязку к заданному элементу

    Получение Туре с помощью System.Object.GetType()

    Экземпляр класса Туре можно получить множеством способов. Нельзя только непосредственно создать объект Туре, используя для этого ключевое слово new, поскольку класс Туре является абстрактным. Чтобы привести пример одной из допустимых возможностей, напомним, что System.Object определяет метод GetType(), который возвращает экземпляр класса Туре, представляющий метаданные соответствующего объекта.

    // Получение информации типа с помощью экземпляра SportsCar.

    SportsCar sc = new SportsCar();

    Type t = sc.GetType();

    Очевидно, что этот подход будет оправдан только в том случае, когда вы имеете информацию о соответствующем типе (в данном случае это тип SportsCar) во время компиляции. При этом становится ясно, что такие инструменты, как ildasm.exe, не могут получать информацию о типах путем непосредственно вызова System.Object.GetType(), поскольку ildasm.exe не компилируется вместе с пользовательскими компоновочными блоками.

    Получение Туре с помощью System.Type.GetType()

    Более гибкий подход обеспечивается использованием статического члена GetType() класса System.Type с указанием абсолютного имени соответствующего типа в виде строки. При использовании такого подхода для извлечения метаданных уже не требуется информация о типе во время компиляции, поскольку Type.GetType() использует экземпляр "вездесущего" System.String.

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

    // Получение информации типа с помощью метода Type.GetType()

    // (не генерировать исключение, если SportsCar не найден,

    // и игнорировать регистр символов).

    Type t = Type.GetType(''CarLibrary.SportsCar", false, true);

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

    // Получение информации типа из внешнего компоновочного блока.

    Type t = null;

    t = Type.GetType("CarLibrary.SportsCar, CarLibrary");

    Следует также знать о том, что в строке, передаваемой методу GetType(), может присутствовать знак "плюс" (+), используемый для обозначения вложенного типа. Предположим, что мы хотим получить информацию для перечня (SpyOptions), вложенного в класс JamesBondCar. Для этого мы должны написать следующее.

    // Получение информации типа для вложенного перечня

    // в рамках имеющегося компоновочного блока.

    Type t = Type.GetType(''CarLibrary. JamesBondCar+SpyOptions");

    Получение Туре с помощью typeof()

    Наконец, можно получить информацию типа с помощью операции C# typeof.

    // Получение Туре с помощью typeof.

    Type t = typeof(SportsCar);

    Подобно методу Type.GetType(), операция typeof оказывается полезной тем, что при ее использовании нет необходимости сначала создавать экземпляр объекта, чтобы затем извлечь из него информацию типа. Но при этом ваш базовый код все равно должен иметь информацию о типе во время компиляции.

    Создание пользовательского приложения для просмотра метаданных

    Чтобы очертить общие контуры процесса отображения (а также привести пример использования System.Type), мы создадим консольное приложение, которое назовем MyTypeViewer. Эта программа будет отображать подробную информацию о методах, свойствах, полях и поддерживаемых интерфейсах (и другую информацию) для любого типа из MyTypeViewer, а также из mscorlib.dll (напомним, что все приложения .NET автоматически получают доступ к этой базовой библиотеке классов).

    Отображение методов

    Мы модифицируем класс Program, чтобы определить ряд статических методов, каждый из которых будет иметь один параметр System.Type и возвращать void. Начнем с метода ListMethods(), который (как вы можете догадаться сами) печатает имена всех методов, определенных указанным на входе типом. При этом заметим, что Type.GetMethods() возвращает массив типов System.Reflection.MethodInfo.

    // Отображение имен методов типа.

    public static void ListMethods(Type t) {

     Console.WriteLine("***** Методы *****");

     MethodInfo[] mi = t.GetMethods();

     foreach (MethodInfo m in mi) Console.WriteLine("-›{0}", m.Name);

     Console.WriteLine(");

    }

    Здесь с помощью свойства MethodInfo.Name просто печатается имя метода. Как и следует предполагать, MethodInfo имеет много других членов, которые позволяют выяснить, является ли метод статическим, виртуальным или абстрактным. Кроме того, тип MethodInfo позволяет получить возвращаемое значение метода и множество его параметров. Реализацию ListMethods() мы с вами проанализируем чуть позже.

    Отображение полей и свойств

    Реализация ListFields() будет аналогичной. Единственным отличием будет вызов Type.GetFields(), а результирующим массивом будет FieldInfo. Для простоты мы печатаем только имена полей.

    // Отображение имен полей типа.

    public static void ListFields(Type t) {

     Console.WriteLine("***** Поля *****");

     FieldInfo[] fi = t.GetFields();

     foreach (FieldInfo field in fi) Console.WriteLine("-›{0}", field.Name);

     Console.WriteLine(");

    }

    Логика отображения свойств типа аналогична.

    // Отображение имен свойств типа.

    public static void ListProps(Type t) {

     Console.WriteLine("***** Свойства *****");

     PropertyInfo[] pi = t.GetProperties();

     foreach(PropertyInfo prop in pi) Console.WriteLine("-›{0}", prop.Name);

     Console.WriteLine(");

    }

    Отображение реализованных интерфейсов

    Теперь построим метод ListInterfaces(), который будет печатать имена интерфейсов, поддерживаемых указанным на входе типом. Единственным заслуживающим внимания моментом здесь является вызов GetInterfaces(), возвращающий массив System.Types. Это логично, поскольку интерфейсы тоже являются типами.

    // Отображение реализованных интерфейсов.

    public static void ListInterfaces(Type t) {

     Console.WriteLine("***** Интерфейсы *****");

     Type[] ifaсes = t.GetInterfaces();

     foreach (Type i in ifaces) Console.WriteLine("-› {0}", i.Name);

    }

    Отображение вспомогательной информации

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

    // Отображаются для полноты картины.

    public static void ListVariousStats(Type t) {

     Console.WriteLine("***** Вcпомогательная информация *****");

     Console.WriteLine("Базовый класс: {0}", t.BaseType);

     Console.WriteLine("Это абстрактный тип? {0}", t.IsAbstract);

     Console.WriteLine("Это изолированный тип? {'0}", t.IsSealed);

     Console.WriteLine("Это обобщенный тип? {0}", t.IsGenericTypeDefinition);

     Console.WriteLine("Это тип класса? {0}", t.IsClass);

     Console.WriteLine(");

    }

    Реализация Main()

    Метод Main() класса Program запрашивает у пользователя абсолютное имя типа. После получения строковых данных они передаются методу Туре.GetType(), а извлеченный объект System.Type отправляется каждому из вспомогательных методов. Это повторяется до тех пор, пока пользователь не нажмет клавишу ‹Q›, чтобы завершить выполнение приложения.

    // Здесь необходимо указать пространство имен отображения.

    using System;

    using System.Reflection;

    ...

    static void Main(string[] args) {

     Console.WriteLine("***** Добро пожаловать в MyTypeViewer! *****");

     string typeName = ";

     bool userIsDone = false;

     do {

      Console.WriteLine("\nВведите имя типа");

      Console.Write("или нажмите Q для выхода из приложения: ");

      // Получение имени типа.

      typeName = Console.ReadLine();

      // Желает ли пользователь завершить работу приложения?

      if (typeName.ToUpper() = "Q") {

       userIsDone = true;

       break;

      }

      // Попытка отображения типа.

      try {

       Type t = Type.GetType(typeName);

       Console.WriteLine("");

       ListVariousStats(t);

       ListFields(t);

       ListProps(t);

       ListMethods(t);

       ListInterfaces(t);

      } catch {

       Console.WriteLine("Извините, указанный тип не найден");

      }

     } while (userIsDone);

    }

    К этому моменту приложение MyTypeViewer.exe уже готово для тестового запуска. Запустите это приложение и введите следующие абсолютные имена (помните о том, что при используемом здесь варианте вызова Туре.GetType() строки имен оказываются чувствительными к регистру символов).

    • System.Int32

    • System.Collections.ArrayList

    • System.Threading.Thread

    • System.Void

    • System.IO.BinaryWriter

    • System.Math

    • System.Console

    • MyTypeViewer.Program

    На рис. 12.2 показана информация для случая, соответствующего выбору типа System.Math.

    Риc. 12.2. Отображение System.Math

    Отображение параметров и возвращаемых значений методов

    Итак, всё работает. Теперь немного усовершенствуем наше приложение. В частности, модифицируем вспомогательную функцию ListMethods(), чтобы получать не только имя метода, но и возвращаемое значение, а также входные параметры. Для решения именно таких задач тип MethodInfo предлагает свойство ReturnType и метод GetParameters().

    В следующем фрагменте программного кода обратите внимание на то, что строка, содержащая тип и имя каждого из параметров, строится с помощью вложенного цикла foreach.

    public static void ListMethods(Type t) {

     Console.WriteLine(***** Методы *****");

     MethodInfo[] mi = t.GetMethods();

     foreach (MethodInfo m in mi) {

      // Получение возвращаемого значения.

      string retVal = m.ReturnType.FullName;

      string paramInfo = "(";

      // Получение параметров.

      foreach (ParameterInfo pi in m.GetParameters()) {

       paramInfo += string.Format("{0} {1}", pi.ParameterType, pi.Name);

      }

      paramInfo += ")";

      // Отображение основных характеристик метода.

      Console.WriteLine("-›{0} {1} (2}", retVal, m.Name, paramInfo);

     }

     Console.WriteLine(");

    }

    Если выполнить это обновленное приложение теперь, методы соответствующего типа будут описаны более подробно. Для примера на рис. 12.3 показаны метаданные методов для типа System.Globalization.GregorianCalendar.

    Рис. 12.3. Подробное описание методов System.Globalization.GregorianCalendar

    Весьма увлекательно, не так ли? Ясно, что пространство имен System.Reflection и класс System.Type позволяют отображать многие другие характеристики типа, а не только те, которые в настоящий момент реализованы в MyTypeViewer. Вы вправе надеяться на то, что можно будет исследовать события типа, выяснить, какие интерфейсы реализованы явно, получить список обобщенных параметров для заданных членов и проверить множество других характеристик.

    Но и в нынешнем своем виде ваш обозреватель объектов уже кое-что умеет. Главным его ограничением, конечно же, является то, что у вас нет никакой возможности отображать объекты, размещенные вне данного компоновочного блока (MyTypeViewer) или всегда доступного mscorlib.dll. В связи с этим остается открытым вопрос: "Как строить приложения, которые могут загружать (и отображать) компоновочные блоки, о которых нет информации во время компиляции?"

    Исходный код. Проект MyTypeViewer размещен в подкаталоге, соответствующем главе 15.

    Динамически загружаемые компоновочные блоки

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

    В рамках System.Reflection определяется класс, имя которого Assembly. Используя этот тип, можно динамически загрузить любой компоновочный блок, а также выяснить его свойства. Используя тип Assembly, можно динамически загружать приватные и общедоступные компоновочные блоки, размещенные в любом месте системы. Класс Assembly предлагает методы (в частности, Load() и LoadFrom()), позволяющие программными средствами получать информацию, аналогичную той, которая содержится в файле *.config клиента.

    Для примера использования динамической загрузки создайте новое консольное приложение с именем ExternalAssemblyReflector. Вашей задачей является построение метода Main(), запрашивающего понятное имя компоновочного блока для динамической загрузки. Ссылка Assembly будет передана вспомогательному методу DisplayTypes(), который просто напечатает имена всех, классов, интерфейсов, структур, перечней и делегатов соответствующего компоновочного блока. Необходимый программный код выглядит довольно просто.

    using System;

    using System.Reflection;

    using System.IO; // Для определения FileNotFoundException.

    namespace ExternalAssemblyReflector {

     class Program {

      static void DisplayTypesInAsm(Assembly asm) {

       Console.WriteLine("\n*** Типы компоновочного блока ***");

       Console.WriteLine("-› {0}", asm.FullName);

       Type[] types = asm.GetTypes();

       foreach (Type t in types) Console.WriteLine("Тип: {0}", t);

       Console.WriteLine(");

      }

      static void Main(string[] args) {

       Console.WriteLine("*** Обзор внешних компоновочных блоков ***");

       string asmName = ";

       bool userIsDone = false;

       Assembly asm = null;

       do {

        Console.WriteLine("\nВведите имя компоновочного блока");

        Console.Write("или нажмите Q для выхода из приложения:");

        // Получение имени компоновочного блока.

        asmName = Console.ReadLine();

        // Желает ли пользователь завершить работу приложения?

        if (asmName.ToUpper() == "Q") {

         userIsDone = true;

         break;

        }

        // Попытка загрузить компоновочный блок.

        try {

         asm = Assembly.Load(asmName);

         DisplayTypesInAsm(asm);

        } catch {

         Console.WriteLine("Извините, компоновочный блок не найден.");

        }

       } while (userIsDone);

      }

     }

    }

    Обратите внимание на то, что статическому методу Assembly.Load() передается только понятное имя компоновочного блока, который вы хотите загрузить в память. Поэтому, чтобы получить отображение CarLibrary.dll с помощью этой программы, перед ее выполнением нужно скопировать двоичный файл CarLibrary.dll в каталог \Bin\Debug приложения ExternalAssemblyReflector. После этого вывод программы будет аналогичен показанному на рис. 12.4.

    Рис. 12.4. Отображение внешнего компоновочного блока CarLibrary

    Замечание. Чтобы приложение ExternalAssemblyReflector было более гибким, следует загружать внешний компоновочный блок с помощью Assembsly.LoadFrom(), а не с помощью Assembly.Load(). Тогда вы сможете указать для соответствующего компоновочного блока абсолютный путь (например, C:\MyApp\MyAsm.dll).

    Исходный код. Проект ExternalAssemblyReflector размещен в подкаталоге, соответствующем главе 12.

    Отображение общедоступных компоновочных блоков

    Как вы можете догадываться, метод Assembly.Load() является перегруженным. Один из вариантов метода Assembly.Load() позволяет указать значение параметра culture (для локализованных компоновочных блоков), а также номер версии и значение открытого ключа (для общедоступных компоновочных блоков).

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

    Name (,Culture = код_языка) (,Version = _главный_номер.дополнительный_номер.номер_компоновки.номep_вapиaнтa) (,PublicKeyToken= код_открытого_ключа)

    Значение PublicKeyToken = null в строке, определяющей дисплейное имя, указывает на то, что при связывании проверка строгого имени не требуется и его наличие у компоновочного блока не обязательно. Значений Culture = "" сообщает о необходимости использований значения кода локализации, принятого на машине по умолчанию, например:

    // Загрузка CarLibrary версии 1.0.982.23972 с кодом локализации,

    // используемым по умолчанию.

    Assembly a = Assembly.Load(@"CarLibrary,Version=1.0.982.23972,PublicKeyToken=null,Culture=''");

    Пространство имен System.Reflection предлагает также тип AssemblyName, который позволяет представить указанную выше информационную строку в объектной переменной. Обычно этот класс используется вместе с System.Version, являющимся объектным контейнером для номера версии компоновочного блока. Создав дисплейное имя, вы можете передать его перегруженному методу Assembly.Load().

    // Использование AssemblyName для определения дисплейного имени.

    AssemblyName asmName;

    asmName = new AssemblyName();

    asmName.Name = "CarLibrary";

    Version v = new Version("1.0.982.23972");

    asmName.Version = v;

    Assembly a = Assembly.Load(asmName);

    Чтобы загрузить общедоступный компоновочный блок из GAC, параметр Assembly.Load() должен указать значение publickeytoken. Предположим, на-пример, что вы хотите загрузить компоновочный блок System.Windows.Forms.dll версии 2.0.0.0, предлагаемый библиотеками базовых классов .NET. Поскольку число типов в этом компоновочном блоке очень велико, следующее приложение выводит имена только первых 20 типов.

    using System;

    using System.Reflection;

    using System.IO;

    namespace SharedAsmReflector {

      public class SharedAsmReflector {

       private static void DisplayInfo(Assembly a) {

        Console.WriteLine("***** Информация о компоновочном блоке *****");

        Console.WriteLine("Загружен из GAC? {0}", a.GlobalAssemblyCache);

        Console.WriteLine("Имя: {0}", a.GetName().Name);

        Console.WriteLine("Версия: {0}", a.GetName().Version);

        Console.WriteLine("Культура: {0}", a.GetName().CultureInfo.DisplayName);

        Type[] types = a.GetTypes();

        for (int i = 0; i ‹ 20; i++) Console.WriteLine("Тип: {0}", types[i]);

       }

      }

      static void Main(string[] args) {

       Console.WriteLine("***** Отображение общедоступных КБ *****\n");

       // Загрузка System.Windows.Forms.dll из GAC.

       string displayName = null;

       displayName = "System.Windows.Forms," +

        "Version=2.0.0.0," +

        "PublicKeyToken=b77а5c561934e089" +

        @"Culture=''";

       Assembly asm = Assembly.Load(displayName);

       DisplayInfo(asm);

       Console.ReadLine();

      }

     }

    }

    Исходный код. Проект SharedAsmReflector размещен в подкаталоге, соответствующем главе 12.

    Чудесно! К этому моменту нашего обсуждения вы должны понять, как использовать некоторые базовые элементы из пространства имен System.Reflection для чтения метаданных компоновочного блока во время выполнения. Здесь я готов признать, что, несмотря на "фактор красоты" предлагаемого подхода, вам по роду своей деятельности вряд ли придется строить пользовательские навигаторы объектов. Но не следует забывать о том, что сервисы отображения являются основой целого ряда других, очень широко используемых подходов в программировании, включая и динамическое связывание.

    Динамическое связывание

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

    На данном этапе обсуждения значение динамического связывания может казаться вам непонятным. Если вы имеете возможность использовать "статическую привязку" к типу (например, установить ссылку на компоновочный блок и поместить тип в память, используя ключевое слово C# new), то в этом случае так и нужно сделать. Статическое связывание позволяет обнаружить ошибки уже во время компиляции, а не во время выполнения программы. Однако динамическое связывание оказывается очень важным для построения приложений, обладающих более гибкими возможностями расширения.

    Класс System.Activator

    Класс System.Activator обеспечивает возможность реализации процесса динамической привязки в .NET. Кроме методов, унаследованных от System.Object, сам класс Activator определяет очень небольшое множество членов, многие из которых относятся к средствам удаленного взаимодействия .NET (cм. главу 18). Для нашего примера нам понадобится только метод Activator.CreateInstance(), который используется для создания экземпляра типа в рамках динамической привязки.

    Этот метод имеет множество перегруженных вариаций, что обеспечивает ему исключительную гибкость. Самая простая вариация члена CreateInstance() должна получить на вход объект Туре, описывающий элемент, который вы хотите динамически разместить. Создайте новое приложение с именем LateBinding и модифицируйте его метод Main() так, как показано ниже (не забудьте поместить копию CarLibrary.dll в каталог \Bin\Debug проекта).

    // Динамическое создание типа.

    public class Program {

     static void Main(string[] args) {

      // Попытка загрузить локальную копию CarLibrary.

      Assembly a = null;

      try {

       a = Assembly.Load("CarLibrary");

      } catch(FileNotFoundException e) {

       Console.WriteLine(e.Message);

       Console.ReadLine();

       return;

      }

      // Получение метаданных типа Minivan.

      Type miniVan = a.GetType("CarLibrary.MiniVan");

      // Динамическое создание Minivan.

      object obj = Activator.Createlnstance(miniVan);

     }

    }

    Обратите внимание на то, что метод Activator.CreateInstance() возвращает обобщенный System.Object, а не строго типизированный MiniVan. Поэтому если к переменной obj вы примените операцию, обозначаемую точкой, то не увидите никаких членов типа MiniVan. На первый взгляд, можно предположить, что эта проблема решается с помощью явного преобразования типа, но ведь программа не имеет никаких указаний на то, что MiniVan должен иметь при выборе какие-либо преимущества.

    Весь смысл динамической привязки заключается в создании экземпляров объектов, для которых нет статической информации. Но как при этом можно вызвать методы объекта MiniVan, сохраненного в переменной System.Object? Ответ: с помощью отображений.

    Вызов методов без параметров

    Предположим, что нам нужно вызвать метод TurboBoost() типа MiniVan. Вы помните, что этот метод приводит двигатель в "абсолютно нерабочее" состояние и генерирует появление информационного блока сообщения. Первым нашим шагом должно быть получение типа MethodInfо для метода TurboBoost() с помощью Type.GetMethod(). Получив MethodInfo, мы сможем вызвать Minivan.TurboBoost() с помощью Invoke(). Для MethodInfo.Invoke() необходимо указать все параметры, которые должны быть переданы методу, представленному с помощью MethodInfo. Эти параметры представляются массивом System.Object (поскольку метод может иметь любое число параметров любого типа).

    Наш метод TurboBoost() не имеет параметров, поэтому для него указывается null (в данном случае это и означает отсутствие параметров у метода). Модифицируйте метод Main() так.

    static void Main(string[] args) {

     // Попытка загрузить локальную копию CarLibrary.

     ...

     // Получение типа MiniVan.

     Type miтiVan = a.GetType("CarLibrary.MiniVan");

     // Динамическое создание MiniVan.

     object obj = Activator.CreateInstance(miniVan);

     // Получение информации о TurboBoost.

     MethodInfo mi = miniVan.GetMethod("TurboBoost");

     // Вызов метода ('null' означает отсутствие параметров) .

     mi.Invoke(obj, null);

    }

    После этого вы сможете лицезреть сообщение, подобное показанному на рис. 12.5.

    Рис. 12.5. Вызов метода в условиях динамической привязки

    Вызов методов с параметрами

    Чтобы показать пример динамического вызова метода, имеющего параметры, предположим, что тип MiniVan определяет метод, который называется TellChildToBeQuiet().

    // Усмирение вопящих…

    public void TellChildToBeQuiet(string kidName, int shameIntensity) {

     for (int i = 0; i ‹ shameIntensity; i++)

      MessageBox.Show("Потише, {0}!!", kidName);

    }

    Метод TellChildToBeQuiet() (приказать ребенку успокоиться) имеет два параметра: строковое представление имени ребенка и целое число, отражающее степень вашего раздражения. При использовании динамического связывания параметры упаковываются в массив объектов System.Object. Для вызова этого нового метода добавьте в свой метод Main() следующий программный код.

    // Динамический вызов метода с параметрами.

    object[] paramArray = new object[2];

    paramArray[0] = "Фред"; // Имя ребенка.

    paramArray[1] = 4; // Степень досады.

    mi = miniVan.GetMethod("TellChildToBeQuiet");

    mi.Invoke(obj, paramArray);

    Выполнив эту программу, вы сможете увидеть четыре блока сообщений, отражающих намерение пристыдить юного Фреда. Надеюсь, что к этому моменту нашего обсуждения вы уже можете видеть взаимосвязь между отображением, динамической загрузкой и динамическим связыванием. Для вас еще может оставаться неясным ответ на вопрос, когда следует использовать указанный подход в приложениях. Завершающий раздел этой главы должен пролить на это свет, но пока что следующей темой нашего рассмотрения будет исследование роли атрибутов .NET.

    Исходный код. Проект LateBinding размещен в подкаталоге, соответствующем главе 12.

    Программирование с помощью атрибутов

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

    Идея аннотирования программного кода с помощью атрибутов не нова. Множество встроенных атрибутов предлагает COM IDL (Interface Definition Language – язык описания интерфейсов), что позволяет разработчику описывать типы COM-сервера. Однако атрибуты COM представляют собой, по сути, лишь набор ключевых слов. Если перед разработчиком COM возникает задача создания пользовательских атрибутов, то эта задача оказывается вполне разрешимой, но ссылаться на такой атрибут в программном коде придется с помощью 128-разрядного номера (GUID), а это, в лучшем случае, слишком обременительно.

    В отличие от атрибутов COM IDL (которые, напомним, являются просто ключевыми словами), атрибуты .NET являются типами класса, расширяющими абстрактный базовый класс System.Attribute. При исследовании пространств имен .NET вы можете обнаружить множество встроенных атрибутов, которые можно использовать в приложениях. К тому же вы можете строить свои пользовательские атрибуты, чтобы затем корректировать поведение своих типов с помощью создания новых типов, производных от Attribute.

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

    Потребители атрибутов

    Как вы можете догадаться, в комплекте с .NET Framework 2.0 SDK поставляется множество утилит, предназначенных для работы с различными атрибутами. Даже компилятор C# (csc.exe) запрограммирован на проверку определенных атрибутов в процессе компиляции. Например, если компилятор C# обнаруживает атрибут [CLSCompilant], он автоматически проверяет соответствующий элемент на совместимость всех его конструкций с CLS. Если же компилятор C# обнаружит элемент с атрибутом [Obsolete], в окне сообщений об ошибках Visual Studio 2005 появится соответствующее предупреждение.

    Вдобавок к инструментам разработки, многие методы из библиотек базовых классов .NET тоже запрограммированы на работу с конкретными атрибутами. Например, если вы хотите сохранить состояние объекта в файле, необходимо указать для класса атрибут [Serializable]. Когда метод Serialize() класса BinaryFormatter обнаруживает указанное свойство, объект автоматически сохраняется в файл в компактном двоичном формате.

    Среда CLR также контролирует наличие определенных атрибутов. Возможно, самым известным из атрибутов .NET является [WebMethod]. Если вы хотите открыть метод для запросов HTTP и автоматически кодировать возвращаемое значение метода в формат XML, просто укажите атрибут [WebMethod] для этого метода, и всю рутинную работу среда CLR выполнит сама. Кроме разработки Web-сервисов, атрибуты важны дли системы безопасности .NET, слоя операций удаленного доступа, взаимодействия COM/.NET и т.д.

    Наконец, можно строить приложения, которые, наряду с атрибутами библиотек базовых классов .NET. будут отображать пользовательские атрибуты. Такой подход позволяет создавать наборы "ключевых слов", понятных только заданному множеству компоновочных блоков.

    Применение встроенных атрибутов C#

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

    Чтобы привести пример применения атрибутов в C#, предположим, что нам нужно построить класс Motorcycle (мотоцикл), допускающий сериализацию в двоичном формате. Для этого мы должны просто добавить атрибут [Serializable] в определение класса. Если при этом какое-то поле при сериализации сохраняться не должно, то к нему можно применить атрибут [NonSerialized].

    // Этот класс можно сохранить на диске.

    [Serializable]

    public class Motorcycle {

     // Но это поле сохраняться не должно.

     [NonSerialized]

     float weightOfCurrentPassengers;

     // Следующие поля сохраняются.

     bool hasRadioSystem;

     bool hasHeadSet;

     bool hasSissyBar;

    }

    Таблица 12.3. Малая часть встроенных атрибутов 

    Атрибут Описание
    [CLSCompliant] Требует от элемента строгого соответствия правилам CLS (Common Language Specification – общеязыковые спецификации). Напомним, что соответствующие CLS-спецификациям типы гарантированно могут использоваться во всех языках программирования .NET
    [DllImport] Позволяет программному коду .NET вызывать библиотеки программного кода C или C++ (которые не являются управляемыми), включая API (Application Programming Interface – программный интерфейс приложения) операционной системы. Заметьте, что [DllImport] не используется при взаимодействии с программным обеспечением COM
    [Obsolete] Обозначает устаревший тип или член. При попытке использовать такой элемент программист получит предупреждение компилятора с соответствующим описанием ошибки
    [Serializable] Обозначает возможность сериализации класса или структуры
    [NonSerialized] Указывает, что данное поле класса или структуры не должно сохраняться в процессе сериализации
    [WebMethod] Обозначает доступность метода для вызова через запросы HTTP и требует от среды CLR сохранения возвращаемого значения метода в формате XML (подробности можно найти в главе 25)

    Замечание. Указанный атрибут применяется только к элементу, непосредственно следующему за атрибутом. Например, единственным не сохраняемым полем класса Motorcycle будет weightOfCurrentPassengers. Остальные поля при сериализации сохраняются, поскольку весь класс аннотирован атрибутом [Serializable].

    Пока что не беспокойтесь о сути самого процесса сериализации объекта (подробности этого процесса будут рассмотрены в главе 17). Обратите внимание только на то, что при использовании атрибута его имя должно заключаться в квадратные скобки.

    После компиляции этого класса можете проверить его метаданные с помощью ildasm.exe. Соответствующие атрибуты будут обозначены метками serializable и notserialized (рис. 12.6).

    Как вы можете догадаться сами, один элемент может иметь много атрибутов. Предположим, что у нас есть тип класса C# (HorseAndBuggy), обозначенный как serializable, но теперь он считается устаревшим.

    Рис. 12.6. Отображение атрибутов в окне ildasm.exe

    Чтобы применить множество атрибутов к одному элементу, используйте список значений, разделенных запятыми.

    [Serializable,

    Obsolete("Класс устарел, используйте другой транспорт!")]

    public class HorseAndBuggy {

     // …

    }

    В качестве альтернативы, чтобы применить несколько атрибутов к одному элементу, можно просто указать их по порядку (результат будет тем же).

    [Serializable]

    [Obsolete("Класс устарел, используйте другой транспорт!")]

    public class HorseAndBuggy {

     // …

    }

    Параметры конструктора для атрибутов

    Мы видим, что атрибут [Obsolete] может принимать нечто похожее на параметр конструктора. Если вы посмотрите на формальное определение атрибута [Obsolete] в окне определения программного кода Visual Studio 2005, то увидите, что данный класс действительно предлагает конструктор, получающий System.String.

    public sealed сlass ObsoleteAttribute: System.Attribute {

     public bool IsError { get; }

     public string Message { get; }

     public ObsoleteAttribute(string message, bool error);

     public ObsoleteAttribute(string message);

     public ObsoleteAttribute();

    }

    Когда вы указываете параметры конструктора для атрибута, атрибут не размещается в памяти до тех пор, пока эти параметры не отобразятся другим типом или внешним программным средством. Строки, определенные на уровне атрибута, просто запоминаются в компоновочном блоке, как часть метаданных.

    Атрибут Obsolete в действии

    Теперь, когда класс HorseAndBuggy обозначен как устаревший, при размещении экземпляра этого типа вы должны увидеть соответствующую строку в сообщении, появившемся в окне со списком ошибок Visual Studio 2005 (рис. 12.7).

    Рис. 12.7. Атрибуты в действии

    В данном случае "другим фрагментом программного обеспечения", отображающим атрибут [Obsolete], является компилятор C#.

    Сокращенное представление атрибутов в C#

    При внимательном изучении материала этой главы вы могли заметить, что фактическим именем класса атрибута [Obsolete] является не Obsolete, a ObsoleteAttribute. По соглашению для имен все атрибуты .NET (и пользовательские атрибуты в том числе) должны в конце имени получить суффикс Attribute. Однако, чтобы упростить процедуру применения атрибутов, в языке C# не требуется, чтобы вы обязательно добавляли этот суффикс. Поэтому следующий вариант определения типа HorseAndBuggy будет идентичен предыдущему (при этом только потребуется ввести немного больше символов).

    [SerializableAttribute]

    [ObsoleteAttribute("Класс устарел, используйте другой транспорт!")]

    public class HorseAndBuggy {

     //…

    }

    Это упрощение предлагается самим языком C#, и следует подчеркнуть, что эту особенность поддерживают не все языки .NET. Так или иначе, к этому моменту нашего обсуждения вы должны понимать следующие основные особенности, касающиеся атрибутов .NET.

    • Атрибуты являются классами, производными от System.Attribute.

    • Информация атрибутов добавляется в метаданные.

    • Атрибуты будут бесполезны до тех пор, пока другой агент не отобразит их.

    • Атрибуты в C# применяются с использованием квадратных скобок.

    Теперь мы рассмотрим то, как можно строить свои собственные пользовательские атрибуты и пользовательские программы, отображающие встроенные метаданные.

    Создание пользовательских атрибутов

    Первым шагом процесса построения пользовательского атрибута является создание нового класса, производного от System.Attribute. В продолжение автомобильной темы, используемой в этой книге, мы создадим новую библиотеку классов C# с именем AttributedCarLibrary. Соответствующий компоновочный блок определит группу транспортных средств (определения некоторых из них, мы уже увидели выше), и при их описании будет использован пользовательский атрибут VehiсleDescriptionAttribute,

    // Пользовательский атрибут.

    public sealed class VehicleDescriptionAttribute: System.Attribute {

     private string msgData;

     public VehicleDescriptionAttribute(string description) { msgData = description; }

     public VehicleDescriptionAttribute() {}

     public string Description {

      get { return msgData; }

      set { msgData = value; }

     }

    }

    Как видите, VehicleDescriptionAttribute поддерживает приватную внутреннюю строку (msgData), значение которой можно установить с помощью пользовательского конструктора, а изменять - с помощью свойства типа (Description). Кроме того, что этот класс является производным от System.Attribute, его определение ничем особенным больше не отличается,

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

    Применение пользовательских атрибутов

    После получения VehicleDescriptionAttribute из System.Attribute вы можете снабжать свои транспортные средства такими аннотациями, какими пожелаете.

    // Назначение описания с помощью 'именованного свойства'.

    [Serializable,

    VehicleDescription(Description = "Мой сияющий Харлей")]

    public class Motorcycle {

     //…

    }

    [SerializableAttribute]

    [ObsoleteAttribute("Класс устарел, используйте другой транспорт!"), VehicleDescription("Старая серая кляча, она уже совсем не та…")]

    public class HorseAndBuggy {

     //…

    }

    [VehicleDescription("Большое, тяжелое, но высокотехнологичное авто"

    public class Winnebago {

     //…

    }

    Обратите внимание на то, что описание класса Motorcycle здесь указано с помощью нового элемента синтаксиса, называемого именованным свойством. В конструкторе первого атрибута [VehicleDescription] соответствующее значение System.String устанавливается с помощью пары "имя-значение". При отображении этого атрибута внешним агентом соответствующее значение передается свойству Description (синтаксис именованного свойства здесь корректен только в том случае, когда атрибут предлагает перезаписываемое свойство .NET). В противоположность этому типы HorseAndBuggy и Winnebago не используют синтаксис именованного свойства, а просто передают строковые данные в пользовательский конструктор.

    После компиляции компоновочного блока AttributedCarLibrary можно использовать ildasm.exe, чтобы увидеть метаданные с описанием добавленного типа. Так, на рис. 12.8 показано встроенное описание типа Winnebago.

    Рис. 12.8. Встроенные данные описания транспортного средства

    Ограничение использования атрибута

    По умолчанию пользовательские атрибуты могут применяться к любой части программного кода (к методам, классам, свойствам и т.д.). Поэтому, если только это имеет смысл, можно использовать VehicleDescription для определения (среди прочего) методов, свойств или полей.

    [VehicleDescription("Большое, тяжелое, но высокотехнологичное авто")]

    public class Winnebago {

     [VehicleDescription("Мой мощный CD-плейер")]

     public void PlayMusic(bool On) {

      …

     }

    }

    В некоторых случаях это оказывается именно тем, что нужно. Но в других случаях бывает нужно создать пользовательский атрибут, который должен применяться только к определенным элементам программного кода. Если вы хотите ограничить контекст применения пользовательского атрибута, то при определении пользовательского атрибута нужна применить атрибут [AttributeUsage]. Атрибут [AttributeUsage] позволяет указать любую комбинацию значений (связанных операцией OR) из перечня AttributeTargets.

    // Этот перечень задает возможные целевые значения для атрибута.

    public enum AttributeTargets {

     All, Assembly, Class, Constructor,

     Delegate, Enum, Event, Field,

     Interface, Method, Module, Parameter,

     Property, ReturnValue, Struct

    }

    Кроме того, [AttributeUsage] позволяет опционально установить именованное свойство (AllowMultiple), которое указывает, может ли атрибут примениться к одному и тому же элементу многократно. Точно так же с помощью именованного свойства Inherited атрибут [AttributeUsage] позволяет указать, должен ли создаваемый атрибут наследоваться производными классами.

    Чтобы атрибут [VehicleDescription] мог применяться к классу или структуре только один раз (и соответствующее значение не наследовалось производными типами), можно изменить определение VehicleDescriptionAttribute так.

    // На этот раз для аннотации нашего пользовательского атрибута

    // мы используем атрибут AttributeUsage.

    [AttributeUsage(AttributeTargets.Class | AttributeTargets.Struct, AllowMultiple = false, Inherited = false)]

    public class VehicleDescriptionAttribute: System.Attribute {

     …

    }

    Теперь если разработчик попытается применить атрибут [VehicleDescription] к чему-либо, кроме класса или структуры, будет сгенерировано сообщение об ошибке компиляции.

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

    Атрибуты уровня компоновочного блока (и уровня модуля)

    Можно также задать применение атрибутов ко всем типам в рамках данного модуля или всех модулей в рамках данного компоновочного блока, если, соответственно, использовать признаки [module:] или [assembly:]. Предположим, что нам нужно гарантировать, чтобы каждый открытый тип, определенный в нашем компоновочном блоке, был CLS-допустимым. Для этого в любой из файлов исходного кода C# нужно добавить следующую строку (заметьте, что атрибуты уровня компоновочного блока должны быть указаны за пределами контекста определения пространства имен).

    // Требование CLS-совместимости для всех открытых типов

    // в данном компоновочном блоке.

    [assembly:System.CLSCompliantAttribute(true)]

    Если теперь добавить фрагмент программного кода, который выходит за пределы спецификации CLS (например, элемент данных без знака)

    // Типы ulong не согласуется с CLS.

    public class Winnebago {

     public ulong notCompliant;

    }

    то будет сгенерирована ошибка компиляции.

    Файл AssemblyInfo.cs в Visual Studio 2005

    По умолчанию Visual Studio 2005 генерирует файл с именем AssemblyInfo.cs (рис. 12.9).

    Рис. 12.9. Файл AssemblyInfo.cs

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

    Исходный код. Проект AttributedCarLibrary размещен в подкаталоге, соответствующем главе 12.

    Таблица 12.4. Некоторые атрибуты уровня компоновочного блока

    Атрибут Описание
    AssemblyCompanyAttribute Содержит общую информацию о компании
    AssemblyCopyrightAttribute Содержит информацию об авторских правах на продукт или компоновочный блок
    AssemblyCultureAttribute Дает информацию о параметрах локализации или языках, поддерживаемых компоновочным блоком
    AssemblyDescriptionAttribute Содержит описание продукта или модулей, из которых состоит компоновочный блок
    AssemblyKeyFileAttribute Указывает имя файла, содержащего пару ключей, используемых для создания подписи компоновочного блока
    AssemblyOperatingSystemAttribute Обеспечивает информацию о том, на поддержку какой операционной системы рассчитан компоновочный блок
    AssemblyProcessorAttribute Обеспечивает информацию о том, на поддержку какого процессора рассчитан компоновочный блок
    AssemblyProductAttribute Обеспечивает информацию о продукте
    AssemblyTrademarkAttribute Обеcпечивает информацию о торговой марке
    AssemblyVersionAttribute Указывает информацию версии компоновочного блока, в формате‹главный.дополнительный.компоновка:вариант

    Отображение атрибутов при статическом связывании

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

    Для иллюстрации процесса отображения пользовательских атрибутов создайте новое консольное приложение C# с именем VehicleDescriptionAttributeReader. Затем установите в нем ссылку на компоновочный блок AttributedCarLibrary. Наконец, поместите в исходный файл *.cs следующий программный код.

    // Отображение пользовательских атрибутов при статическом связывании.

    using System;

    using AttributedCarLibrary;

    public class Program {

     static void Main(string [] args) {

      // Получение Type для представления Winnebago.

      Type t = typeof(Winnebago);

      // Получение атрибутов Winnebago.

      object[] customAtts = t.GetCustomAttributes(false);

      // Печать описания.

      Console.WriteLine("*** Значение VehicleDescriptionAttribute ***\n");

      foreach(VehicleDescriptionAtttibute v in customAtts) Console.WriteLine("-› {0}\n", v.Description);

      Console.ReadLine();

     }

    }

    Как следует из самого названия, метод Type.GetCustomAttributes() возвращает массив объектов, представляющих все атрибуты, примененные тому к члену, который представлен с помощью Туре (логический параметр этого метода указывает, следует ли расширить поиск на всю цепочку наследования). После получения списка атрибутов выполняется цикл по всем классам VehicleDescriptionAttribute с выводом на печать значения, полученного свойством Description.

    Исходный код. Проект VehicleDescriptionAttributeReader размещен в подкаталоге, соответствующем главе 12.

    Отображение атрибутов при динамическом связывании

    В предыдущем примере использовалось статическое связывание и печатались данные описания для типа Winnebago. Это было возможно благодаря тому, что тип класса VehicleDescriptionAttribute был определен, как открытый член компоновочного блока AttributedCarLibrary. Но для отображения атрибутов можно также использовать динамическую загрузку и динамическое связывание.

    Создайте новый консольный проект (VehicleDescriptionAttributeReaderLateBinding) и скопируйте AttributedCarLibrary.dll в каталог \Bin\Debug этого проекта. Затем обновите метод Main() так, как предлагается ниже.

    using System.Reflection;

     namespace VehicleDescriptionAttributeReaderLateBinding {

      class Program {

       static void Main(string[] args) {

        Console.WriteLine("*** Описания транспортных средств ***\n");

        // Загрузка локальной копии AttributedCarLibrагу.

        Assembly asm = Assembly.Load(AttributedCarLibrary");

        // Получение информации типа для VehicleDescriptionAttribute.

        Type vehicleDesc = asm.GetType("AttributedCarLibrary.VehicleDescriptionAttribute");

        // Получение информации типа для свойства Description.

        PropertyInfо propDesc = vehicleDesc.GetProperty("Description");

        // Получение всех типов данного компоновочного блока.

        Туре[] types = asm.GetTypes();

        // Получение VehicleDescriptionAttribute для каждого типа.

        foreach (Type t in types) {

         object[] objs = t.GetCustomAttributes(vehicleDesc, false);

         // Итерации по VehicleDescriptionAttribute и печать

         // описаний с динамическим связыванием.

         foreach(object о in objs) {

          Console.WriteLine("-› {0}: {1}\n", t.Name, propDesc.GetValue(o, null));

         }

        }

        Console.ReadLine();

       }

      }

    }

    Если вы внимательно анализировали все примеры этой главы, то листинг этого метода Main() должен быть для вас (более или менее) понятным. Единственным заслуживающим внимания моментом здесь является использование метода PropertyInfo.GetValue() для доступа к свойству. На рис. 12.10 показан соответствующий вывод.

    Рис. 12.10. Отображение атрибутов при динамическом связывании

    Исходный код. Проект VehiсleDescriptionAttributeReaderLateBinding размещен в подкаталоге, соответствующем главе 12.

    Перспективы отображения, статического и динамического связывания и пользовательских атрибутов

    Даже после множества примеров применения соответствующих подходов вам может быть не ясно, когда же следует использовать отображение, динамическую загрузку, динамическое связывание и пользовательские атрибуты в программах. Строго говоря, эти вопросы (которые увлекательны сами по себе) можно отнести, скорее, к теоретической стороне программирования (что можно считать как достоинством, так и недостатком, в зависимости от точки зрения). Чтобы спроецировать эти вопросы на реальность, нам нужен реальный пример. Представьте себе на минуту, что вы работаете в команде программистов, созданной для разработки приложения, удовлетворяющего следующему требованию:

    • продукт должен допускать расширение путем подключения дополнительных программных средств, разработанных сторонними производителями.

    Но что именно подразумевается под требованием допускать расширение? Рассмотрим Visual Studio 2005. При разработке этого приложения в нем были предусмотрены различные "гнезда" для подключения к IDE пользовательских модулей других производителей программного обеспечения. Ясно, что команда разработчиков Visual Studio 2005 не имела при этом возможности установить ссылки на внешние компоновочные блоки .NET, которые эта команда не разрабатывала (так что о статическом связывании не могло быть и речи). Поэтому закономерен вопрос: как именно это приложение смогло предложить необходимые гнезда подключения?

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

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

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

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

    Создание расширяемого приложения

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

    Мы предполагаем, что наше расширяемое приложение должно иметь следующее компоновочные блоки.

    • CommonSnappableTypes.dll. Компоновочный блок, содержащий определения типов, которые должны реализовываться каждым подключаемым расширением, поскольку на них будет ссылаться расширяемое приложение Windows Forms.

    • CSharpSnapIn.dll. Расширение, созданное на языке C# и использующее типы CommonSnappableTypes.dll.

    • VbNetSnapIn.dll. Расширение, созданное на языке Visual Basic .NET и использующее типы CommonSnappableTypes.dll.

    • MyPluggableApp.exe. Приложение Windows Forms, функциональные возможности которого можно расширять с помощью подключаемых модулей. Это приложение будет использовать динамическую загрузку, отображение и динамическое связывание для динамического выяснения функциональных возможностей компоновочных блоков, о которых ранее не было ничего известно.

    Создание CommonSnappableTypes.dll

    Первой нашей задачей является создание компоновочного блока, содержащего типы, которые должен использовать каждый подключаемый модуль, чтобы обеспечить возможность его подключения к нашему приложению Windows Forms. Проект библиотеки классов CommonSnappableTypes определяет следующие два типа.

    namespace CommonSnappableTypes {

     public interface IAppFunctionality {

      void DoIt();

     }

     [AttributeUsage(AttribyteTargets.Class)]

     public sealed class CompanyInfoAttribute: System.Attribute

      private string companyName;

      private string companyUrl;

      public CompanyInfoAttribute(){}

      public string Name {

       get { return companyName; }

       set { companyName = value; }

      }

      public string Url {

       get { return companyUrl; }

       set { companyUrl = value; }

      }

     }

    }

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

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

    Создание подключаемого компонента в C#

    Теперь нужно создать тип, реализующий интерфейс IAppFunctionality. Снова, чтобы сосредоточиться на процессе создания расширяемого приложения, здесь предполагается создание самого простого типа. Мы построим библиотеку программного кода C# с именем CSharpSnapIn, которая определит тип класса с именем CSharpModule. Поскольку этот класс должен использовать типы, определенные в CommonSnappableTypes, нам придется установить ссылку на соответствующий двоичный файл (а также на System.Windows.Forms.dll, чтобы выводить необходимые сообщения). С учетом сказанного предлагается использовать следующий программный код.

    using System;

    using CommonSnappableTypes;

    using System.Windows.Forms;

    namespace CSharpSnapIn {

     [CompanyInfo(Name = "Intertech Training",

      Url = www.intertechtraining.com)]

     public class TheCSharpModule: IAppFunctionality {

      void IAppFunctionality.DoIt() {

       MessageBox.Show("Вы только что подключили блок C#!");

      }

     }

    }

    Обратите внимание на то, что здесь используется явная реализация интерфейса IAppFunctionality. Это не обязательно, но идея в том, что единственной частью системы, которой понадобится непосредственное взаимодействие с этим. типом интерфейса, является наше расширяемое приложение Windows.

    Создание подключаемого компонента в Visual Basic .NET

    Теперь, чтобы имитировать стороннего производителя, предпочитающего использовать не C#, a Visual Basic .NET, создадим в Visual Basic .NET новую библиотеку программного кода (VbNetSnapIn), которая будет ссылаться на те же внешние компоновочные блоки, что и CSharpSnapIn. Программный код (снова) будет пред-намерено очень простым.

    Imports System.Windows.Forms

    Imports CommonSnappableTypes

    ‹CompanyInfo(Name:="Chucky's Software", Url:="‹www.ChuckySoft.com")› _

    Public Class VbNetSnapIn Implements IAppFunctionality

     Public Sub DoIt() Implements CommonSnappableTypes.IAppFunctionality.DoIt

      MessageBox.Show("Вы только что подключили блок VB .NET!")

     End Sub

    End Class

    Говорить здесь особенно не о чем. Однако обратите внимание на то, что синтаксис применения атрибутов в Visual Basic .NET предполагает использование угловых (‹›), а не квадратных ([]) скобок.

    Создание расширяемого приложения Windows Forms

    Заключительным шагом будет создание приложения Windows Forms, которое позволит пользователю выбрать подключаемый блок с помощью стандартного диалогового окна открытия файла Windows. Создав новое приложение Windows Forms (с именем MyExtendableApp), добавите ссылку на компоновочный блок CommonSnappableTypes.dll, но не устанавливайте ссылок на библиотеки программного кода CSharpSnapIn.dll и VbNetSnapIn.dll. Помните о том, что целью создания этого приложения является демонстрация динамического связывания и отображения при выяснении возможности подключения независимых двоичных блоков, созданных сторонними производителями.

    Снова подчеркнем, что здесь не рассматриваются детали процесса построения приложений Windows Forms. Тем не менее, предполагается, что вы поместите компонент MenuStrip в окно формы и определите с его помощью меню Сервис, которое будет содержать единственный пункт Подключаемый модуль (рис. 12.11).

    Рис. 12.11. Исходный графический интерфейс MyExtendableApp

    Эта форма Windows должна также содержать тип Listbox (которому здесь назначено имя lstLoadedSnapIns), используемый для отображения имен подключаемых модулей, загружаемых пользователем. На рис. 12.12 показан окончательный вид графического интерфейса приложения, о котором идет речь.

    Рис. 12.12. Окончательный вид графического интерфейса MyExtendableApp

    Программный код для обработки выбора Сервис>Подключаемый модуль из меню (этот программный код можно создать с помощью двойного щелчка на пункте меню в окне проектирования формы), отображает диалоговое окно Открытие файла и читает путь к выбранному файлу. Соответствующая строка пути затем посылается вспомогательной функции LoadExternalModule() для обработки. Метод возвращает false (ложь), если он не обнаруживает класс, реализующий IAppFunctionality.

    private void snapInModuleToolStripMenuItem_Click(object sender, EventArgs e) {

     // Позволяет пользователю выбрать компоновочный блок для загрузки.

     OpenFileDialog dlg = new OpenFileDialog();

     if (dlg.ShowDialog() == DialogResult.OK) {

      if (LoadExternalModule(dlg.FileName) == false) MessageBox.Show("Нет реализации IAppFunctionality!");

     }

    }

    Метод LoadExternalModule() решает следующие задачи.

    • Динамически загружает компоновочный блок в память.

    • Выясняет, содержит ли компоновочный блок тип, реализующий IAppFunctionality

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

    private bool LoadExternalModule(string path) {

     bool foundSnapIn = false;

     IAppFunctionality itfAppFx;

     // Динамическая загрузка выбранного компоновочного блока.

     Assembly theSnapInAsm = Assembly.LоadFrom(path);

     // Получение всех типов компоновочного блока.

     Tуре[] theTypes = theSnapInAsm.GetTypes();

     // Поиск типа с реализацией IAppFunctionality.

     for (int i = 0; i ‹ theTypes.Length; i++) {

      Type t = theTypes[i].GetInterface("IAppFunctionality");

      if (t != null) {

       foundSnapIn = true;

       // Динамическое связывание для создания типа.

       object о = theSnapInAsm.CreateInstance(theTypes[i].FullName);

       // Вызов DoIt() через интерфейс.

       itfAppFx = о as IAppFunctionality;

       itfAppFx.DoIt();

       lstLoadedSnapIns.Items.Add(theTypes[i].FullName);

      }

     }

     return foundSnapIn;

    }

    Теперь вы можете выполнить свое приложение. При выборе компоновочных блоков CSharpSnapIn.dll и VbNetSnapIn.dll вы должны увидеть соответствующее сообщение. На рис. 12.13 показан один из возможных вариантов выполнения.

    Рис. 12.13. Подключение внешних компоновочных блоков

    Завершающей задачей будет отображение метаданных, соответствующих атрибуту [CompanyInfo]. Для этого просто обновите LoadExternalModule(), чтобы перед выходом из контекста if вызывалась новая вспомогательная функция DisplayCompanyData(). Эта функция имеет один параметр типа System.Type.

    private bool LoadExternalModule(string path) {

     …

     if (t != null) {

      …

      // Отображение информации о компании.

      DisplayCompanyData(theTypes[i]);

     }

     return foundSnapIn;

    }

    Для поступающего на вход типа просто отобразите атрибут [CompanyInfo].

    private void DisplayCompanyData(Type t) {

     // Получение данных [CompanyInfo].

     object[] customAtts = t.GetCustomAttributes(false);

     // Вывод данных.

     foreach (CompanyInfoAttribute с in customAtts) {

      MessageBox.Show(с.Url, String.Format("Дополнительные сведения о {0} ищите по адресу", с.Name));

     }

    }

    Превосходно! На этом рассмотрение примера завершается. Я надеюсь, что к этому моменту нашего обсуждения вы осознаете, что подходы, представленные в этой главе, могут найти применение и на практике, а не только при разработке средств построения программ.

    Исходный код. Программный код приложений CommonSnappableTypes, CSharpSnapIn, VbNetSnapIn и MyExtendableApp размещен в подкаталоге, соответствующем главе 12.

    Резюме

    Сервис отображения оказывается весьма интересным аспектом построения надежного окружения при использовании объектно-ориентированного подхода. В среде .NET ключевыми элементами сервиса отображения являются тип System.Туре и пространство имен System.Reflection. Отображение представляет собой процесс выяснения основных характеристик и возможностей типа в среде выполнения.

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

    ГЛАВА 13. Процессы, домены приложений, контексты и хосты CLR

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

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

    Обладая пониманием того, как среда CLR обрабатывает компоновочный блок, мы с вами сможем выяснить, что такое хостинг CLR. Как уже говорилось в главе 1, сама среда CLR представляется (по крайней мере, отчасти) файлом mscoree.dll. При запуске выполняемого компоновочного блока файл mscoree.dll загружается автоматически, но, как вы сможете убедиться, в фоновом режиме при этом выполняется целый ряд шагов, скрытых от глаз пользователя.

    Выполнение традиционных процессов Win32

    Понятие "процесс" существовало в операционных системах Windows задолго до появления платформы .NET. Упрощенно говоря, термин процесс используется для обозначения множества ресурсов (таких, как внешние библиотеки программного кода и первичный поток) и выделяемой памяти, необходимых для работы приложения. Для каждого загруженного в память файла *.ехe операционная система создает отдельный и изолированный процесс, используемый в течение всего "жизненного цикла" соответствующего приложения. В результате такой изоляции приложений повышается надежность и устойчивость среды выполнения, поскольку отказ в ней одного процесса не влияет на функционирование другого.

    Каждому процессу Win32 назначается уникальный идентификатор PID (Process ID – идентификатор процесса), и процесс, при необходимости, может независимо загружаться или выгружаться операционной системой (или программными средствами с помощью вызовов Win32 API). Вы, возможно, знаете, что на вкладке Процессы в окне Диспетчер задан Windows (которое можно активизировать нажатием комбинации клавиш ‹Ctrl+Shift+Esc>) можно увидеть информацию о процессах, выполняющихся на машине, включая информацию PID и имя образа (рис. 13.1).

    Замечание. Если столбец PID в окне Диспетчер задач Windows не отображается, выберите в этом окне команду Вид>Выбрать столбцы… из меню и в открывшемся после этого окне установите флажок Идентификатор процесса (PID).

    Рис. 13.1. Диспетчер задач Windows

    Обзор потоков

    Каждый процесс Win32 имеет один главный "поток", выполняющий функции точки входа в приложение. В следующей главе будет выяснено, как создавать дополнительные потоки и соответствующий программный код, применяя возможности пространства имен System.Threading, но пока что для освещения вопросов, представленных здесь, нам нужно выполнить определенную вспомогательную работу. Во-первых, заметим, что поток – это "нить" выполнения в рамках данного процесса. Первый поток, созданный точкой входа процесса, называется первичным потоком. Приложения Win32 с графическим интерфейсом пользователя определяют в качестве точки входа приложения метод WinMain(). Консольные приложения для этой цели используют метод Main(). Процессы, состоящие из одного первичного потока, будут потокоустойчивыми, поскольку в них в каждый момент времени только один поток может получить доступ к данным приложения. Однако одно-поточный процесс (особенно если он основан на графическом интерфейсе) часто бывает "склонен" не отвечать пользователю при выполнении потоком достаточно сложных действий (например, связанных с печатью большого текстового файла, запутанными вычислениями или попытками соединиться с удаленным сервером).

    Учитывая эти потенциальные недостатки однопоточных приложений, Win32 API позволяет первичным потокам порождать дополнительные вторичные потоки (также называемые рабочими потоками), используя, например, такую удобную функцию Win32 API, как CreateThread(). Каждый поток (первичный или вторичный) в таком процессе становится уникальным элементом выполнения и получает доступ ко всем открытым элементам данных на условиях конкуренции.

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

    В реальности всегда следует учитывать то, что многопоточность является, по сути, иллюзией, обеспечиваемой операционной системой. Машины, основанные на одним процессоре, в действительности не способны обрабатывать несколько потоков одновременно. Вместо этого системы с одним процессором выделяют каждому потоку свою) часть времени (что называют квантованием времени) на основе уровня приоритета данного потока. Когда квант времени потока заканчивается, текущий поток приостанавливается, чтобы свою задачу мог выполнить другой поток. Чтобы поток "помнил", что происходило перед тем, как поток был временно "отодвинут в сторону", каждый поток получает возможность записать необходимые данные в блик TLS (Thread Local Storage – локальная память потока), и каждому потоку обеспечивается отдельный стек вызовов, как показано на рис. 13.2.

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

    Замечание. Новые процессоры Intel имеют особенность, называемую технологией НТ (Hyper-Threading Technology – гиперпотоковая технология), которая позволяет одному процессору при определенных условиях обрабатывать множество потоков одновременно. Подробности описания этой технологии можно найти по адресу http://www.intel.com/info/hyperthreading.

    Рис. 13.2. Взаимосвязь процесса и потоков Win32

    Взаимодействие с процессами в рамках платформы .NET

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

    Пространство имен System.Diagnostics определяет ряд типов, позволяющих программное взаимодействие с процессами, а также типов, связанных с диагностикой системы (например, с журналом регистрации системных событий и счетчиками производительности). В этой главе мы рассмотрим только те связанные с процессами типы, которые определены в табл. 13.1.

    Таблица 13.1. Избранные члены пространства имен System.Diagnostics

    Типы System.Diagnostics для поддержки процессов Описание
    Process Класс Process обеспечивает доступ к локальным и удаленным процессам, а также позволяет программно запускать и останавливать процессы
    ProcessModule Этот тип представляет модуль (*.dll или *.exe), загруженный в рамках конкретного процесса. При этом тип ProcessModule может представлять любой модуль – модуль COM, модуль .NET или традиционный двоичный файл C
    ProcessModuleCollection Предлагает строго типизованную коллекцию объектов ProcessModule
    ProcessStartlnfo Указывает множество значений, используемых при запуске процесса с помощью метода Process.Start()
    ProcessThread Представляет поток в рамках данного процесса. Тип ProcessThread используется для диагностики множества потоков процесса, а не для того, чтобы порождать новые потоки выполнения в рамках данного процесса
    ProcessThreadCollection Предлагает строго типизованную коллекцию объектов PrосessThread 

    Тип System.Diagnostics.Process позволяет проанализировать процессы, выполняемые на данной машине (локальной или удаленной). Класс Process предлагает также члены, которые позволяют запускать и останавливать процессы программными средствами, устанавливать уровни приоритета и получать список активных потоков и/или загруженных модулей, выполняемых в рамках данного процесса. В табл. 13.2 предлагается список некоторых (но не всех) членов System.Diagnostics.Process.

    Таблица 13.2. Избранные члены типа Process

    Член Описание
    ExitCode Свойство, содержащее значение, которое указывается процессом при завершении его работы. Для получения этого значения необходимо обработать событие Exited (при асинхронном уведомлении) или вызвать метод WaitForExit() (при синхронном уведомлении)
    ExitTime Свойство, содержащее штамп времени, соответствующий прекращению работы процесса (и представленный типом DateTime)
    Handle Свойство, возвращающее дескриптор, назначенный процессу операционной системой
    HandleCount Свойство, возвращающее число дескрипторов, открытых процессом
    Id Свойство, содержащее идентификатор процесса (PID) для данного процесса
    MachineName Свойство, содержащее имя компьютера, на котором выполняется данный процесс
    MainModule Свойство, получающее тип ProcessModule, который представляет главный модуль данного процесса
    MainWindowTitle MainWindowHandle Свойство MainWindowTitle получает заголовок главного окна процесса (если процесс не имеет главного окна, будет возвращена пустая строка). Свойство MainWindowHandle получает дескриптор (представленный типом System.IntPtr) соответствующего окна. Если процесс не имеет главного окна, типу IntPtr присваивается значение System.IntPtr.Zero
    Modules Свойство, обеспечивающее доступ к строго типизованной коллекции ProcessModuleCollection, представляющей множество модулей (*.dll или *.exe), загруженных в рамках текущего процесса
    PriorityBoostEnabled Это свойство указывает, должна ли операционная система временно ускорять выполнение процесса, когда его главное окно получает фокус ввода
    PriorityClass Свойство, позволяющее прочитать или изменить данные базового приоритета соответствующего процесса
    ProcessName Свойство, содержащее имя процесса (которое, как вы можете догадаться, соответствует имени приложения)
    Responding Значение этого свойства указывает, должен ли пользовательский интерфейс процесса реагировать на действия пользователя
    StartTime Свойство с информацией о времени, соответствующем старту данного процесса (эта информация представлена типом DateTime)
    Threads Свойство, получающее набор потоков, выполняющихся в рамках данного процесса (представляется массивом типов ProcessThread)
    CloseMainWindow() Метод, завершающий процесс с пользовательским интерфейсом путем отправки соответствующего сообщения о закрытии главного окна
    GetCurrentProcess() Статический метод, возвращающий тип Process, используемый для представления процесса, активного в настоящий момент
    GetProcesses() Статический метод, возвращающий массив компонентов Process, выполняющихся на данной машине
    Kill() Метод, немедленно прекращающий выполнение соответствующего процесса
    Start() Метод, начинающий выполнение процесса

    Список выполняемых процессов

    Чтобы привести пример обработки типов Process, предположим, что у нас есть консольное приложение C# ProcessManipulator, которое определяет следующий вспомогательный статический метод.

    public static void ListAllRunningProcesses() {

     // Получение списка процессов, выполняемых на данной машине.

     Process[] runningProcs = Process.GetProcesses(".");

     // Печать значения PID и имени каждого процесса.

     foreach(Process p in runningProcs) {

      string info = string.Format("-› PID: {0}\tИмя: {1}", p.Id, p.ProcessName);

      Console.WriteLine(info);

     }

     Console.WriteLine("*************************************\n");

    }

    Обратите внимание на то, что статический метод Process.GetProcesses() возвращает массив типов Process, представляющих процессы, запущенные на выполнение на целевой машине (используемая здесь точка обозначает локальный компьютер).

    После получения массива типов Process можно использовать любой из членов, приведенных в табл. 13.2. Здесь просто отображается значение PID и имя каждого из процессов. В предположении о том, что вы обновили метод Main() для вызова ListAllRunningProcesses(), в результате выполнения соответствующей программы вы должны увидеть нечто подобное показанному на рис. 13.3.

    Рис. 13.3. Перечень запущенных процессов

    Чтение данных конкретного процесса

    В дополнение к полному списку всех запущенных на данной машине процессов, статический метод Process.GetProcessById() позволяет прочитать данные отдельного процесса по его значению PID. Если запросить доступ к процессу по несуществующему значению PID, будет сгенерировано исключение ArgumentException. Так, чтобы получить объект Process, представленный значением PID, равным 987, можно написать следующее.

    // Если процесса с PID=987 нет, то среда выполнения

    // сгенерирует соответствующее исключение.

    static void Main(string[] args) {

     Process theProc;

     try {

      theProc = Process.GetProcessByld(987);

     } catch { // Общий блок catch для простоты.

      Console.WriteLine("-› Извините, некорректное значение PID!");

     }

    }

    Список множества потоков процесса

    Тип класса Process обеспечивает и способ программного получения множества всех потоков, используемых данным потоком в настоящий момент. Множество потоков представляется строго типизованной коллекцией ProcessThreadCollection, которая содержит соответствующий набор отдельных типов ProcessThread. Для примера предположим, что в наше текущее приложение была добавлена следующая вспомогательная статическая функция.

    public static void EnumThreadsForPid(int pID) {

     Process theProc;

     try {

      theProc = Process.GetProcessById(pID);

     } catch {

      Console.WriteLine("-› Извините, некорректное значение PID!");

      Console.WriteLine("************************************\n");

      return;

     }

     // Вывод информации для каждого потока указанного процесса.

     Console.WriteLine("Это потоки, выполняемые в рамках {0}", theProc.ProcessName);

     ProcessThreadCollection theThreads = theProc.Threads;

    foreach (ProcessThread pt in theThreads) {

     string info = string.Format("-› ID: {0}\tBpeмя запуска {1}\tПриоритет {2}", pt.Id, pt.StartTime.ToShortTimeString(), pt.PriorityLevel);

     Console.WriteLine(info);

    }

    Console.WriteLine("************************************\n").

    }

    Как видите, свойство Threads типа System.Diagnostics.Process обеспечивает доступ к классу ProcessThreadCollection. Здесь для каждого потока в рамках указанного клиентом процесса выводится назначенный потоку идентификатор ID, время запуска и приоритет. Обновите метод Main() программы для запроса у пользователя значения PID процесса так, как показано ниже.

    static void Main(string[] args) {

     …

     // Запрос PID у пользователя и вывод списка активных потоков.

     Console.WriteLine("***** Введите значение PID процесса *****");

     Console.Write("PID: ");

     string pID = Console.ReadLine();

     int theProcID = int.Parse(pID);

     EnumThreadsForPid(theProcID);

     Console.ReadLine();

    }

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

    Рис. 13.4. Перечень потоков в рамках выполняемого процесса

    Кроме членов Id, StartTime и PriorityLevel, тип ProcessThread имеет и другие члены, которые могут представлять интерес. Некоторые из таких членов приведены в табл. 13.3.

    Таблица 13.3. Подборка членов типа ProcessThread

    Член Описание
    BasePriority Читает значение базового приоритета потока
    CurrentPriority Читает значение текущего приоритета потока
    Id Читает уникальный идентификатор потока
    IdealProcessor Задает предпочтительный процессор для выполнения данного потока
    PriorityLevel Читает или задает уровень приоритета для данного потока
    ProcessorAffinity Задает процессоры, на которых может выполняться ассоциированный поток
    StartAddress Читает адрес в памяти для функции, которая вызывалась операционной системой для запуска данного потока
    StartTime Читает информацию о времени запуска данного потока операционной системой
    ThreadState Читает информацию о текущем состоянии потока
    TotalProcessorTime Читает общую оценку времени, в течение которого данный поток использовал процессор
    WaitReason Читает информацию о причине, по которой поток находится в ожидании

    Перед тем как двигаться дальше, следует заметить, что тип ProcessThread не является тем элементом, который можно использовать для создания, остановки или ликвидации потоков в рамках платформы .NET. Тип ProcessThread является средством получения диагностической информации об активных потоках Win32 в рамках выполняющихся процессов. То, как строить многопоточные приложения с помощью пространства имен System.Threading, мы с вами выясним в главе 14.

    Информация о наборе модулей процесса

    Теперь выясним, как выполнить цикл по всем модулям, загруженным в рамках данного процесса. Напомним, что модуль - это общее название, используемое для обозначения *.dll (или *.exe). При доступе к ProcessModuleCollection с помощью свойства Process.Module вы получаете перечень всех модулей, задействованных в рамках соответствующего процесса – модулей .NET, модулей COM и традиционных библиотек C. Рассмотрите следующую вспомогательную функцию, которая перечислит модули конкретного процесса, заданного с помощью PID.

    public static void EnumModsForPid(int pID) {

     Process theProc;

     try {

      theProc = Process.GetProcessById(pID);

     } catch {

      Console.WriteLine("-› Извините, некорректное значение PID!");

      Console.WriteLine("************************************\n");

      return;

     }

     Console.WriteLine("Загруженные модули для {0}:", theProc.ProcessName);

     try {

      ProcessModuleCollection theMods = theProc.Modules;

      foreach (ProcessModule pm in theMods) {

       string info = string.Format("-› Имя модуля: {0}", pm.ModuleName);

       Console.WriteLine(info);

      }

      Console.WriteLine("************************************\n");

     } catch {

      Console.WriteLine("Модулей не обнаружено!");

     }

    }

    Чтобы увидеть пример возможного вывода программы, давайте проверим затрушенные модули для. процесса, выполняемого в рамках рассматриваемого здесь консольного приложения ProcessManipulator. Для этого запустите приложение, выясните значениеPID, соответствующее ProcessManipulator.exe, и передайте это значение методу EnumModsForPid() (не забудьте соответствующим образом обновить метод Main(). Вы, наверное, удивитесь, увидев весь список модулей *.dll, которые используются для такого простого консольного приложения (atl.dll, mfc42u.dll, oleaut32.dll и т.д.). На рис. 13.5 показан результат запуска.

    Рис. 13.5. Перечень загруженных модулей в рамках выполняющегося процесса

    Начало и остановка процессов с помощью программных средств

    В завершение этого раздела мы рассмотрим методы Start() и Kill() типа System.Diagnostics.Process. По именам этих методов вы можете догадаться, что они обеспечивают, соответственно, программный запуск и программное завершение процесса. Рассмотрите, например, вспомогательный статический метод StartAndKillProcess().

    public static void StartAndKillProcess() {

     // Запуск Internet Explorer.

     Process ieProc = Process.Start("IExplore.exe", "www.intertechtraining.com");

     Console.Write("-› Нажмите ‹Enter›, чтобы завершить {0}…", ieProc.ProcessName);

     Console.ReadLine();

     // Завершение процесса iexplorer.exe.

     try {

      ieProc.Kill();

     } catch {} // Если пользователь уже завершил процесс.…

    }

    Статический метод Process.Start() является перегруженным. Как минимум, вы должны указать имя процесса, который следует запустить (например, Microsoft Internet Explorer). В этом примере используется вариация метода Start(), позволяющего указать любые дополнительные аргументы, передаваемые точке входа программы (т.е. методу Main()).

    Метод Start(), кроме того, позволяет передать тип System.Diagnostics. ProcessStartInfo, чтобы указать дополнительную информацию о том, как должен стартовать данный процесс. Вот формальное определение ProcessStartInfo (подробности можно найти в документации .NET Framework 2.0 SDK).

    public sealed class System.Diagnostics. ProcessStartInfo : object {

     public ProcessStartInfo();

     public ProcessStartInfo(string fileName);

     public ProcessStartInfo(string fileName, string arguments);

     public string Arguments { get; set; }

     public bool CreateNoWindow { get; set; }

     public StringDictionary EnvironmentVariables { get; }

     public bool ErrorDialog { get; set; }

     public IntPtr ErrorDialogParentHandle { get; set; }

     public string FileName { get; set; }

     public bool RedirectStandardError { get; set; }

     public bool RedirectStandardInput { get; set; }

     public bool RedirectStandardOutput { get; set; }

     public bool UseShellExecute { get; set; }

     public string Verb { get; set; }

     public string[] Verbs { get; }

     public ProcessWindowStyle WindowStyle { get; set; }

     public string WorkingDirectory { get; set; }

     public virtual bool Equals(object obj);

     public virtual int GetHashCode();

     public Type GetType();

     public virtual string ToString();

    }

    Независимо от того, какую версию метода Process.Start() вы вызовете, будет возвращена ссылка на новый активизированный процесс. Чтобы завершить выполнение процесса, просто вызовите метод Kill() уровня экземпляра.

    Исходный код. Проект ProcessManipulator размещен в подкаталоге, соответствующем главе 13.

    Домены приложений .NET

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

    • Домены приложения являются ключевым аспектом независимой от ОС природы платформы .NET, поскольку такое логическое деление абстрагируется от того, как именно ОС представляет загруженный выполняемый объект.

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

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

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

    Хотя один процесс и может принять множество доменов приложения, так бывает не всегда. Как минимум, процесс ОС будет содержать то, что обычно называют доменом приложения, созданным по умолчанию. Этот специальный домен приложения автоматически воздается средой CLR во время запуска процесса.

    После этого CLR создает дополнительные домены приложения по мере необходимости, Если потребуется (хотя это и маловероятно), вы можете программно создавать домены приложения в среде выполнения в рамках выполняемого процесса, используя статические методы класса System.AppDomain. Этот класс оказывается также полезным для осуществления низкоуровневого контроля доменов приложения. Основные члены этого класса описаны в табл. 13.4.

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

    Таблица 13.4. Основные члены класса AppDomain

    Член Описание
    CreateDomain() Статический метод, с помощью которого создается новый домен приложения в данном процессе. Среда CLR сама создает новые домены приложения по мере необходимости, поэтому вероятность того, что вам понадобится вызывать этот член, близка к нулю
    GetCurrentThreadId() Статический метод, возвращающий ID активного потока в данном домене приложения
    Unload() Еще один статический метод, позволяющий выгрузить указанный домен приложения для данного процесса
    BaseDirectory Свойство, возвращающее базовый каталог, используемый при поиске зависимых компоновочных блоков
    CreateInstance() Метод, создающий экземпляр указанного типа, определенного в указанном файле компоновочного блока
    ExecuteAssembly() Метод, выполняющий компоновочный блок в рамках домена приложения, заданного именем файла
    GetAssemblies() Метод, который читает список компоновочных блоков .NET, загруженных в данном домене приложения (двоичные файлы COM и C игнорируются)
    Load() Метод, используемый для динамической загрузки компоновочного блока в рамках данного домена приложения

    Таблица 13.5. События типа AppDomain

    Событие Описание
    AssemblyLoad Возникает при загрузке компоновочного блока
    AssemblyResolve Возникает, когда не удается идентифицировать компоновочный блок
    DomainUnload Возникает перед началом выгрузки домена приложения
    ProcessExit Возникает для домена приложения, созданного по умолчанию, когда завершается родительский процесс этого домена
    ResourceResolve Возникает, когда не удается идентифицировать ресурс
    TypeResolve Возникает, когда не удается идентифицировать тип
    UnhandledException Возникает, когда остается без обработки сгенерированное исключение

    Список доменов приложения процесса

    Для примера программного взаимодействия с доменами приложений .NET предположим, что у нас есть новое консольное приложение C# с именем AppDomainManipulator, в рамках которого определяется статический метод PrintAllAssembliesInAppDomain(). Этот вспомогательный метод использует AppDomain.GetAssemblies(), чтобы получить список всех двоичных файлов .NET, выполняющихся в рамках данного домена приложения.

    Соответствующий список представляется массивом типов System.Reflection. Assembly, поэтому необходимо использовать пространство имен System. Reflection (см. главу 12). Получив массив компоновочных блоков, вы выполняете цикл по элементам массива и печатаете понятное имя и версию каждого модуля.

    public static void PrintAllAssembliesInAppDomain(ApsDomain ad) {

     Assembly[] loadedAssemblies = ad.GetAssemblies();

     Console.WriteLine("*** Компоновочные блоки в рамках {0} ***\n", ad.FriendlyName);

     foreach (Assembly a in loadedAssemblies) {

      Console.WriteLine("-Имя: {0}", a.GetName().Name);

      Console.WriteLine("-› Версия: {0}\n", a.GetName().Version);

     }

    }

    Теперь обновим метод Main(), чтобы перед вызовом PrintAllAssembliesInAppDomain() получить ссылку на текущий домен приложения, используя свойство AppDomain.CurrentDomain.

    Чтобы сделать пример более интересным, метод Main() открывает окно сообщения Windows Forms (для этого среда CLR должна загрузить компоновочные блоки System.Windows.Forms.dll, System.Drawing.dll и System.dll, так что не забудьте установить ссылки на эти компоновочные блоки и соответственно изменить набор операторов using).

    static void Main(string[] args) {

     Console.WriteLine("***** Чудесное приложение AppDomain *****\n");

     // Чтение информации для текущего AppDomain.

     AppDomain defaultAD= AppDomain.CurrentDomain;

     MessageBox.Show(''Привет");

     PrintAllAssembliesInAppDomain(defaultAD);

     Console.ReadLine();

    }

    На рис. 13.6 показан соответствующий вывод (номера версий у вас могут быть другими).

    Рис. 13.6. Перечень компоновочных блоков в рамках текущего домена приложений

    Программное создание новых доменов приложения

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

    static void Main(string[] args) {

     …

     // Создание нового AppDomain в рамках текущего процесса.

     AppDomain anotherAD = AppDomain.CreateDomain("SecondAppDomain");

     PrintAllAssembliesInAppDomain(anotherAD);

     Console.ReadLine();

    }

    Если выполнить приложение теперь (рис. 13.7), вы увидите, что компоновочные блоки System.Windows.Forms.dll, System.Drawing.dll и System.dll будут загружены только в рамках домена приложения, созданного по умолчанию. Это может показаться нелогичным для тех. кто имеете опыт программирования с использованием традиционных подходов Win32 (скорее, оба домена приложения должны иметь доступ к одному и тому же множеству компоновочных блоков). Напомним, однако, о том. что компоновочный блок загружается в рамки домена приложения а не в рамки непосредственно самого процесса.

    Рис. 13.7. Один процесс с двумя доменами приложения

    Далее, обратите внимание на то, что домен приложения SecondAppDomain автоматически получает свою собственную копию mscorlib.dll, поскольку этот ключевой компоновочный блок автоматически загружается средой CLR для каждого домена приложения. Это порождает следующий вопрос "Как можно программно загрузить компоновочный блок в домен приложения?" Ответ: с помощью метода АррDomain.Load() (или, альтернативно, с помощью AppDomain.executeAssembly()). В предположении, что вы скопировали CarLibrary.dll в каталог приложения AppDomainManipulator.exe, вы можете загрузить CarLibrary.dll в домен приложения SecondAppDomain так.

    static void Main(string[] args) {

     Console.WriteLine("***** Чудесное приложение AppDomain *****\n");

     …

     // Загрузка CarLibrary.dll в новый AppDomain.

     AppDomain anotherAD = AppDomain.CreateDomain("SecondAppDomain");

     anotherAD.Load("CarLibrary");

     PrintAllAssembliesInAppDomain(anotherAD);

     Console.ReadLine();

    }

    Чтобы закрепить понимание взаимосвязей между процессами, доменами приложения и компоновочными блоками, рассмотрите рис. 13.8, на котором представлена диаграмма внутреннего устройства только что построенного процесса AppDomainManipulator.exe.

    Рис. 13.8. Схема функционирования процесса AppDomainManipulator.exe

    Программная выгрузка доменов приложения

    Важно понимать, что среда CLR не позволяет выгружать отдельные компоновочные блоки .NET. Однако, используя метод AppDomain.Unload(), вы можете избирательно выгрузить домен приложения из объемлющего процесса. При этом домен приложения выгрузит по очереди каждый компоновочный блок.

    Напомним, что тип AppDomain определяет набор событий, одним из которых является DomainUnload. Это событие генерируется тогда, когда домен приложения (не являющийся доменом, созданным по умолчанию) выгружается из содержащего этот домен процесса. Другим заслуживающим внимания событием является событие ProcessExit, которое генерируется при выгрузке из процесса домена, создаваемого по умолчанию (что, очевидно, влечет за собой завершение всего процесса). Так, если вы хотите программно выгрузить anotherAD из процесса AppDomainManipulator.exe и получить извещение о том, что соответствующий домен приложения закрыт, можете использовать следующую программную логику событий.

    static void Main(string[] args) {

     …

     // Привязка к событию DomainUnload.

     anotherAD.DomainUnload += new EventHandler(anotherAD_DomainUnload);

     // Теперь выгрузка anotherAD.

    AppDomain.Unload(anotherAD);

    }

    Обратите внимание на то, что событие DomainUnload работает в паре с делегатом System.EventHandler, поэтому формат anotherAD_DomainUnload() требует следующих аргументов.

    public static void anotherAD_DomainUnload(object sender, EventArgs e) {

     Console.WriteLine("***** Выгрузка anotherAD! *****\n");

    }

    Если вы хотите получить извещение при выгрузке домена приложения, созданного по умолчанию, измените метод Main() так, чтобы обработать событие ProcessEvent, соответствующее домену приложения по умолчанию:

    static void Main(string [] args) {

     …

     AppDomain defaultAD = AppDomain.CurrentDomain;

     defaultAD.ProcessExit +=new EventHandler(defaultAD_ProcessExit);

    }

    и определите подходящий обработчик событий.

    private static void defaultAD_ProcessExit (object sender, EventArgs e) {

     Console.WriteLine("***** Выгрузка defaultAD! *****\n");

    }

    Исходный код. Проект AppDomainManipulator размещен в подкаталоге, соответствующем главе 13.

    Границы контекста объекта

    Итак, вы могли убедиться, что домены приложения – это логические разделы в рамках процесса, предназначенные для загрузки компоновочных блоков .NET. Домен приложения, в свою очередь, можно делить дальше на контекстные области со своими границами. В сущности, контекст .NET обеспечивает домену приложения возможность создать "Отдельную комнату" для данного объекта.

    Используя контекст, среда CLR может гарантировать, что объекты, которые выдвигают специальные требования в среде выполнении, будут обработаны надлежащим образам и в нужном порядке, поскольку для этого среда использует перехват вызовов, пересекающих границу контекста. Слой перехвата позволяет среде CLR корректировать текущие вызовы методов в соответствии с контекстно-зависимыми установками данного объекта. Например, если вы определите тип класса C#, требующий автоматической поддержки множества потоков (используя атрибут [Synchronization]), то среда CLR при его размещении создаст "синхронизированный контекст".

    Точно так же, как процесс определяет создаваемый по умолчанию домен приложения, каждый домен приложения имеет создаваемый по умолчанию контекст. Этот создаваемый по умолчанию контекст (на который иногда ссылаются, как на контекст 0, поскольку он всегда оказывается первым контекстом, создаваемым в домене приложений) применяется для тех объектов .NET, которые не имеют никаких особых или уникальных контекстных требований. Вы вправе ожидать, что подавляющее большинство объектов .NET должно загружаться в контекст 0. Когда среда CLR определяет новый объект, имеющий специальные требования, создаются новые границы контекста в рамках объемлющего домена приложения. На рис. 13.9 показана схема взаимодействия процесса, доменов приложения и контекстов.

    Рис. 13.9. Процессы, домены приложения и границы контекста

    Контекстно-независимые и контекстно-связанные типы

    Типы .NET которые не предъявляют никаких специальных контекстных требований, называются контекстно-независимыми объектами. Эти объекты доступны из любого места в рамках соответствующего домена приложения, без каких бы то ни было особых требований к среде выполнения. Построение контекстно-независимых объектов не требует больших усилий, поскольку ничего специального делать не приходится (в частности, не требуется наделять тип контекстными атрибутами или получать производные базового класса System.ContextBoundObject).

    // Контекстно-независимый объект загружается в контекст 0.

    public class SportsCar()

    С другой стороны, объекты, которые требуют контекстного размещения, называются контекстно-связанными объектами, и они должны быть производными от базового класса System.ContextBoundObject. Этот базовый класс закрепляет тот факт, что соответствующий объект сможет правильно функционировать только в рамках контекста, в котором он был создан. С учетом роли контекста .NET должно быть ясно, что в случае, когда контекстно-связанный объект оказывается в несоответствующем контексте, в любой момент могут возникнуть проблемы.

    Вдобавок к необходимости получения типа из System.ContextBoundObject, контекстно-связанный тип будет наделен рядом специальных атрибутов .NET, называемых контекстными атрибутами (что вполне логично). Все контекстные атрибуты получаются из базового класса. System.Runtime.Remoting.Contexts. ContextAttribute:

    public class System.Runtime.Remoting.Contexts.ContextAttribute: Attribute, IContextAttribute, IContextProperty {

     public ContextAttribute(string name);

     public string Name { virtual get; }

     public object TypeId { virtual get; }

     public virtual bool Equals(object o);

     public virtual void Freeze(System.Runtime.Remoting.Contexts.Context newContext);

     public virtual int GetHashCode();

     public virtual void GetPropertiesForNewContext(System.Runtime.Remoting.Activation.IConstructionCallMessage сtorMsg);

     public Type GetType();

     public virtual bool IsContextOK(System.Runtime.Remoting.Contexts.Context ctx, System.Runtime.Remoting.Activation.IConstructionCallMessage ctorMsg);

     public virtual bool IsDefaultAttribute();

     public virtual bool IsNewContextOK(System.Runtime.Remoting.Contexts.Context newCtx);

     public virtual bool Match(object obj);

     public virtual string ToString();

    }

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

    Замечание. В этой книге не рассматриваются подробности создания пользовательских контекстов объектов, но если вы заинтересованы узнать об этом больше, прочитайте книгу Applied .NET Attributes (Apress, 2003).

    Определение контекстно-связанных объектов

    Чтобы определить класс (SportsCarTS), автоматически поддерживающий потоковую безопасность, без добавления в него сложной логики синхронизации патока при реализации членов, следует взять объект, производный от ContextBoundObject, и применить атрибут [Synchronization], как показано ниже.

    using System.Runtime.Remoting.Contexts;

    // Этот контекстно-связанный тип будет загружен только

    // в синхронизированном (т.е. многопоточном) контексте.

    [Synсhronization]

    public class SportsCarTS: ContextBoundObject{}

    Типы с атрибутом [Synchronization] загружаются в контексте сохранения потоков. С учетом специальных контекстуальных требований типа класса MyThreadSafeObject представьте себе те проблемы, которые должны возникнуть, если размещенный объект перевести из синхронизированного контекста в несинхронизированный. Объект вдруг перестанет быть защищенным в отношении потоков и превратится в потенциального нарушителя целостности данных, поскольку другие потоки могут пытаться взаимодействовать с этим ссылочным объектом (теперь уже не сохраняющим потоки). Для гарантии того, что среда CLR не переместит объекты SportsCarTS за рамки синхронизированного контекста, достаточно взять объект, производный от ContextBoundObject.

    Проверка контекста объекта

    Из тех приложений, которые вы построите сами, очень немногие могут потребовать программного взаимодействия с контекстом, но вот вам пример для иллюстрации подхода, о котором идет речь. Создайте новое консольное приложение с именем ContextManipulator. Это приложение будет определить один контекстно-независимый класс (SportsCar) и один контекстно-связанный (SportsCarTS).

    using System.Runtime.Remoting.Contexts; // Для типа Context.

    using System.Threading; // Для типа Thread.

    // Тип SportsCar не имеет специальных контекстных требований

    // и будет загружен в рамках контекста, создаваемого доменом

    // приложения по умолчанию.

    public class SportsCar {

     public SportsCar() {

      // Чтение информации и вывод идентификатора контекста.

      Context ctx = Thread.CurrentContext;

      Console.WriteLine("{0} объект в контексте {1}", this.ToString(), ctx.ContextID);

      foreach (IContextProperty itfCtxProp in ctx.ContextProperties) Console.WriteLine("-› Свойство контекста: {0}", itfCtxProp.Name);

     }

    }

    // Тип SportsCarTS требует загрузки

    // в синхронизированном контексте.

    [Synchronization]

    public class SportsCarTS: ContextBoundObject {

     public SportsCarTS() {

      // Чтение информации и вывод идентификатора контекста.

      Context ctx = Thread.CurrentContext;

      Console.WriteLine("{0} объект в контексте {1}", this.ToString(), ctx.ContextID);

      foreach(IContextProperty itfCtxProp in ctx.ContextProperties) Console.WriteLine("-› Свойство контекста: {0}", itfCtxProp.Name);

     }

    }

    Обратите внимание на то. что каждый конструктор получает тип Context от текущего потока выполнения через статическое свойство Thread.CurrentContext. Используя объект Context, вы можете распечатать информацию о границах контекста, например, значение ID контекста или значения дескрипторов, полученных через Context.ContextProperties. Это свойство возвращает объект, реализующий интерфейс IContextProperty, который обеспечивает доступ к дескрипторам с помощью свойства Name. Теперь обновите метод Main(), чтобы разместить по экземпляру каждого из типов класса.

    static void Main(string[] args) {

     Console.WriteLine("*** Чудесное контекстное приложение ***\n");

      // При создании объекты будут отображать информацию контекста.

     SportsCar sport = new SportsCar();

     Console.WriteLine();

     SportsCar sport2 = new SportsCar();

     Console.WriteLine();

     SportsCarTS synchroSport = new SportsCarTS();

     Console.ReadLine();

    }

    По мере создания объектов конструкторы классов отображают различные элементы информации о контексте (рис. 13.10).

    Рис. 13.10. Исследование контекста объекта

    Для класса SportsCar не был указан атрибут контекста, поэтому среда CLR размещает sport и sport2 в контексте 0 (т.е. в контексте, созданном по умолчанию). Однако объект SportsCarTS загружается в свои уникальные контекстуальные границы (которым назначается идентификатор 1), поскольку для этого контекстно-связанного типа был указан атрибут [Synchronization].

    Исходный код. Проект ContextManipulator размещен в подкаталоге, соответствующем главе 13.

    Еще несколько слов о процессах, доменах приложения и контекстах

    К этому моменту вы должны лучше понимать, как среда CLR обрабатывает компоновочные блоки .NET. Вот на что следует обратить внимание.

    • Процесс .NET может содержать один или несколько доменов приложения. Каждый домен приложения может принять любое число связанных компоновочных блоков .NET и независимо загружаться и выгружаться средой CLR (или программистом с помощью типа System.AppDomain).

    • Любой домен приложения состоит из одного или нескольких контекстов. Используя контексты, среда CLR может поместить объект со "специальными требованиями" в логический контейнер, чтобы гарантировать выполнение этих требований в среде выполнения.

    Если предыдущее обсуждение кажется вам слишком сложным и далеким от практики, не волнуйтесь. По большей части среда выполнения .NET автоматически разрешает вопросы процессов, доменов приложений и контекстов, не требуя вашего вмешательства. Тем не менее представленная здесь информация обеспечивает "твердую основу" для понимания принципов многопоточного программирования в рамках платформы .NET. Но перед тем, как перейти к изучению пространства имен System.Threading, мы попытаемся выяснить, как сама среда CLR обрабатывается операционной системой Win32.

    Хостинг общеязыковой среды выполнения

    Для конечного пользователя запуск выполняемого блока .NET доступен с помощью простого двойного щелчка на соответствующем файле *.exe в окне программы Проводник (или активизации соответствующего ярлыка). Но вы должны помнить из главы 1, что каркас .NET Framework (пока что) не интегрирован непосредственно в ОС Windows, а опирается на ОС. Во время установки Visual Studio 2005 (или .NET Framework 2.0 SDK) на вашу машину устанавливается и окружение среды выполнения .NET (включая все необходимые библиотеки базовых классов). Также напомним, что Microsoft предлагает свободно доступную программу установки (dotnetfx.exe) среды выполнения .NET, позволяющую настроить машину конечного пользователя на поддержку компоновочных блоков .NET.

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

    1. ОС Windows загружает выполняемый двоичный файл в память.

    2. ОС Windows читает встроенный заголовок WinNT, чтобы определить (по флагу IMAGE_DIRECTORY_ENTRY_COM_DESCRIPTOR), является ли двоичный файл компоновочным блоком .NET.

    3. Если образ является компоновочным блоком .NET, загружается mscoree.dll.

    4. Затем mscoree.dll загружает одну из двух реализаций CLR (mscorwks.dll или mscorsvr.dll).

    5. В этот момент ответственность за выполнение "принимает на себя" среда CLR, выполняющая все связанные с .NET задачи (поиск внешних компоновочных блоков, выполнение проверок безопасности, обработка CIL-кода, сборка мусора и т.д.).

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

    Параллельное выполнение CLR

    "Копнув" чуть глубже, мы увидим, что платформа .NET поддерживает параллельное выполнение, т.е. на одной машине можно установить несколько версий платформы .NET (во время создания этой книги были доступны версии 1.0.1.1 и 2.0). Сам файл mscoree.dll размещается в подкаталоге System32 каталога установки Windows. Например, на моей машине mscoree.dll "проживает" в каталоге C:\WINDOWS\system32 (рис. 13.11).

    Рис. 13.11. Файл mscoree.dll находится в каталоге system32

    После загрузки mscoree.dll по реестру системы Win32 (да, по реестру этой системы) выясняется номер последней из установленных версий и путь установки .NET Framework (используется ветвь HKEY_LOCAL_MACHINE\Software\Microsoft\.NETFramework, рис. 13.12).

    Рис. 13.12. Выяснение версии и пути установки платформы .NET

    После определения версии и пути установки платформы .NET в память загружается нужная версия mscorwks.dll/mscorsvr.dll. На моей машине корневым путем установки платформы .NET является C:\WINDOWS\Microsoft.NET\Frаmеwork. В указанном каталоге есть специальные подкаталоги для .NET версии 1.0.1.1 и (на время создания книги) текущей версии 2.0 (см. рис. 13.13, ваши номера версий могут быть другими).

    Загрузка конкретной версии CLR

    Когда mscoree.dll определяет (с помощью реестра системы), какую версию mscorwks.dll/mscorsrv.dll загрузить, читается также раздел Policy (Политика) ветви HKEY_LOCAL_MACHINE\Software\Microsoft\.NETFramework реестра. В этот раздел записывается информация обновлений CLR, которые могут выполняться с безопасностью. Например, если запускается компоновочный блок, который был построен с использованием .NET версии 1.0.3.705, mscoree.dll узнает из файла политики, что вполне безопасно загрузить версию 1.1.4322.

    Рис. 13.13. Файл mscorwks.dll версии 2.0

    Все это происходит незаметно в фоновом режиме и только тогда, когда известно, что обновление обеспечивает правильное выполнение. В редких случаях возникает необходимость заставить mscoree.dll загрузить конкретную версию CLR, и тогда вы можете использовать для этого файл *.config клиента.

    ‹?xml version="l.0" encoding="utf-8"?›

     ‹configuration›

      ‹startup›

       ‹requiredRuntime version ="1.0 .3705"/›

      ‹/startup›

    ‹/configuration›

    Здесь элемент ‹requiredRuntime› указывает, что для загрузки данного компоновочного блока следует использовать только версию 1.0.3705. Поэтому, если на целевой машине нет полной инсталляции .NET версии 1.0.3705, конечный пользователь увидит окно с информацией об ошибке среды выполнения, показанное на рис. 13.14.

    Рис. 13.14. Элемент ‹requiredRuntime› порождает сообщение об ошибке среды выполнения, если указанная версия CLR не установлена[2]

    Дополнительные хосты CLR

    Только что описанный процесс обозначил основные шаги, предпринимаемые операционной системой Windows для хостинга CLR по умолчанию, когда запускается выполняемый компоновочный блок. Но Microsoft предлагает множество приложений, которые могут действовать в обход используемого по умолчанию поведения, используя программную загрузку CLR. Например. Microsoft Internet Explorer может загружать своими встроенными средствами пользовательские элементы управления Windows Forms (управляемый эквивалент теперь уже устаревших элементов управления ActiveX). Последняя версия Microsoft SQL Server (с кодовым названием Yukon и официальным названием SQL Server 2005) также способна осуществлять непосредственный хостинг CLR.

    Наконец. Microsoft определила набор интерфейсов, позволяющих разработчикам строить их собственные пользовательские хосты CLR. Это можно сделать, используя соответствующий программный код C/C++ или библиотеку COM-типа (mscorеe.tlb). Хотя сам процесс построения пользовательского хоста CLR исключительно прост (особенно при использовании библиотеки COM-типа), эта тема выходит за рамки нашего обсуждения. Если вам нужна дополнительная информация по данному вопросу, в Сети вы можете найти множество статей на эту тему (просто выполните поиск по ключу "CLR hosts").

    Резюме

    Целью этой главы было выяснение того, как обрабатывается выполняемый образ .NET. Вы имели возможность убедиться в том, что уже привычное понятие процесса Win32 было внутренне изменено с тем, чтобы адаптировать его к требованиям CLR. Отдельный процесс (которым можно программно управлять с помощью типа System.Diagnostiсs.Process) теперь компонуется из множества доменов приложения, имеющих изолированные и независимые границы в рамках этого процесса. Один процесс может содержать множество доменов приложения, каждый из которых может обрабатывать и выполнять любое число связанных компоновочных блоков.

    Кроме того, каждый домен приложения может содержать любое число контекстов. Используя этот дополнительный уровень изоляции типов, среда CLR может гарантировать, что объекты со специальными требованиями будут обработаны корректно. Глава завершается рассмотрением деталей того, как сама CLR обрабатывается операционной системой Win32.

    ГЛАВА 14. Создание многопоточных приложений

    В  предыдущей главе мы рассмотрели взаимосвязь между процессами, доменами приложения и контекстами. В этой мы выясним, как в рамках платформы .NET строить многопоточные приложения и как в условиях множества потоков гарантировать целостность совместно используемых ресурсов.

    Наше обсуждение снова начнется с рассмотрении типа делегата .NET, чтобы прийти к пониманию его внутренней поддержки асинхронных вызовов методов. Вы увидите, что такой подход позволяет автоматически вызвать метод во вторичном потоке выполнения. Затем мы исследуем типы пространства имен System.Тhreading. Будет рассмотрено множество типов (Thread.ThreadStart и т.д.), позволяющих с легкостью создавать дополнительные потоки. Конечно, сложность разработки многопоточных приложений заключается не в создании потоков, а в гарантии того, что ваш программный код будет иметь надежные средства обработки конфликтов при конкурентном доступе к общедоступным ресурсам. Поэтому завершается глава рассмотрением различных примитивов синхронизации, предлагаемых каркасом .NET Framework.

    Взаимосвязь процессов, доменов приложений, контекстов и потоков

    В предыдущей главе обсуждалось понятие потока, который был определен, как путь исполнения в рамках выполняемого приложения. И хотя многие приложения .NET имеют только один поток и, тем не менее, оказываются очень полезными, первичный поток компоновочного блока (порождаемый средой CLR при выполнении Main()) может создавать вторичные потоки для решения дополнительных задач. Реализуя дополнительные потоки, вы можете строить приложения с лучшим откликом на действия пользователя (но не обязательно более быстро выполняющие свои задачи).

    Пространство имен System.Threading содержит различные типы, позволяющие создавать многопоточные приложения. Основным типом здесь можно считать класс Thread, поскольку он представляет данный поток. Чтобы программно получить ссылку на поток, выполняющий данный член в текущий момент, просто вызовите статическое свойство Thread.CurrentThread.

    private static void ExtractExecutingThread() {

     // Получение потока, выполняющего

     // в данный момент данный метод.

    Thread currThread = Thread.CurrentThread;

    }

    Для платформы .NET не предполагается прямого однозначного соответствия между доменами приложения и потоками. Напротив, домен приложения может иметь множество потоков, выполняющихся в рамках этого домена в любой момент времени. Кроме того, конкретный поток не привязан к одному домену приложения в течение всего времени существования потока. Потоки могут пересекать границы домена приложения, подчиняясь правилам потоков Win32 и целесообразности CLR.

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

    private static void ExtractAppDomainHostingThread() {

     // Получение домена приложения, содержащего текущий поток.

     AppDomain ad = Thread.GetDomain();

    }

    Любой поток в любой момент времени также может быть перемещен средой CLR в любой из имеющихся контекстов или помещен в новый контекст. Чтобы получить текущий контекст, в рамках которого оказался поток, используйте статическое свойство Thread.CurrentContext.

    private static void ExtractCurrentThreadContext() {

     // Получение контекста, в рамках которого

     // действует текущий поток.

    Context ctx = Thread.CurrentContext;

    }

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

    Проблема конкуренции и роль синхронизации потоков

    Одним из множества "преимуществ" (читайте источников проблем) многопоточного программирования является то, что вы имеете очень узкие возможности контроля в отношении использования потоков операционной системой и средой CLR. Например, построив блок программного кода, создающий новый поток выполнения, вы не можете гарантировать, что этот поток начнет выполняться немедленно. Скорее, такой программный код только "даст инструкцию" операционной системе начать выполнение потока как можно быстрее (что обычно означает момент, когда наступит очередь этого потока у планировщика потоков).

    Кроме того, поскольку потоки могут перемещаться между границами приложения и контекста по требованию CLR, вы должны, следить за тем, какие элементы вашего приложения открыты влиянию потоков (т.е. позволяют доступ множества потоков), а какие операции оказываются атомарными (операции, открытые для множества потоков, потенциально опасны!). Для примера предположим, что поток вызывает некоторый метод конкретного объекта. Предположим также, что после этого поток, получает инструкцию от планировщика потоков приостановить выполнение, чтобы позволить другому потоку доступ к тому же методу того же объекта.

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

    Атомарные операции, с другой стороны, всегда безопасны в многопоточном окружении. К сожалению, только для очень небольшого числа операций из библиотек базовых классов .NET можно гарантировать, что эти операции будут атомарными. Не является атомарной даже операция присваивание значения члену-переменной! Если в документации .NET Framework 2.0 SDK в отношении какой-либо операции специально не оговорено, что данная операция является атомарной, вы должны предполагать, что эта операция является открытой влиянию потоков и принимать специальные меры предосторожности.

    Теперь вам должно быть ясно, что домены многопоточного приложения тоже открыты влиянию потоков, поскольку потоки могут пытаться использовать доступные функциональные возможности одновременно. Чтобы защитить ресурсы приложения от возможных искажении, разработчикам .NET приходится использовать так называемые примитивы потоков (такие, как блокировки, мониторы и атрибут [Synchronization]), чтобы контролировать доступ выполняемых потоков.

    Нельзя утверждать, что платформа .NET исключила все трудности, возникающие при построении устойчивых многопоточных приложений, но теперь этот процесс значительно упрощён. Используя типы, определенные в пространстве имен System.Threading, вы получаете возможность создавать дополнительные потоки с минимальными усилиями и минимальными проблемами. Точно так же, когда приходит время блокировать открытые элементы данных, вы можете использовать дополнительные типы, которые обеспечивают те же функциональные возможности, что и примитивы потоков Win32 API (но при этом используется намного более аккуратная объектная модель).

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

    Краткий обзор делегатов .NET

    Напомним, что тип делегата .NET – это обеспечивающий типовую безопасность объектно-ориентированный указатель функции. Когда вы объявляете делегат .NET, компилятор C# отвечает на это созданием изолированного класса, полученного из System.MulticastDelegate (который, в свою очередь, является производным от System.Delegate). Эти базовые классы наделяют каждый делегат способностью поддерживать список адресов методов, которые могут быть вызваны позднее. Давайте рассмотрим декларацию делегата BinaryOp, который был впервые определен в главе 8.

    // Тип делегата C#.

    public delegate int BinaryOp(int x, int y);

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

    sealed class BinaryOp: System.MulticastDelegate {

     public BinaryOp(object target, uint functionAddress);

     public void Invoke(int x, int y);

     public IAsyncResult BeginInvoke(int x, int y, AsyncCallback cb, object state);

     public int EndInvoke(IAsyncResult result);

    }

    Напомним, что генерируемый метод Invoke() используется для вызова методов, обслуживаемых объектом делегата в синхронном режиме. В этом случае вызывающий поток (например, первичный поток приложения) вынужден ждать, пока не завершится вызов делегата. Также напомним, что в C# метод Invoke() не вызывается в программном коде явно, а запускается в фоновом режиме при использовании "нормального синтаксиса" вызова метода. Рассмотрите следующий программный код, в котором статический метод Add() вызывается в синхронной (т.е. блокирующей) форме.

    // Это требуется для вызова Thread.Sleep().

    using System.Threading;

    using System;

    namespace SyncDelegate {

     public delegate int BinaryOp(int x, int y);

     class Program {

      static void Main(string[] args) {

       Console.WriteLine("***** Синхронный вызов, делегата *****");

       // Вывод ID выполняемого потока.

       Console.WriteLine("Вызван Main() в потоке {0}.", Thread.CurrentThread.GetHashCode());

       // Вызов Add() в синхронной форме.

       BinaryOp b = new BinaryOp(Add);

       int answer = b(10, 10);

       // Эти строки не будут выполнены до завершения

       // работы метода Add().

       Console.WriteLine("В Main() еще есть работа!");

       Console.WriteLine("10 + 10 равно {0}.", answer);

       Console.ReadLine();

      }

      static int Add(int x, int y) {

       // Вывод ID выполняемого потока.

    Console.WriteLine("Вызван Add() в потоке {0}.", Thread.CurrentThread.GetHashCode());

       // Пауза примерно 5 секунд для

       // имитации длительной операции.

       Thread.Sleep(5000);

       return x + у;

      }

     }

    }

    Сначала заметим, что в этой программе используется пространство имен System.Threading. В методе Add() вызывается статический метод Thread.Sleep(), чтобы приостановить вызывающий поток (приблизительно) на пять секунд для имитации задачи, выполнение которой требует много времени. Поскольку метод Add() вызывается в синхронной форме, метод Main() не напечатает результат операции до тех пор, пока не завершится работа метода Add().

    Далее заметим, что метод Main() получает доступ к текущему потоку (с помощью Thread.CurrentThread) и печатает его хешированный код. Поскольку этот хешированный код представляет объект в конкретном состоянии, соответствующее значение можно использовать как "грубый" идентификатор потока. Та же логика используется в статическом методе Add(). Как и следует ожидать, поскольку вся работа в этом приложении выполняется исключительно первичным потоком, вы увидите одинаковые хешированные значения в консольном выводе программы (рис. 14.1).

    Рис. 14.1. Синхронные вызовы методов "блокируют" другие вызовы

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

    Исходный код. Проект SyncDelegate размещен в подкаталоге, соответствующем главе 14.

    Асинхронная природа делегатов

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

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

    Методы BeginInvoke() и EndInvoke()

    Когда компилятор C# обрабатывает ключевое слово delegate, динамически генерируемый класс определяет два метода с именами BeginInvoke() и EndInvoke(). Для нашего определения делегата BinaryOp эти методы оказываются следующими.

    sealed class BinaryOp : System.MulticastDelegate {

     …

     // Используется для асинхронного вызова метода.

     public IAsyncResult BeginInvoke(int x, int y, AsyncCallback cb, object state);

     // Используется для извлечения возвращаемого значения

     // вызванного метода.

     public int EndInvoke(IAsyncResult result);

    }

    Первый набор параметров, передаваемых в BeginInvoke(), формируется на основе формата делегата C# (в случае BinaryOp это два целочисленных значения). Последними двумя аргументами всегда являются System.AsyncCallback и System.Object. Мы рассмотрим роль этих параметров чуть позже, а пока что для каждого из них мы будем использовать null.

    Интерфейс System.IAsyncResult

    Метод BeginInvoke() всегда возвращает объект, реализующий интерфейс IAsyncResult, а метод EndInvoke() имеет единственный параметр типа IAsyncResult. Совместимый с IAsyncResult объект, возвращаемый методом BeginInvoke(), и является тем связующим механизмом, который позволяет вызывающему потоку получить результат асинхронного вызова метода позже с помощью EndInvoke(). Интерфейс IAsyncResult (определенный в пространстве имен System) задается так, как показано ниже.

    public interface IAsyncResult {

     object AsyncState { get; }

     WaitHandle AsyncWaitHandle { get; }

     bool CompletedSynchronously { get; }

     bool IsCompleted { get; }

    }

    В самом простом случае можно избежать непосредственного вызова этих членов. Требуется только сохранить совместимый с IAsyncResult объект, возвращенный BeginInvoke(), и передать его методу EndInvoke(), когда вы будете готовы получить результат вызова метода. Позже вы увидите, что у вас есть возможность вызывать члены совместимого с IAsyncResult объекта, если вы хотите "участвовать" в процессе извлечения возвращаемого значений метода.

    Замечание. Если асинхронно вызывается метод, который не предлагает возвращаемых значений, можно его вызвать и престо "забыть" о нем. В таких случаях нет необходимости сохранять совместимый с IAsyncResult объект и вызывать EndInvoke() (так как нет возвращаемого значения, которое требуется извлечь).

    Асинхронный вызов методов

    Чтобы дать указание делегату BinaryOp вызвать метод Add() асинхронно, измените предыдущий метод Main() так, как показано ниже.

    static void Main(string[] args) {

     Console.WriteLine("***** асинхронный вызов делегата *****");

     // Вывод ID выполняемого потока.

     Console.WriteLine("Вызван Main() в потоке {0}.", Thread.CurrentThread.GetHashCode());

     // Вызов Add() во вторичном потоке.

     BinaryOp b = new BinaryOp(Add);

     IAsyncResult iftAR = b.BeginInvoke(10, 10, null, null);

     // Выполнение другой работы в первичном потоке.…

     Console.WriteLine("В Main() еще есть работа!");

     // Получение результата метода Add(),

     // когда это требуется.

     int answer = b.EndInvoke(iftAR);

     Console.WriteLine ("10 + 10 равно {0}.", answer);

     Console.ReadLine();

    }

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

    Рис. 14.2. Методы, вызываемые асинхронно, выполняют свою работу в отдельном потоке

    Вдобавок к уникальным хешированным значениям, вы также обнаружите, что при запуске приложения сообщение "В Main() еще есть работа!" появляется практически немедленно.

    Синхронизация вызывающего потока

    Для текущей реализации Main() диапазон времени между вызовом BeginInvoke() и вызовом EndInvoke() явно меньше пяти секунд. Поэтому после вывода на консоль сообщения "В Main() еще есть работа!" поток вызова блокируется и ждет завершения существования вторичного потока, который должен получить результат метода Add(). Таким образом, вы на самом деле выполняете еще один синхронный вызов.

    static void Main (string[] args) {

     …

     BinaryOp b = new BinaryOp(Add);

     IAsyncResult iftAR = b.BeginInvoke(10, 10, null, null);

     // До этого вызова проходит менее 5 секунд!

     Console.WriteLine("В Main() еще есть работа!");

     // Вызывающий поток блокируется до завершения EndInvoke().

     int answer = b.EndInvoke(iftAR);

     …

    }

    Очевидно, что асинхронные делегаты теряют свою привлекательность, если поток вызова может при определенных условиях блокироваться. Чтобы позволить вызывающему потоку выяснить, закончил ли асинхронно вызванный метод свою работу, интерфейс IAsyncResult предлагает свойство IsCompleted. Используя этот член, поток вызова может перед вызовом EndInvoke() проверить, завершен ли асинхронный вызов. Если работа метода не завершена, IsCompleted возвращает false (ложь), и поток вызова может продолжать свою работу. Если же IsCompleted возвращает true (истина), то поток вызова может получить результат "наименее блокирующим" способом. Рассмотрите следующую модификацию метода Main().

    static void Main (string[] args) {

     …

     BinaryOp b = new BinaryOp(Add);

     IAsyncResult iftAR = b.BeginInvoke(10, 10, null, null);

     // Это сообщение будет печататься до тех пор, // пока не завершится вызов метода Add().

     while (!iftAR.isCompleted) Console. WriteLine("В Main() еще есть работа!");

     // Теперь мы знаем, что вызов метода Add() завершен.

     int answer = b.EndInvoke(iftAR);

     …

    }

    Здесь вводится цикл, который будет продолжать выполнение оператора Console.WriteLine() до тех пор, пока не завершится вторичный поток. Как только это произойдет, вы сможете получить результат метода Add() с уверенностью, что этот метод завершил свою работу.

    Вдобавок к свойству IsCompleted интерфейс IAsyncResult предлагает свойство AsyncWaitHandle для построения еще более гибкой логики ожидания. Это свойство возвращает экземпляр WaitHandle, предлагающий метод WaitOne(). Преимущество метода WaitHandle.WaitOne() в том, что вы можете указать максимальное время ожидания. Если указанное время превышено, WaitOne() возвращает false. Рассмотрите следующий (обновленный) вариант цикла while:

    while (!iftAR.AsyncWaitHandle.WaitOne(2000, true)) {

     Console.WriteLine("В Main() еще есть работа!");

    }

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

    Исходный код. Проект AsyncDelegate размещен в подкаталоге, соответствующем главе 14.

    Роль делегата AsyncCallback

    Вместо того чтобы выяснять у делегата, завершился ли асинхронный вызов метода, лучше позволить делегату информировать поток вызова о выполнении задания. Чтобы реализовать такое поведение, вы должны предъявить экземпляр делегата System.AsyncCallback методу BeginInvoke() в виде параметра, значением которого до сих пор было у нас значение null. Если вы укажете AsyncCallback, делегат вызовет соответствующий метод автоматически, когда асинхронный вызов завершится.

    Подобно любому другому делегату, AsyncCallback может вызывать только методы, соответствующие конкретному шаблону, и в данном случае это методы, принимающие единственный параметр типа IAsyncResult и возвращающие void.

    void MyAsyncCallbackMethod(IAsyncResult iftAR)

    Предположим, что у нас есть другое приложение, использующее делегат BinaryOp. На этот раз мы не будем "просить" делегат выяснить, завершился ли метод Add(). Вместо этого мы определим статический метод с именем AddComplete(), чтобы получить извещение о завершении асинхронного вызова,

    namespace AsyncCallbackDelegate {

     public delegate int BinaryOp(int x, int y);

     class Program {

      static void Main(string[] args) {

       Console.WriteLine("*** Пример делегата AsyncCallback ***");

       Console.WriteLine("Вызван Main() в потоке {0}", Thread.CurrentThread.GetHashCode());

       BinaryOp b = new BinaryOp(Add);

       IAsyncResult iftAR = b.BeginInvoke(10, 10, new AsyncCallback(AddComplete), null);

       // Здесь выполняется другая работа…

       Console.ReadLine();

      }

      static void AddComplete(IAsyncResult iftAR) {

       Console.WriteLine("Вызван AddComplete() в потоке {0}", Thread.CurrentThread.GetHashCode());

       Console.WriteLine("Ваше сложение выполнено");

      }

      static int Add(int x, int y) {

       Console.WriteLine("Вызван Add() в потоке {0}.", Thread.CurrentThread.GetHashCode());

       Thread.Sleep(5000);

       return x + y;

      }

     }

    }

    Снова заметим, что статический метод AddComplete() будет вызван делегатом AsyncCallback тогда, когда завершится вызов метода Add(). Выполнение этой программы может подтвердить, что именно вторичный поток выполняет обратный вызов AddComplete() (рис. 14.3).

    Рис. 14.3. Делегат AsyncCallback в действии

    Роль класса AsyncResult

    В текущей своей форме метод Main() не хранит тип IAsyncResult, возвращаемый из BeginInvoke(), и не вызывает EndInvoke(). Более того, целевой метод делегата AsyncCallback (в данном случае это метод AddComplete()) вообще не имеет доступа к оригинальному делегату BinaryOp, созданному в контексте Main(). Можно, конечно, объявить BinaryOp, как статический член класса, чтобы позволить обоим методам иметь доступ к объекту, но более "элегантным" решением яв-ляетcя использование входного параметра IAsyncResult.

    Поступающий на вход параметр IAsyncResult, передаваемый целевому методу делегата AsyncCallback, является экземпляром класса AsyncResult (заметьте, префикс I здесь отсутствует), определенного в пространстве имен System.Runtime. Remoting.Messaging. Статическое свойство AsyncDelegate возвращает ссылку на оригинальный асинхронный делегат, созданный где-то в программе. Таким образом, чтобы получить ссылку на объект делегата BinaryOp, размещенный в Main(), нужно просто преобразовать возвращенный свойством AsyncDelegate тип System.Object в тип BinaryOp. После этого можно вызвать EndInvoke(), как и ожидается.

    // Не забудьте добавить директиву 'using' для

    // System.Runtime.Remoting.Messaging!

    static void AddComplete(IAsyncResult iftAR) {

     Console.WriteLine("Вызван AddComplete() в потоке {0}.", Thread.CurrentThread.GetHashCode());

     Console.WriteLine("Ваше сложение выполнено");

     // Теперь получим результат.

     AsyncResult ar = (AsyncResult)itfAR;

     BinaryOp b = (BinaryOp)ar.AsyncDelegate;

     Console.WriteLine("10 + 10 равно {0}.",

     b.EndInvoke(itfAR));

    }

    Передача и получение пользовательских данных состояния

    Заключительным аспектом нашего рассмотрения асинхронных делегатов будет обсуждение последнего из аргументов метода BeginInvoke() (этот аргумент у нас до сих пор был равен null). С помощью этого параметра можно передать в метод обратного вызова дополнительную информацию состояния из первичного потока. Ввиду того, что прототипом этого аргумента является System.Object, с его помощью можно передать практически любые данные, приемлемые для метода обратного вызова. Предположим для примера, что первичный поток должен передать методу AddComplete() пользовательское текстовое сообщение.

    static void Main(string[] args) {

     …

     IAsyncResult iftAR = b.BeginInvoke(10, 10, new AsyncCallback(AddComplete), "Main() благодарит вас за сложение этих чисел.");

     …

    }

    Чтобы получить эти данные в контексте AddComplete(), используйте свойство AsyncState поступающего на вход параметра IAsyncResult.

    static void AddComplete(IAsyncResult iftAR) {

     …

     // Получение объекта с информацией и преобразование его в строку.

     string msg = (string)itfAR.AsyncState;

     Console.WriteLine(msg);

    }

    На рис. 14.4 показан вывод этого приложения.

    Рис. 14.4. Передача и получение пользовательских данных состояния

    Чудесно! Теперь, когда вы понимаете, что делегат .NET можно использовать для автоматического запуска вторичного потока выполнения, обрабатывающего асинхронный вызов метода, давайте обратим внимание на возможности непосредственного взаимодействия о потоками с помощью пространства имен System.Threading.

    Исходный код. Проект AsyncCallbackDelegate размещен в подкаталоге, соответствующем главе 14.

    Пространство имен System.Threading

    В рамках платформы .NET пространство имен System.Threading предлагает ряд типов, позволяющих строить многопоточные приложения. Вдобавок к типам, с помощью которых можно взаимодействовать с отдельными потоками CLR, в этом пространстве имен определены также типы, обеспечивающие доступ к поддерживаемому средой CLR пулу потоков, простой (не имеющий графического интерфейса) класс Timer и множество типов, предназначенных для поддержки синхронизированного доступа к разделяемым ресурсам. Описания основных членов этого пространства имен приведены табл. 14.1. (Не забывайте о том, что подробности всегда можно найти в документации .NET Framework 2.0 SDK.)

    Таблица 14.1. Подборка типов пространства имен System.Threading

    Тип Описание
    Interlocked Предлагает атомарные операции для типов, открытых для множества потоков.
    Monitor Обеспечивает синхронизацию объектов потоков с помощью блокировок и ожиданий/сигналов, ключевое слово C# lock использует тип Monitor в фоновом режиме
    Mutex Примитив синхронизации, используемый для синхронизации взаимодействия между границами доменов приложения
    ParameterizedThreadStart Делегат (появившийся только в .NET 2.0), позволяющий потоку вызывать методы с любым числом аргументов
    Semaphore Позволяет ограничить число потоков, которые могут иметь конкурентный доступ к ресурсу или определенному типу ресурсов
    Thread Представляет поток, выполняющийся в среде CLR. С помощью этого типа можно создавать дополнительные потоки в оригинальном домене приложения
    ThreadPool Позволяет взаимодействовать о пулам потоков, управляемым средой CLR в рамках данного процесса
    ThreadPriority Перечень, представляющий уровень приоритета потока (Highest, Normal и т.д.)
    ThreadStart Делегат, используемый для указания метода, вызываемого для данного потока. В отличие от ParameterizedThreadStart, целевые методы ThreadStart должны соответствовать фиксированному шаблону
    ThreadState Перечень, указывающий состояния, допустимые для данного потока (Running, Aborted и т.д.)
    Timer Обеспечивает механизм выполнения метода через заданные интервалы времени
    TimerCallback Делегат, используемый в совокупности с типами Timer

    Класс System.Threading.Thread

    Основным в пространстве имен System.Threading является класс Thread. Этот класс представляет собой объектный контейнер отдельной ветви выполнения в конкретном домене приложения. Он определяет ряд методов (как статических, так и общедоступных), которые позволяют создавать новые потоки в текущем домене приложения, а также приостанавливать, останавливать и завершать отдельные потоки. Рассмотрите описания основных статических членов, приведенные в табл. 14.2.

    Таблица 14.2. Основные статические члены типа Thread

    Статический член Описание
    CurrentContext Доступное только для чтения свойство, возвращающее контекст, в котором выполняется поток в настоящий момент
    CurrentThread Доступное только для чтения свойство, возвращающее ссылку на выполняемый в настоящий момент поток
    GetDomain() GetDomainID() Методы, возвращающие ссылки на текущий домен приложения или идентификатор домена, в котором выполняется текущий поток
    Sleep() Метод, приостанавливающий выполнение текущего потока на указанное время

    Класс Thread также поддерживает набор членов уровня экземпляра. Описания некоторых из этих членов приведены в табл. 14.3.

    Таблица 14.3. Члены уровня экземпляра типа Thread 

    Член уровня экземпляра Описание
    IsAlive Возвращает логическое значение, сообщающее о том, запущен ли данный поток
    IsBackground Читает или устанавливает значение, сообщающее о том, является ли данный поток "фоновым" (дополнительные подробности будут предложены чуть позже)
    Name Позволяет задать понятное строковое имя потока
    Priority Читает или устанавливает приоритет потока, которому может быть назначено значение из перечня ThreadPriority
    ThreadState Читает информацию о состоянии потока, которая может принимать значения из перечня ThreadState
    Abort() Дает указание среде CLR завершить поток как можно быстрее
    Interrupt() Выводит (например, путем активизации) текущий поток из периода ожидания
    Join() Блокирует вызывающий поток до завершения указанного потока (того, для которого вызывается Join())
    Resume() Возобновляет выполнение приостановленного ранее потока  
    Start() Дает указание среде CLR как можно быстрее начать выполнение потока
    Suspend() Приостанавливает выполнение потока. Если поток уже приостановлен, вызов Suspend() игнорируется

    Получение информации об отдельном потоке

    Напомним, что точка входа компоновочного блока (т.е. метод Main()) при выполнении оказывается в первичном потоке. Чтобы привести типичный пример использования типа Thread, предположим, что у нас есть новое консольное приложение с именем ThreadState. Вы знаете, что статическое свойство Thread.СurrentThread позволяет получить тип Thread, представляющий выполняемый в настоящий момент поток. Получив текущий поток, вы можете вывести на экран различную информацию о потоке.

    // Не забудьте указать 'using' для пространства имен System.Threading.

    static void Main(string[] args) {

     Console.WriteLine("***** Информация первичного потока *****\n");

     // Получение текущего потока и назначение ему имени.

     Thread primaryThread = Thread.CurrentThread;

     primaryThread.Name = "ThePrimaryThread";

     // Подробности хостинга домена приложения и контекста.

     Console.WriteLine("Имя текущего домена приложения: {0}";

     Thread.GetDomain().FriendlyName);

     Console.WriteLine("Идентификатор текущего контекста: {0}", Thread.CurrentContext.ContextID);

     // Вывод информации о данном потоке.

     Console.WriteLine("Имя потока: {0}", primaryThreаd.Name);

     Console.WriteLine("Запущен ли поток? {0}", primaryThread.IsAlive);

     Console.WriteLine("Уровень приоритета: {0}", primaryThread.Priority);

     Console.WriteLine("Состояние потока: {0}", primaryThread.ThreadState);

     Console.ReadLine();

    }

    На рис. 14.5 показан вывод этого приложения.

    Рис. 14.5. Сбор статистики о потоке

    Свойство Name

    Приведенный выше программный код достаточно понятен, но обратите внимание на то, что класс Thread предлагает свойство с именем Name (имя). Если вы не установите для него значения, свойство Name будет возвращать пустую строку. Но, назначив данному объекту Thread в качестве имени понятную строку, вы можете сильно упростить процесс отладки. В Visual Studio 2005 в режиме отладки можно использовать окно Threads (Потоки), доступ к которому можно получить, выбрав Debug>Windows>Threads из меню. Как показано на рис. 14.6, в этом окне можно по имени идентифицировать поток, который следует проанализировать.

    Рис. 14.6. Отладка потока в Visual Studio 2005

    Свойство Priority

    Далее заметим, что тип Thread определяет свойство с именем Priority. По умолчанию все потоки получают приоритет Normal (средний). Но вы можете изменить это значение в любой момент времени существования потока, используя свойство Priority и связанный с ним перечень System.Threading.ThreadPriority.

    public enum ThreadPriority {

     AboveNormal,

     BelowNormal,

     Highest,

     Idle,

     Lowest,

     Normal, // Значение, используемое по умолчанию.

     TimeCritical

    }

    При назначении потоку приоритета, отличного от принимаемого по умолчанию (ThreadPriority.Normal), вы должны понимать, что не обладаете слишком большими возможностями контроля в отношении того, когда планировщик потоков переключится с одного потока на другой. Уровень приоритета потока является лишь "подсказкой" среде CLR в отношении того, насколько важно выполнение данного потока. Поэтому поток со значением ThreadPriority.Highest (наивысший) не обязательно гарантирует данному потоку абсолютное преимущество.

    Снова подчеркнем, что в том случае, когда планировщик потоков полностью занят текущей задачей (например, синхронизацией объекта, переключением или перемещением потоков), уровень приоритета будет, вероятнее всего, соответствующим образом изменен. Однако в других случаях соответствующие значения прочитает среда CLR, которая и выдаст планировщику потоков указания о том, как лучше всего организовать квантование времени. При прочих равных условиях потоки с идентичным приоритетом должны получать примерно одинаковое время для выполнения своей работы.

    Необходимость изменения приоритетов потоков вручную возникает очень редко. Теоретически можно повысить приоритет для множества потоков так, что это не позволит потокам с более низкими приоритетами выполнять работу на их уровнях (поэтому используйте указанные возможности с осторожностью).

    Исходный код. Проект ThreadState размещен в подкаталоге, соответствующем главе 14.

    Программное создание вторичных потоков

    Чтобы программно создавать дополнительные потоки, выполняющие свои отдельные задачи, вы должны следовать вполне понятным указанным ниже рекомендациям.

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

    2. Создайте делегат ParameterizedThreadStart (или уже устаревший ThreadStart), передав его конструктору адрес метода, определенного на шаге 1.

    3. Создайте объект Thread, передав конструктору делегат ParameterizedThreadStart/ThreadStart в виде аргумента.

    4. Задайте подходящие начальные характеристики потока (имя, приоритет и т.д.).

    5. Вызовите метод Thread.Start(). Это указание как можно быстрее стартовать поток для метода, на который ссылается делегат, созданный на шаге 2.

    Согласно шагу 2, имеется возможность использовать один из двух разных типов делегата для метода, предназначенного для выполнения во вторичном потоке. Делегат ThreadStart является частью пространства имен System.Threading со времен .NET версии 1.0 и может указывать на любой метод, не имеющий аргументов и не возвращающий ничего. Этот делегат удобно использовать тогда, когда метод должен выполняться в фоновом режиме без взаимодействия с ним.

    Очевидным ограничением ThreadStart является отсутствие параметров. Поэтому в .NET 2.0 предлагается тип делегата ParameterizedThreadStart, допускающий передачу одного параметра типа System.Object. Поскольку с помощью System.Object можно представить всё, что угодно, вы можете передать этому делегату любое число параметров в виде пользовательского класса или структуры. Заметьте, однако, что делегат ParameterizedThreadStart может указывать только на методы, возвращающие void.

    Работа с делегатом ThreadStart

    Чтобы рассмотреть процесс создания многопоточного приложения на практику (а также продемонстрировать пользу соответствующего подхода), предположим, что у нас есть консольное приложение (SimpleMultiThreadApp), которое позволяет конечному пользователю выбрать в приложении либо использование одного первичного потока, выполняющего всю работу, либо разделение ее на два отдельных потока.

    После того как вы обеспечите доступ к пространству имен System.Threading с помощью ключевого слова C# using, первым шагом должно быть определение метода, который будет выполнять работу во вторичном потоке. Чтобы сосредоточиться на сути механизма построения многопоточных программ, здесь этот метод просто выводит последовательность чисел с двухсекундными задержками перед каждой операцией вывода. Вот полное определение соответствующего класса Printer.

    public class Printer {

     public void PrintNumbers() {

      // Отображение информации потока.

      Console.WriteLine ("-› {0} выполняет PrintNumbers()", Thread.CurrentThread.Name);

      // Вывод чисел.

      Console.Write("Ваши числа: ");

      for(int i = 0; i ‹ 10; i++) {

       Console.Write(i + ", ");

       Thread.Sleep(2000);

      }

      Console.WriteLine();

     }

    }

    Теперь в Main() нужно предложить выбор одного или двух потоков для выполнения задач приложения. Если пользователь выберет использование одного потока, просто вызывается метод PrintNumbers() в рамках первичного потока. Но если пользователь указывает два потока, создается делегат ThreadStart, указывающий на PrintNumbers(). Объект делегата передается конструктору нового объекта Thread и вызывается метод Start(), информирующий среду CLR о том, что поток готов к обработке.

    Сначала установите ссылку на компоновочный блок System.Windows.Forms.dll и с помощью MessageBox.Show() отобразите подходящее сообщение в Main() (смысл этого станет ясным при запуске программы). Вот полная реализация Main() в нужном виде.

    static void Main(string[] args) {

     Console.WriteLine("***** Чудесное приложение Thread *****\n");

     Console.Write("Хотите иметь [1] или [2] потока?");

     string threadCount = Console.ReadLine();

     // Имя текущего потока.

     Thread primaryThread = Thread.CurrentThread;

     primaryThread.Name = "Первичный";

     // Вывод информации Thread.

     Console.WriteLine("-› {0} выполняет Main()", Thread.CurrentThread.Name);

     // Создание рабочего класса.

     Printer р = new Printer();

     switch (threadCount) {

     case "2":

      // Теперь создание потока.

      Thread backgroundThread = new Thread(new ThreadStart(p.PrintNumbers));

      backgroundThread.Name = "Вторичный";

      backgroundThread.Start();

      break;

     case "1":

      p.PrintNumbers();

      break;

    default:

     Console.WriteLine("Ваши указания не ясны… будет 1 поток.");

     goto case "1";

    }

    // Выполнение дополнительней работы.

    MessageBox.Show("Я занят!", "Работа в главном потоке…");

    Console.RеаdLine();

    }

    Если теперь запустить эту программу с одним потоком, вы обнаружите, что окно сообщения не будет отображено до тех пор, пока на консоль не будет выведена вся последовательность чисел. Здесь была указана пауза приблизительно в две секунды после вывода каждого из чисел, поэтому подобное поведение программы не вызовет восхищения конечного пользователя. Но если вы выберете вариант с двумя потоками, окно сообщения появится немедленно, поскольку для вывода чисел на консоль будет использоваться свой уникальный объект Thread (рис. 14.7).

    Рис. 14.7. Многопоточные приложения "более отзывчивы" при выдаче своих результатов

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

    Исходный код. Проект SimpleMultiThreadApp размещен в подкаталоге, соответствующем главе 14.

    Работа с делегатом ParameterizedThreadStart

    Напомним, что делегат ThreadStart может указывать только на методы, возвращающие void и не имеющие аргументов. Во многих случаях этого будет вполне достаточно, но передать данные методу, выполняющемуся во вторичном потоке, вы сможете только с помощью делегата ParameterizedThreadStart. Для примера воссоздадим программную логику проекта AsyncCallbackDelegate, построенного в этой главе выше, но на этот раз используем тип делегата ParameterizedThreadStart.

    Сначала создайте новое консольное приложение AddWithThreads и укажите using для пространства имен System.Threading. Поскольку ParameterizedThreadStart может указывать на любой метод, принимающий параметр System.Object, создайте пользовательский тип, содержащий числа для сложения.

    class AddParams {

     public int a;

     public int b;

     public AddParams(int numb1, int numb2) {

      a = numb1;

      b = numb2;

     }

    }

    В классе Program создайте статический метод, который с помощью типа AddParams напечатает сумму соответствующих значений.

    public static void Add(object data) {

     if (data is AddParams) {

      Console.WriteLine("ID потока в Add(): {0}", Thread.CurrentThread.GetHashCode());

      AddParams ap = (AddParams)data;

      Console.WriteLine("{0} + {1} равно {2}", ар.a, ар.b, ар.a + ар.b);

     }

    }

    Программный код Main() в данном случае предельно прост. Просто используйте ParameterizedThreadStart вместо ThreadStart.

    static void Main(string[] args) {

     …

     Console.WriteLine("***** Сложение с объектами Thread *****");

     Console.WriteLine("ID потока в Main(): {0}", Thread.CurrentThread.GetHashCode());

     AddParams ap = new AddParams(10, 10);

     Thread t = new Thread(new ParameterizedThreadStart(Add));

     t.Start(ap);

     …

    }

    Исходный код. Проект AddWithThreads размещен в подкаталоге, соответствующем главе 14.

    Приоритетные и фоновые потоки

    Итак, вы научились программного создавать новые потоки выполнения с помощью пространства имен System.Threading, теперь давайте выясним, чем отличаются приоритетные и фоновые потоки.

    Приоритетные потоки обеспечивают текущему приложению защиту от преждевременного завершения. Среда CLR не прекратит работу приложения (лучше сказать, не выгрузит соответствующий домен приложения), пока не завершат работу все приоритетные потоки,

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

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

    Но предположим, что нам нужно вызвать Printer.PrintNumbers() во вторичном потоке, который должен действовать, как фоновый поток. Это означает, что для метода, на который указывает тип Thread (посредством делегата ThreadStart или ParameterizedThreadStart), должна допускаться возможность безболезненного его завершения, как только все приоритетные потоки закончат свою работу. Для настройки такого потока достаточно установить значение true (истина) для свойства IsBackground.

    static void Main(string[] args) {

     Printer p = new Printer();

     Thread bgroundThread = new Thread(new ThreadStart(p.PrintNumbers));

      bgroundThread.IsBackground = true;

      bgroundThread.Start();

    }

    Обратите внимание на то, что метод Main() здесь не вызывает Console.ReadLine(), чтобы гарантировать присутствие консоли на экране до нажатия клавиши «Enter». Поэтому при выполнении этого приложения оно сразу же прекратит свою работу, так как объект Thread сконфигурирован для работы в фоновом потоке. С началом работы метода Main() создается приоритетный первичный поток, поэтому, как только выполнение программной логики Main() завершится, домен приложения будет выгружен, и это произойдет до того, как вторичный поток завершит свою работу. Однако, закомментировав строку, в которой устанавливается свойство IsBackground, вы обнаружите, что на консоль выводятся все числа, поскольку для того, чтобы домен приложения будет выгружен из содержащего его процесса, все приоритетные потоки должны завершить свою работу.

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

    Исходный код. Проект BackgroundThread размещен в подкаталоге, соответствующем главе 14.

    Проблема конкурентного доступа

    До сих пор все многопоточные приложения, созданные вами при изучении материала этой главы, были устойчивыми в отношении потоков, поскольку в них соответствующие методы вызывались только одним объектом Thread. Конечно, некоторые из ваших приложений могут быть настолько же простыми, но большинство многопоточных приложений содержит очень много вторичных потоков. С учетом того, что все потоки в домене приложения могут претендовать на доступ к открытым данным приложения одновременно, представьте себе, что может случиться, если к одному и тому же элементу данных получит доступ множество потоков. Поскольку планировщик потоков может приостановить работу потока в любой момент времени, что будет, если поток А будет отстранен от выполнения своей работы на полпути до того, как он эту работу завершит? Поток В будет читать некорректные данные.

    Чтобы проиллюстрировать проблему конкурентного доступа, давайте построим еще одно консольное приложение C#, которое мы назовем MultiThreadedPrinting, Это приложение будет использовать класс Printer, созданный нами ранее, но на этот раз метод PrintNumbers() "заставит" текущий поток делать паузы произвольной длительности в соответствии со случайно генерируемыми значениями.

    public class Printer {

     public void PrintNumbers() {

      …

      for (int i = 0; i ‹ 10; i++) {

       Random r = new Random();

       Thread.Sleep(1000 * r.Next(5));

       Console.Write(i + ", ");

      }

      Console.WriteLine();

     }

    }

    Метод Main() отвечает за создание массива из десяти объектов Thread с уникальными именами), каждый из который вызывает один и тот же экземпляр Printer.

    class Program {

     static void Main(string[] args) {

      Console.WriteLine("***** Синхронизация потоков *****\n");

      Printer p = new Printer();

      // Создание 10 потоков, указывающих на один и тот же метод

      // одного и того же объекта.

     Thread[] threads = new Thread[10];

      for (int i = 0; i ‹ 10; i++) {

       threads[i] =new Thread(new ThreadStart(p.PrintNumbers));

       threads[i].Name = string.Format("Рабочий поток #{0}", i);

      }

      // Теперь старт каждого их них.

      foreach (Thread t in threads) t.Start();

      Console.ReadLine();

     }

    }

    Перед тем как выполнить тестовый запуск программы, давайте обсудим cо-ответствующую проблему. Здесь первичный поток в рамках домена приложения порождает десять вторичных рабочих потоков. Каждому рабочему потоку дается указание вызвать метод PrintNumbers() одного и того же экземпляра Printer. Поскольку здесь не предпринято никаких мер по блокированию общедоступных ресурсов данного объекта (консоли), имеется большая вероятность того, что текущий поток будет приостановлен до того, как метод PrintNumbers() закончит вывод всех своих результатов. Вы не знаете точно, когда это случиться (и случится ли вообще), поэтому нужно быть готовым к непредвиденным результатам. Например, может получиться вывод, показанный на рис. 14.8.

    Рис. 14.8. Конкуренция в действии, первая попытка

    Выполните приложение еще несколько раз. На рис. 14.9 показана другая возможность вывода (ваши результаты, очевидно, тоже будут другими).

    Рис. 14.9. Конкуренция в действии, вторая попытка

    Ясно, что проблемы здесь действительно есть. Каждый поток дает указание объекту Printer печатать числовые данные, и планировщик потоков запускает выполнение этих потоков в фоновом режиме. В результате получается несогласованный вывод. В этом случае мы должны программно организовать синхронизованный доступ к совместно используемым ресурсам. Нетрудно догадаться, что в пространстве имен System.Threading есть целый ряд типов, имеющих отношение к синхронизации. А язык программирования C# предлагает специальное ключевое слово, как раз для решения задач синхронизации совместного доступа к данным в многопоточных приложениях.

    Замечание. Если у вас не получается сгенерировать непредвиденный вывод, увеличьте число потоков с 10 до 100 (например) или добавьте в свою программу вызов Thread.Sleep(). В конце концов вы все равно столкнетесь с проблемой конкурентного доступа

    Синхронизация с помощью ключевого слова lock в C#

    Первой из возможностей, которую вы можете применить в C# для синхронизации доступа к совместно используемым ресурсам, является использование ключевого слова lock. Это ключевое слово позволяет определить контекст операторов, которые должны синхронизироваться между потоками. В результате входящие потоки не смогут прервать текущий поток, пока он выполняет свою работу. Ключевое слово lock требует, чтобы вы указали маркер (объектную ссылку), который потребуется потоку для входа в пределы контекста lock. При блокировке метода уровня экземпляра можно использовать просто ссылку на текущий тип.

    // Использование текущего объекта в качестве маркера потока.

    lock(this) {

     // Весь программный код в этом контексте оказывается

     // устойчивым в отношении потоков.

    }

    При внимательном изучении метода PrintNumbers() становится ясно, что совместно используемым ресурсом, за доступ к которому соперничают потоки, является окно консоли. Поместите в рамки соответствующего контекста блокировки все операторы взаимодействии с типом Console так, как показано ниже.

    public void PrintNumbers() {

     lock (this) {

      // Вывод информации Thread.

      Console.WriteLine("-› {0} выполняет PrintNumbers()", Thread.CurrentThread.Name);

      // Вывод чисел.

      Console.Write("Ваши числа": ");

      for (int i = 0; i ‹ 10; i++) {

       Random r = new Random();

       Thread.Sleep(1000 * r.Next(5));

       Console.Write(i + ", ");

      }

      Console.WriteLine();

     }

    }

    Тем самым вы создадите метод, который позволит текущему потоку завершить выполнение своей задачи. Как только поток вступит в контекст блокировки, соответствующий маркер блокировки (в данном случае эта ссылка на текущий объект) станет недоступным другим потокам, пока блокировка не будет снята в результате выхода потока из контекста блокировки. Например, если маркер блокировки получает поток А, то другие потоки не смогут войти в контекст до тех пор, пока поток А не освободит маркер блокировки.

    Замечание. Если пытаться блокировать программный код в статическом методе, вы, очевидно, не можете использовать ключевое слово this. Но в этом случае можно передать объект System.Type соответствующего класса с помощью оператора C# typeof.

    Если снова выполнить это приложение, вы увидите, что теперь каждый поток получает возможность закончить свою работу (рис. 14.10).

    Рис. 14.10. Конкуренция в действии, третья попытка

    Исходный код. Проект MultiThreadedPrinting размещен в подкаталоге, соответствующем главе 14.

    Синхронизация с помощью типа System.Threading.Monitor

    Оператор C# lock на самом деле является лишь ключевым словом, обозначающим использование типа класса System.Threading.Monitor. После обработки компилятором C# контекст блокировки превращается в следующее (вы можете убедиться в этом с помощью ildasm.exe).

    public void PrintNumbers() {

     Monitor.Enter(this);

     try {

      // Вызов информации Thread.

      Console.WriteLine("-› {0} выполняет PrintNumbers()", Thread.CurrentThread.Name); // Вывод чисел.

      Console.Write("Ваши числа: ");

      for (int i = 0; i ‹ 10; i++) {

       Random r = new Random();

       Thread.Sleep(1000* r.Next(5));

       Console.Write(i + ", ");

      }

      Console.WriteLine();

     } finallу {

      Monitor.Exit(this);

     }

    }

    Во-первых, заметим, что конечным получателем маркера потока, который был указан в качестве аргумента ключевого слова lock, является метод Monitor.Enter(). Во-вторых, весь программный код в рамках контекста соответствующей блокировки помещен в блок try. Соответствующий блок finally гарантирует, что маркер потока будет освобожден (с помощью метода Monitor.Exit()), независимо от исключений, которые могут возникать в среде выполнения. Если изменить программу MultiThreadSharedData так, чтобы тип Monitor использовался непосредственно (как это будет сделано чуть позже), то ее вывод останется тем же.

    При использовании ключевого слова lock, кажется, требуется меньший ввод программного кода, чем при явном использований типа System.Threading.Monitor, поэтому вы можете задать вопрос о преимуществах непосредственного использования типа Monitor. Краткий ответ: контроль. При использовании типа Monitor вы можете дать указание активному потоку подождать (с помощью метода Wait()), информировать ожидающие потоки о завершении текущего потока (с помощью методов Pulse() и PulseAll()) и т.д.

    В большинстве случаев вам будет вполне достаточно возможностей, обеспечиваемых ключевым словам C# lock. Но если вы захотите рассмотреть другие члены класса Monitor, обратитесь к документации .NET Framework 2.0 SDK.

    Синхронизация с помощью типа System.Threading.Interlocked

    В это всегда верится с трудом, пока вы не проверите соответствующий программный код CIL, но и операции присваивания, и базовые арифметические операции не являются атомарными. Поэтому в пространстве имен System.Threading предлагается тип, позволяющий воздействовать на отдельный элемент данных атомарно с меньшей нагрузкой, чем это делает тип Monitor. Тип класса Interlocked определяет статические члены, описания которых приведены в табл. 14.4.

    Таблица 14.4. Члены типа System.Threading.Interlocked

    Член Описание
    CompareExchange() Безопасно проверяет два значения на равенство, и если они равны, заменяет одно из значений третьим
    Decrement() Безопасно уменьшает значение на 1
    Exchange() Безопасно меняет два значения местами
    Increment() Безопасно выполняет приращение значения на 1

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

    public void AddOne() {

     lock(this) {

      intVal++;

     }

    }

    можно предложить более простой программный код, в котором используется статический метод Interlocked.Increment(). Просто передайте переменную для приращения по ссылке. Обратите внимание на то, что метод Increment() не только изменяет значение поступающего параметра, но и возвращает новое значение.

    public void AddOne() {

     int newVal = Interlocked.Increment(ref intVal);

    }

    В дополнение к Increment() и Decrement() тип Interlocked позволяет атомарно присваивать числовые и объектные данные. Например, если вы хотите присвоить члену-переменной значение 83, вы можете избежать необходимости явного использования оператора lock (или явного применения логики Monitor), если используете метод Interlocked.Exchange().

    public void SafeAssignment() {

     Interlocked.Exchange(ref myInt, 83);

    }

    Наконец, при проверке двух значений на равенство, чтобы обеспечить потоковую безопасность элементу сравнения, можете использовать метод Interlocked.CompareExchange(), как показано ниже.

    public void CompareAndExchange() {

     // Если значением i является 83, изменить его на 99.

     Interlocked.CompareExchange(ref i, 99, 83);

    }

    Синхронизация с помощью атрибута [Synchronization]

    Последним из рассмотренных здесь примитивов синхронизации будет атрибут [Synchronization], который определяется в пространстве имен System.Runtime.Remoting.Contexts. Этот атрибут уровня класса для безопасности потока эффективно блокирует весь программный код членов экземпляра. Когда среда CLR размещает объект, имеющий атрибут [Synchronization], она помещает этот объект в рамки синхронизированного контекста. Вы должны помнить из главы 13, что объекты, которые не должны покидать контекстные границы, являются производными от ContextBoundObject. Поэтому, чтобы сделать тип класса Printer устойчивым в отношении потоков (без добавления программного кода защиты потоков вручную), следует изменить соответствующее определение так.

    using System.Runtime.Remoting.Contexts;

    ...

    // Все методы Printer теперь потокоустойчивы!

    [Synchronization]

    public class Printer: СontextBoundObject {

     public void PrintNumbers() {

     …

     }

    }

    Этот подход можно назвать способом создания потокоустойчивого программного кода для ленивых, поскольку здесь не требуется выяснять, какие фрагменты типа могут испытывать влияние внешних потоков. Главным недостатком этого подхода является то, что даже если какой-то метод и не испытывает влияния внешних потоков, среда CLR все равно блокирует обращение к этому методу. Очевидно, это может ухудшить общие характеристики функционирования типа, так что используйте указанный подход с осторожностью.

    Итак, мы с вами обсудили целый ряд подходов к решению вопроса синхронизированного доступа к общим блокам данных. Будьте уверены, в пространстве имен System.Threading есть и другие типы, которые я настоятельно рекомендую вам постепенно исследовать. В завершение этой главы, посвященной программированию потоков, давайте рассмотрим три: дополнительных типа: TimerCallback, Timer и ThreadPool.

    Программирование с помощью таймеров обратного вызова

    Во многих приложениях возникает необходимость вызывать конкретный метод через регулярные промежутки времени. Например, в одном приложении может потребоваться отображение текущего времени в строке состояния с помощью некоторой вспомогательной функции. В другом приложении может понадобиться периодический вызов вспомогательной функции, выполняющей в фоновом режиме какие-то некритические задачи, например проверку поступления новых сообщений электронной почты. Для таких ситуаций можно использовать тип System. Threading.Timer в совокупности с соответствующим делегатом TimerCallback.

    Для примера предположим, что нам нужно создать консольное приложение, которое ежесекундно выводит текущее время, пока пользователь не нажмет клавишу, завершающую выполнение этого приложения. Первым очевидным шагом здесь является создание метода, который будет вызываться типом Timer.

    class TimePrinter {

     static void PrintTime(object state) {

      Console.WriteLine("Время: {0}", DateTime.Now.ToLongTimeString());

     }

    }

    Этот метод имеет один параметр типа System.Object и возвращает void. Такая структура метода обязательна, поскольку делегат TimerCallback может вызывать только такие методы. Значение, передаваемое целевому методу делегата TimerCallback, может представлять любую информацию (так, в случае электронной почты это может быть имя сервера Microsoft Exchange, с которым требуется взаимодействие в ходе процесса). А так как параметр является типом System.Object, в действительности можно передать любое число аргументов, если использовать System.Array или пользовательский класс (структуру).

    Следующим шагом является настройка экземпляра делегата TimerCallback и передача его объекту Timer. Кроме делегата TimerCallback, конструктор Timer позволяет указать дополнительную информацию (в виде System.Object) для передачи ее целевому объекту делегата, временной интервал опроса метода и время ожидания (в миллисекундах) до начала первого вызова, например:

    static void Main(string[] args) {

     Console.WriteLine("***** Работа с типом Timer *****\n");

     // Создание делегата для типа Timer.

     TimerCallback timeCB = new TimerCallback(PrintTime);

     // Установка параметров таймера.

     Timer t = new Timer(

      timeCB, // Тип делегата TimerCallback.

      null, // Информация для вызываемого метода или null.

      0, // Время ожидания до старта.

      1000); // Интервал между вызовами (в миллисекундах) .

     Console.WriteLine("Нажмите «Enter» для завершения работы…");

     Console.ReadLine();

    }

    В данном случае метод PrintTime() будет вызываться примерно каждую секунду и методу не передается никакой дополнительной информации. Чтобы передать целевому объекту делегата какую-то информацию, замените значение null второго параметра конструктора подходящим значением (например, "Привет"). Следующая модификация метода PrintTime() использует переданное значение.

    static void PrintTime(Object state) {

     Console.WriteLine("Время: {0}, Параметр: {1}", DateTime.Now.ToLongTimeString(), state.ToString());

    }

    На рис. 14.11 показан соответствующий вывод.

    Рис. 14.11. Таймеры за работой

    Исходный код. Проект TimerApp размещен в подкаталоге, соответствующем главе 14.

    Пул потоков CLR

    Заключительной темой нашего обсуждения в этой плаве, посвященной потокам, будет пул потоков CLR. При асинхронном вызове типов с помощью делегатов (посредством метода BeginInvoke()) нельзя сказать, что среда CLR буквально создает совершенно новый поток. В целях эффективности метод BeginInvoke() делегата использует пул (динамическую область) рабочих потоков, поддерживаемых средой выполнения. Чтобы позволить вам взаимодействовать с этим пулом рабочих потоков, пространство имен System.Threading предлагает тип класса ThreadPool.

    Чтобы поставить вызов метода в очередь для обработки рабочим потоком из пула, используйте метод ThreadPool.QueueUserWorkItem(). Этот метод является перегруженным, чтобы вдобавок к экземпляру делегата WaitCallback имелась возможность указать необязательный System.Objеct для пользовательских данных состояния.

    public sealed class ThreadPool {

     …

     public static bool QueueUserWorkItem(WaitCallback callBack);

     public static bool QueueUserWorkItem(WaitCallback callBack, object state);

    }

    Делегат WaitCallback может указывать на любой метод, имеющий один параметр System.Object (для представления необязательных данных состояния) и не возвращающий ничего. Если при вызове QueueUserWorkItem() вы не предложите System.Object, среда CLR автоматически передаст значение null. Для иллюстрации методов очереди при использовании пула потоков CLR давайте рассмотрим следующую программу, в которой снова используется тип Printer. Но на этот раз мы не будем создавать массив типов Thread вручную, а свяжем метод PrintNumbers() с членами пула.

    class Program {

     static void Main(string[] args) {

      Console.WriteLine("Старт главного потока. ThreadID = {0}", Thread.CurrentThread.GetHashCode());

      Printer p = new Printer();

      WaitCallback workItem = new WaitCallback(PrintTheNumbers);

      // Очередь из 10 вызовов метода.

      for (int i = 0; i ‹ 10; i++) {

       ThreadPool.QueueUserWorkItem(workItem, p);

      }

      Console.WriteLine("Все задачи в очереди");

      Console.ReadLine();

     }

     static void PrintTheNumbers(object state) {

      Printer task = (Printer)state;

      task.PrintNumbers();

     }

    }

    Здесь вы можете спросить, разве выгодно использовать поддерживаемый средой CLR пул потоков вместо явного создания объектов Thread? Тогда рассмотрите следующие главные преимущества использования пула.

    • Пул потоков управляет потоками эффективнее, поскольку минимизируется число потоков, которые приходится создавать, запускать и останавливать.

    • При использовании пула потоков вы можете сосредоточиться на своей конкретной задаче, не отвлекаясь на вопросы инфраструктуры потоков приложения.

    Однако управление потоками "вручную" может оказаться предпочтительнее, например, в следующих случаях.

    • Если требуется создавать приоритетные потоки или устанавливать приоритеты потоков. Потоки, помещенные в пул, всегда являются фоновыми потоками с обычным уровнем приоритета (ThreadPriority.Normal).

    • Если требуется создать поток с фиксированным идентификатором, чтобы име-лаcь возможность завершить, приостановить или обнаружить его по имени.

    Исходный код. Проект ThreadPoolApp размещён в подкаталоге, соответствующем главе 14.

    На этом наш экскурс в многопоточное программирование .NET завершается. Пространство имен System.Threading, без сомнения, определяет множество других типов, кроме тех, которые смогли уместиться в рамках обсуждения данной главы. Но сейчас вы имеете прочный фундамент, который позволит вам расширять свой знания.

    Резюме

    Эта глава началась с рассмотрения того, как настроить тип делегата .NET на вызов методов в асинхронной форме. Как было показано, методы BeginInvoke() и EndInvoke() позволяют косвенно управлять фоновыми потоками с минимальными усилиями и практически без проблем. В ходе обсуждения были рассмотрены интерфейс IAsyncResult и тип класса AsyncResult. Эти типы обеспечивают различные способы синхронизации вызовов и получения возвращаемых значений методов.

    Оставшаяся часть главы была посвящена выяснению роли пространства имен System.Threading. Вы узнали о том, что в результате создания приложением дополнительных потоков программа получает (мнимую) возможность выполнять множество задании одновременно. Были рассмотрены различные способы защиты блоков программного кода, уязвимых в отношении потоков, чтобы при совместном использовании ресурсов потоками не происходило повреждения данных. Наконец, вы узнали о том, что среда CLR поддерживает пул потоков с целью повышения общей производительности системы и удобства ее использования.

    ГЛАВА 15. CIL и роль динамических компоновочных блоков

    В этой главе ставится две задачи. В первой половине главы будет рассмотрен синтаксис и семантика языка CIL (Common Intermediate Language – общий промежуточный язык) намного более подробно, чем в предыдущих главах. Честно говоря, при создании программ .NET вполне можно обойтись и без непосредственного изучения подробностей внутреннего устройства CIL-кода. Однако, изучив основы CIL, вы получите более глубокое понимание того, как функционируют некоторые "магические" особенности .NET (например, межъязыковое наследование). В оставшейся части главы будет исследована роль пространства имен System. Reflection.Emit. Используя его типы, вы получаете возможность строить программное обеспечение, способное генерировать компоновочные блоки .NET в памяти во время выполнения. Формально компоновочные блоки, определенные и выполняемые в памяти, называют динамическими компоновочными блоками. Как вы можете догадаться, эта специальная возможность .NET требует знания языка CIL, поскольку от вас потребуется указать набор CIL-инструкций, которые будут использоваться при создании компоновочного блока.

    Природа программирования в терминах CIL

    CIL – это родной язык платформы .NET, Когда вы создаете компоновочный блок .NET, используя тот управляемый язык, который вы предпочитаете, соответствующий компилятор переводит ваш исходный код в термины CIL. Подобно любому языку программирования, язык CIL предлагает множество программных и структурных лексем. Поскольку CIL является одним из языков программирования .NET не должно быть удивительным то, что вполне возможно создавать компоновочные блоки .NET непосредственно с помощью CIL и CIL-компилятора (ilasm.exe), вхо-дящего в стандартную поставку .NET Framework 2.0 SDK.

    Хотя вполне очевидно, что лишь немногие программисты предпочтут строить свои .NET-приложения непосредственно на языке CIL, язык CIL сам по себе является чрезвычайно интересным объектом для интеллектуального исследования. Проще говоря, чем лучше вы понимаете грамматику CIL, тем увереннее вы будете себя чувствовать в мире нетривиальных приемов разработки .NET. Если говорить конкретно, то разработчик, обладающий пониманием языка CIL, получает следующее.

    • Понимание того, как различные языки программирования .NET проецируют свои ключевые слова в лексемы CIL.

    • Возможность дезассемблирования компоновочных блоков .NET, редактирования программного кода CIL и перекомпиляции обновленного базового кода в измененный двоичный код  .NET

    • Возможность построения динамических компоновочных блоков с помощью элементов пространства имен System.Refleсtion.Emit.

    • Иcпользование тех возможностей CTS (Common Type System – общая система типов), которые не поддерживаются управляемыми языками более высокого уровня, но существуют на уровне CIL. Язык CIL является единственным языком .NET, позволяющим получить доступ ко всем возможностям CTS.

    Например, используя CIL, вы можете определять члены и поля глобального уровня (что не позволено в C#).

    Снова заметим, чтобы было предельно ясно, что если вы не хотите углубляться в детали внутреннего устройства программного кода CIL, вам может быть вполне достаточно освоения возможностей библиотек базовых классов .NET. Во многих отношениях роль понимания языка CIL аналогична роли понимания языка ассемблера программистом, использующим C(++). Тем, кто понимает низкоуровневые возможности, проще находить хитроумные решения сложных задач с учетом тонких требований среды программирования (и среды выполнения). Так что если вы готовы принять вызов, давайте приступим к. рассмотрению особенностей CIL.

    Замечание. Следует понимать, что в данной главе не предлагается всестороннее и исчерпывающее описание синтаксиса и семантики CIL. Если вам требуется всесторонний анализ возможностей CIL, обратитесь к книге Jason Bock, CIL Programming: Under the Hood of .NET (Apress, 2002).

    Директивы, атрибуты и коды операций CIL

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

    {new, public, this, base, get, set, explicit, unsafe, enum, operator, partial}

    Вы, скорее всего, идентифицируете их, как ключевые слова языка C# (и это правильно). Но если присмотреться к элементам этого набора более внимательно, вы сможете заметить, что хотя здесь каждый элемент и является ключевым словом C#, они имеют совершенно разную семантику. Например, ключевое слово enum определяет тип, производный от System.Enum, а ключевые слова this и base позволяют ссылаться, соответственно, на текущий объект или родительский класс объекта. Ключевое слово unsafe используется для создания блока программного вода, который не должен непосредственно контролироваться средой CLR, а ключевое слово operator позволяет построить скрытый (специально именованный) метод, который будет вызываться тогда, когда вы применяете заданный оператор C# (например, знак сложения).

    В отличие от такого высокоуровневого языка, как C#, язык CIL не просто определяет свой собственный набор ключевых слов. Набор лексем, понятных компилятору CIL, разделяется на три большие категории, в зависимости от семантического подтекста:

    • директивы CIL;

    • атрибуты CIL;

    • коды операций CIL.

    Каждая категория лексем CIL выражается с помощью своих специальных синтаксических конструкций, а сами лексемы объединяются с тем, чтобы в результате получился работоспособный компоновочный блок .NET.

    Роль директив CIL

    Прежде всего, есть множество известных лексем CIL, которые используются для описания полной структуры компоновочного блока .NET. Эти лексемы называются директивами. Директивы CIL используются дли информирования компилятора CIL о том, как определять пространства имен, типы и члены, содержащиеся в компоновочном блоке.

    Синтаксически директивы обозначаются с помощью префикса, представленного точкой (.) (например, .namespace, .class, .publickeytoken, .override, .method, .assembly и т.д.). Так, если ваш файл *.il (обычное расширение для файла, содержащего программный код CIL) имеет одну директиву .namespace и три директивы .сlass, компилятор CIL сгенерирует компоновочный блок, который определит одно пространства имен .NET и три типа класса .NET.

    Роль атрибутов CIL

    Во многих случаях директивы CIL сами по себе оказываются недостаточно информативными, чтобы дать исчерпывающее определение соответствующего типа .NET или его члена. Поэтому многие директивы CIL сопровождаются различными атрибутами CIL, сообщающими о том, как должна обрабатываться данная директива. Например, директива .class может сопровождаться атрибутам public (чтобы задать параметры видимости типа), атрибутом extends (чтобы явно указать базовый класс типа) или атрибутом implements (чтобы задать список интерфейсов, поддерживаемых типом).

    Роль кодов операций CIL

    После определения компоновочного блока .NET, пространства имен и набора типов в терминах GIL с использованием различных директив и связанных атрибутов остается одно – предложить программную логику реализации типа. Это является задачей кодов операций. В соответствии с традициями других языков низкого уровня, коды операций CIL, как правило, имеют просто непроизносимые аббревиатуры. Например, чтобы определить переменную строки, используется не понятный код операции LoadString, a ldstr.

    Но все же, что не может не радовать, некоторые коды операций CIL в точности соответствуют их аналогам в C# (это, например, box, unbox, throw и sizeof). Вы сможете убедиться в том, что коды операций CIL всегда используются в контексте реализации члена и, в отличие от директив CIL, они никогда не обозначаются префиксом, заданным точкой.

    Различия между мнемоникой и кодом операции CIL

    Как только что объяснялось, коды операций, например ldstr, используются для реализации членов данного типа. Но в реальности лексемы (в том числе и ldstr) являются мнемониками CIL, представляющими на самом деле двоичные коды операций CIL. Чтобы пояснить различие, предположим, что у нас есть следующий метод, созданный средствами C#.

    static int Add(int x, int у) {

     return х + у;

    }

    В терминах CIL сложение двух чисел представлено кодом операции 0X58. Аналогично для представления вычитания используется код операции 0X59, а действие, соответствующее размещению нового объекта в управляемой динамической памяти, обозначается кодом операции 0X73. С учетом сказанного должно быть ясно, что CIL-код, обрабатываемый JIT-компилятором, на самом деле является набором двоичных данных.

    К счастью, для каждого двоичного кода операции CIL есть соответствующая мнемоника. Например, мнемоника add может использоваться вместо 0X58, sub – вместо 0X59, a newobj – вместо 0X73. Ввиду указанных различий между мнемониками и кодами операций, нетрудно догадаться, что декомпиляторы CIL, такие как, например, ildasm.exe, переводят двоичные коды операций компоновочного блока в соответствующую мнемонику CIL.

    .method public hidebysig static int32 Add(int32 x, int32 y) cil managed {

     …

     // Лексема 'add' является более понятной мнемоникой CIL,

     // используемой для представления кода операции 0X58.

     add

     …

    }

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

    Добавление и извлечение данных: стековая природа CIL

    Высокоуровневые языки .NET (например, такие как C#) пытаются максимально скрыть низкоуровневые сложности. Одним из аспектов разработки .NET, который оказывается скрытым особенно хорошо, является тот факт, что CIL является языком, целиком основанным на стековом программировании. Напомним, что при исследований пространства имен System.Collections (см. главу 7) мы с вами выяснили, что тип stack может использоваться для добавления значения в стек, а также для удаления из стека значения, размещенного на вершине стека. Конечно, разработчики CIL-приложений для загрузки и выгрузки значений не используют непосредственно объект System.Сollections.Stack, однако они применяют аналогичные операции.

    Формально объект, используемый для хранения набора значений, называется виртуальным стеком выполнения. Вы сможете убедиться в том, что CIL предлагает целый ряд кодов операций, которые используются для добавления значения в стек: соответствующий процесс называется загрузкой. Точно так же CIL определяет целый ряд других кодов операций, которые переносят значение с вершины стека в память (например, в локальную переменную): для обозначения этого процесса используется термин сохранение.

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

    Чтобы понять, как CIL использует стековую модель, рассмотрим простой C#-метод PrintMessage(), который не имеет аргументов и ничего не возвращает. В рамках реализации этого метода вы просто выводите значение локальной строковой переменной в поток стандартного вывода.

    public void PrintMessage() {

     string myMessage = "Привет.";

     Consolе.WriteLine(myMessage);

    }

    Если рассмотреть результат трансляции этого метода компилятором C# в термины CIL, вы сразу заметите, что метод PrintMessage() определяет ячейку хранения для локальной переменной, используя директиву.locals. Локальная строка затем загружается и сохраняется в этой локальной неременной с помощью кодов операций ldstr (загрузка строки) и stloc.0 (это можно прочитать, как "запомнить текущее значение в локальной переменной с индексом 0").

    Значение (снова с индексом 0) затем загружается в память с помощью кода операции ldloc.0 ("загрузить локальный аргумент с индексом 0") для использования в вызове метода System.Console.WriteLine() (указанном с помощью кода операции call). Наконец, происходит возврат из функции через код операции ret.

    .method public hidebysig instance void PrintMessage() cil managed {

     .maxstack 1

     // Определение локальной строковой переменной (с индексом 0).

     .locals init ([0] string myMessage)

     // Загрузка строки со значением "Привет."

     ldstr "Привет."

     // Сохранение строкового значения в стеке в локальной переменной.

     stloc.0

     // Загрузка значения с индексом 0.

     ldloc.0

     // Вызов метода с текущим значением.

     call void [mscorlib]System.Console::WriteLine(string)

     ret

    }

    Замечание. В программном коде CIL поддерживаются комментарии, использующие синтаксис двойной косой черты (а также синтаксис /*…*/). Как и в C#, компилятором CIL комментарии просто игнорируются.

    Челночная технология разработки

    Вы уже знаете, как использовать ildasm.exe для просмотра программного кода CIL, генерируемого компилятором C#. Однако вы можете не знать о том, что ildasm.exe позволяет записать CIL-код, содержащийся в загруженном компоновочном блоке, во внешний файл. Имея программный код CIL в своем распоряжении, вы можете отредактировать и с помощью ildasm.exe – компилятора CIL – скомпилировать базовый код вновь.

    Формально такой подход называется челночной технологией разработки, и эта технология может оказаться полезной в следующих случаях.

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

    • Ввиду несовершенства компилятора языка .NET, сгенерировавшего неэффективный программный код CIL, вы хотите изменить этот код.

    • Вы создаете компоновочные блоки, взаимодействующие в рамках COM, и вам приходится принимать во внимание то, что некоторые атрибуты IDL (Interface Definition Language – язык описания интерфейса) в процессе преобразования могут теряться (например, COM-атрибут [helpstring]).

    Для примера использования челночной технологии разработки создайте новый файл (HelloProgram.cs) исходного кода C# с помощью обычного текстового редактора и определите в этом файле следующий тип класса (можете, конечно, использовать и Visual Studio 2005, но тогда не забудьте удалить файл AssemblyInfo.cs, чтобы уменьшить объем генерируемого CIL-кода).

    // Простое консольное приложение на языке C#.

    using System;

    class Program {

     static void Main(string[] args) {

      Console.WriteLine("Hello CIL code!");

      Console.ReadLine();

     }

    }

    Сохраните этот файл в подходящем месте на своем диске и скомпилируйте его с помощью программы csc.exe.

    csc HelloProgram.cs

    Теперь откройте полученный файл HelloProgram.exe с помощью ildasm.exe и, используя опцию меню File>Dump, сохраните "сырой" программный код CIL в новом файле *.il (HelloProgram.il) На вашем жестком диске (значения, предлагаемые в появляющемся диалоговом окне, вполне подойдут для наших целей). Теперь вы можете рассмотреть этот файл, используя любой текстовый редактор. Вот слегка откорректированный в снабженный некоторыми комментариями результат.

    // Компоновочные блоки, на которые мы ссылаемся.

    .assembly extern mscorlib {

     .publickeytoken = (В7 7A 5С 56 19 34 Е0 89)

     .ver 2:0:0:0

    }

    // Ваш компоновочный блок.

    .assembly HelloProgram {

     .hash algorithm 0х00008004

    .ver 0:0:0:0

    }

    .module HelloProgram.exe

    .imagebase 0x00400000

    .file alignment 0x00000200

    .stackreserve 0x00100000

    .subsystem 0x0003

    .corflags 0x00000001

    // Определение класса Program.

    .class private auto ansi beforefieldinit Program extends [mscorlib]System.Object {

     .method private hidebysig static void Main(string[] args) cil managed {

      // Обозначение этого метода, как точки входа

      // выполняемого файла.

      .entrypoint

      .maxstack.8

      IL_0000: nop

      IL_0001: ldstr "Hello CIL code!"

      IL_0006: call void [mscorlib]System.Console::WriteLine(string)

      IL_000b: nop

      IL_000c: call string [mscorlib]System.Console::ReadLine()

      IL_0011: pop

      IL_0012: ret

     }

     // Конструктор, заданный по умолчанию.

     .method public hidebysig specialname rtspecialname instance void .ctor() cil managed {

      .maxstack 8

      IL_0000: ldarg.0

      IL_0001: call instance void [mscorlib]System.Object::.ctor()

      IL_0006: ret

     }

    }

    Во-первых, обратите внимание на то, что файл *.il начинается с объявления всех внешних компоновочных блоков, на которые ссылается данный компоновочный блок. Здесь вы видите только одну директиву .assembly extern для одного обязательно присутствующего mscorlib.dll. Если бы ваша библиотека классов использовала типы из других внешних компоновочных блоков, вы бы обнаружили дополнительные директивы .assembly extern.

    Далее следует формальное определение вашего компоновочного блока HelloProgram.exe, для которого указана версия 0.0.0.0, назначаемая по умолчанию (если вы не укажете иное значение с помощью атрибута [AssemblyVersion]). После этого приводятся другие описания компоновочного блока, для которых используются другие директивы CIL (такие, как .module, .imagebase и т.д.).

    После указания ссылок на внешние компоновочные блоки и определения текущего компоновочного блока идет определение типа Program. Обратите внимание на то, что директива.class имеет несколько атрибутов (многие из которых необязательны), – например, атрибут extends, задающий базовый класс типа.

    .class private auto ansi beforefieldinit Program extends [mscorlib]System.Object {…}

    Большой кусок программного кода CIL соответствует конструктору класса, заданному по умолчанию, и методу Main(). Оба они определены (в частности) с помощью директивы .method. После определения этих членов с помощью подходящих директив и атрибутов они реализуются с помощью различных кодов операций.

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

    .method private hidebysig static void Main(string[] args) cil managed {

     .entrypoint

     .maxstack 8

     IL_0000: nop

     IL_0001: ldstr "Hello CIL code!"

     IL_0006: call void [mscorlib]System.Console::WriteLine(string)

     IL_000b: nop

     IL_000c: call string [mscorlib]System.Console::ReadLine()

     IL_0011: pop

     IL_0012: ret

    }

    Реализация конструктора, заданного по умолчанию, в терминах программного кода CIL включает еще одну относящуюся к загрузке инструкцию (ldarg.0). В данном случае значение загружается в стек не как пользовательская переменная, указанная нами, а как текущая объектная ссылка (подробности этого процесса будут описаны позже). Также обратите внимание на то, что конструктор, заданный по умолчанию, явно вызывает конструктор базового класса.

    .method public hidebysig specialname rtspecialname instance void .ctor cil managed {

     .maxstack 8

     IL_0000: ldarg.0

     IL_0001: call instance void [mscorlib]System.Object::.ctor()

     IL_0006: ret

    }

    Роль меток в программном коде CIL

    Вы. конечно, заметили, что в каждой строке программного кода реализации содержится префикс в форме лексемы IL_XXX: (например, IL_0000: IL_0001: и т.д.). Эти лексемы называются метками кода, и они могут иметь любой вид, какой вы только пожелаете (лишь бы они не дублировались в пределах одного и того же контекста). При записи содержимого компоновочного блока в файл с помощью ildasm.exe автоматически генерируются метки кода, имеющие вид IL_XXX:. Но вы можете изменить их с тем, чтобы они стали более информативными.

    .method private hidebysig static void Main(string[] args) cil managed {

     .entrypoint

     .maxstack 8

     Nothing_1: nop

     Load_String: ldstr "Hello CIL code!"

     PrintToConsole: call void [mscorlib]System.Console::WriteLine(string)

     Nothing_2: nop

     WaitFor_KeyPress: call string [mscorlib] System.Console::ReadLine()

     RemoveValueFromStack: pop

     Leave_Functlon: ret

    }

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

    .method private hidebysig static void Main(string[] args) cil managed {

     .entrypoint

     .maxstack 8

     nop

     ldstr "Hello CIL code!"

     call void [mscorlib]System.Console::WriteLine(string)

     nop

     call string [mscorlib]System.Console::ReadLine()

     pop

     ret

    }

    Взаимодействие с CIL: модификация файла *.il

    Теперь, когда вы понимаете, как компонуется базовый файл CIL, давайте завершим наш эксперимент с челночной технологией разработки программ. С помощью изменения CIL-кода в файле *.il мы должны выполнить следующее.

    • Добавить ссылку на компоновочный блок System.Windows.Forms.dll.

    • Загрузить локальную строку в Main().

    • Вызвать метод System.Windows.Forms.MessageBox.Show(), используя локальную строковую переменную в качестве его аргумента.

    Первым шагом является добавление новой директивы.assembly (с атрибутом extern), которая укажет, что используется System.Windows.Forms.dll. Для этого просто добавьте в файл *.il следующую программную логику после ссылки на внешний компоновочный блок mscorlib.

    .assembly extern System.Windows.Forms {

     .publickeytoken = (B7 7A 5C 56 19 34 E0 89)

     .ver 2:0:0:0

    }

    Значение, указанное директивой .ver. может у вас оказаться другим, поскольку оно зависит от версии платформы .NET, установленной на вашей машине. Здесь указано использование System.Windows.Forms.dll версии 2.0.0.0 с кодом открытого ключа В77А5С561934Е089. Если открыть GAC (см. главу 11) и найти там компоновочный блок System.Windows.Forms.dll, можно скопировать правильный номер версии и значение открытого ключа со страницы свойств этого компоновочного блока.

    .method private hidebysig static void Main(string[] args) cil managed {

     .entrypoint

     .maxstack 8

     // Задача: написать новый CIL-код.

    }

    Итак, целью является помещение новой строки в стек и вызов метода MessageBox.Show() (а не метода Console.WriteLine()). Напомним, что при указании имени внешнего типа следует использовать абсолютное имя типа (в совокупности с понятным именем компоновочного блока). С учетом этого обновите метод Main() так, как показано ниже.

    .method private hidebysig static void Main(string[] args) cil managed {

     .entrypoint

     .maxstack 8

     ldstr "CIL работает прекрасно!"

     call valuetype [System.Windows.Forms] System.Windows.Forms.DialogResult [System.Windows.Forms] System.Windows.Forms.MessageBox::Show(string)

     pop

     ret

    }

    В результате вы получите программный код CIL, соответствующий следующему определению класса C#.

    public class Program {

     static void Main(string[] args) {

      System.Windows.Forms.MessageBox.Show("CIL работает прекрасно!");

     }

    }

    Компиляция CIL-кода с помощью ilasm.exe

    Сохранив измененный файл *.il, вы можете скомпилировать новый компоновочный блок .NET, используя для этого утилиту ilasm.exe (компилятор CIL). Возможно, вы удивитесь тому, что компилятор CIL имеет гораздо меньше опций командной строки, чем компилятор C#. В табл. 15.1 приводятся их описания.

    Таблица 15.1. Опции командной строки ilasm.exe 

    Опция Описание
    /debug Включает информацию отладки (такую как имена локальных переменных и аргументов, а также номера строк)
    /dll Создает выходной файл" *.dll
    /exe Создает выходной файл *.exe. Это значение устанавливается по умолчанию, поэтому его можно опустить
    /key Компилирует компоновочный блок со строгим именем, используя заданный файл *.snk
    /noautoinherit Запрещает автоматическое наследование типов класса из System. Object, когда конкретный базовый класс не определен
    /output Указывает имя и расширение выходного файла. Если флаг /output не используется, имя выходного файла будет соответствовать имени первого исходного файла

    Чтобы откомпилировать обновленный файл simplehelloclass.il в .NET-файл *.exe, в командном окне Visual Studio 2005 выполните следующую команду.

    ilasm.exe HelloProgram.il

    Если все пройдет без сбоев, вы должны получить вывод, подобный показанному на рис. 15.1.

    Рис. 15.1. Компиляция файлов *.il с помощью ilasm.exe

    После этого вы сможете выполнить свое новое приложение. Достаточно очевидно, что теперь вместо сообщения в окне консоли вы должны увидеть окно Windows с вашим сообщением (рис. 15.2).

    Рис. 15.2. Результат челночной технологии

    Компиляция CIL-кода с помощью SharpDevelop

    Для работы с файлами *.il вы можете использовать бесплатную среду разработки SharpDevelop (см. главу 2). При создании нового "комбината" (для этого выберите File>New Combine из меню), одним из вариантов выбора является создание рабочего пространства CIL-проекта. Хотя SharpDevelop пока что не предлагает поддержку IntelliSense для CIL-проектов, лексемы CIL выделяются цветом, и вы получаете возможность компилировать и выполнять свои приложения непосредственно в окне IDE (а не в командной строке, как в случае ilasm.exe).

    Компиляция CIL-кода с помощью ILIDE#

    Если вам интересно поэкспериментировать с языком программирования CIL, рекомендую загрузить самую последнюю версию бесплатного редактора исходных текстов CIL, имеющего открытый код и название ILIDE#. Этот инструмент, подобно SharpDevelop, обеспечивает выделение цветом ключевых слов и программных структур, интеграцию с ilasm.exe и набор соответствующих инструментов. В отличие от SharpDevelop, последняя версия ILIDE# поддерживает IntelliSense для CIL. Установщик ILIDE# можно загрузить со страницы http://ilide.aspfreeserver.com/default-en.aspx (этот адрес URL может измениться). На рис. 15.3 показано окно ILIDE# в действии.

    Рис. 15.3. Редактор ILIDE# – бесплатная среда разработки для CIL

    Роль peverify.exe

    При создании или модификации компоновочных блоков, в которых используется программный код CIL, всегда целесообразно проверить, будет ли скомпилированный двоичный образ правильно сформирован с точки зрения правил .NET. Для этого можно использовать средство командной строки peverify.exe.

    peverifу HelloProgram.exe

    Этот инструмент проверит все коды операций в указанном компоновочном блоке на соответствие правилам CIL. Например, в терминах CIL-кода стек оценок должен всегда опустошаться: перед выходом из функции, Если вы забудете извлечь из него какие-то значения, компилятор ilasm.exe все равно сгенерирует допустимый компоновочный блок (поскольку компиляторы "заботятся" только о синтаксисе).

    А вот peverifу.exe, с другой стороны, заботится о семантике. Если вы забудете очистить стек перед выходом из функции, peverify.exe сообщит вам об этом.

    Исходный код. Файл HelloProgram.il размещен в подкаталоге, соответствующем главе 15.

    Директивы и атрибуты CIL

    Теперь, когда вы знаете, как использовать ildasm.exe и ilasm.exe в рамках челночной технологии разработки, мы можем заняться непосредственным анализом синтаксиса и семантики CIL. Следующие разделы предлагают описание процесса построения пользовательского пространства имен, содержащего определенный набор типов. Чтобы упростить рассмотрение, эти типы не будут содержать никакого программного кода реализации их членов. После того как вы поймете, как создаются пустые типы, вы сможете сосредоточить все свое внимание на процессе создания "реальных" членов типа с помощью кодов операций CIL.

    Ссылки на внешние компоновочные блоки

    С помощью любого редактора создайте новый файл, назвав его CilTypes.il. Сначала вы должны указать список внешних компоновочных блоков, используемых текущим компоновочным блоком (в нашем примере мы будем использовать только типы из mscorlib.dll). Для этого нужно указать директиву .assembly с атрибутом external. При ссылке на строго именованный компоновочный блок, такой как mscorlib.dll, вы должны также указать директивы .publickeytoken и .ver.

    .assembly extern mscorlib {

     .publickeytoken = (B7 7A 5C 56 19 34 E0 89)

     .ver 2:0:0:0

    }

    Замечание. Строго говоря, явная ссылка на внешний компоновочный блок mscorlib.dll не является обязательной, поскольку ilasm.exe добавит такую ссылку автоматически.

    Определение текущего компоновочного блока

    Следующей задачей является определение компоновочного блока, который вы хотите построить. Это делается с помощью директивы .assembly. В простейшем случае компоновочный блок можно определить с помощью простого указания понятного имени соответствующего двоичного файла.

    // Наш компоновочный блок.

    .assembly CILTypes {}

    Это действительно определяет новый компоновочный блок .NET, но обычно в рамках декларации компоновочного блока размещаются дополнительные директивы. Для нашего примера добавьте в определение компоновочного блока номер версии 1.0.0.0 с помощью директивы .ver (заметьте, что все числовые идентификаторы в определении должны разделяться двоеточием, не точкой, как в C#).

    // Наш компоновочный блок.

    .assembly CILTypes {

     .ver 1:0:0:0

    }

    Поскольку компоновочный блок CILTypes является одномодульным компоновочным блоком, определение этого компоновочного блока завершается единственной директивой.module, которая указывает официальное имя двоичного .NET-файла, CILTypes.dll.

    .assembly CILTypes {

    .ver 1:0:0:0

    }

    // Этот модуль является одномодульным компоновочным блоком.

    .module CILTypes.dll

    Кроме директив .assembly и .module, есть и другие CIL-директивы, обеспечивающие дальнейшее уточнение структуры создаваемого двоичного файла .NET. В табл. 15.2 предлагаются описания еще двух директив уровня компоновочного блока,

    Таблица 15.2. Дополнительные директивы компоновочного блока

    Директива Описание
    .mresources Если компоновочный блок использует встраиваемый ресурс (например, точечный рисунок или таблицу строк), эта директива используется для идентификации имени файла, содержавшего такой ресурс. В главе 20 ресурсы .NET рассматриваются подробно
    .subsystem Эта директива CIL используется для указания предпочтительного пользовательского интерфейса для выполнения компоновочного блока, например, значение 2 означает, что компоновочный блок должен выполняться в рамках графического интерфейса с поддержкой форм, а значение 3 означает консольное приложение

    Определение пространств имен

    Итак, вы определили вид своего компоновочного блока (и необходимые внешние ссылки). Теперь можно создать пространство имен .NET (МуNamespace), используя для этого директиву .namespace.

    // Наш компоновочный блок имеет одно пространство имен.

    .namespace MyNamespace {}

    Как и в C#, определение пространства имен CIL можно вложить во внешнее пространство имен. Вот пример вложения нашего пространства имен в корневое пространство имен с именем IntertechTraining.

    .namespace IntertechTraining {

     .namespace MyNamespace {}

    }

    Кроме того, как и C#, язык CIL позволяет определить вложенное пространство имен так.

    // Определение вложенного пространства имен.

    .namespace IntertechTraining.MyNamespace{}

    Определение типов класса

    Пустые пространства имен не представляют собой большого интереса, поэтому давайте выясним, как в CIL определяется тип класса. Вполне логично, что для этого используется директива .class. Однако эта простая директива может иметь множество дополнительных атрибутов, уточняющих природу создаваемого типа. Для примера мы добавим простой общедоступный класс с именем MyBaseClass. Как и в C#, если не указать базовый класс явно, соответствующий тип будет автоматически получаться из System.Object.

    .namespace MyNamespace {

     // В качестве базового класса предполагается System.Object.

     .class public MyBaseClass {}

    }

    Для создания типа класса, являющегося производным от любого класса, отличного от System.Object, используется атрибут extends. При ссылке на тип, определенный в пределах того же компоновочного блока, CIL требует, чтобы вы указали абсолютное имя (однако для базового класса из того же компоновочного блока вы можете опустить префикс, представляющий понятное имя компоновочного блока). Так, следующий вариант модификации MyBaseClass приведет к ошибке компиляции.

    // Это компилироваться не будет!

    .namespace MyNamespace {

     .class public MyBaseClass {}

     .class public MyDerivedClass extends MyBaseClass {}

    }

    Чтобы корректно определить родительский класс для MyDerivedClass, следует указать полное имя MyBaseClass, как показано ниже.

    // Так будет лучше!

    .namespace MyNamespace {

     .class public MyBaseClass {}

     .class public MyDerivedClass extends MyNamespace.MyBaseClass {}

    }

    Вдобавок к атрибутам public и extends определение класса CIL может иметь множество дополнительных спецификаторов, задающих параметры видимости типа, размещения полей и т.д. В табл. 15.3 предлагаются описаний некоторых атрибутов, которые могут использоваться с директивой .class.

    Таблица 15.3. Атрибуты, которые могут использоваться с директивой .class

    Атрибут Описание
    public, private, nested assembly, nested famandassem, nested family, nested famorassem, nested public, nested private В CIL определяется множество атрибутов, используемых для указании параметров видимости типа. Как видите, CIL предлагает целый ряд возможностей, не доступных в C#
    abstract sealed Эти два атрибута можно добавить к директиве.class, чтобы определить абстрактный класс или изолированный класс, соответственно
    auto sequential explicit Эти атрибуты используются для информирования CLR о том, как следует размещать поля данных в памяти. Для типов класса вполне подойдет вариант, используемый по умолчанию (auto)
    extends implements Эти атрибуты позволяют определить базовый класс типа (с помощью extends) или реализовать интерфейс (с помощью implements)

    Определение и реализация интерфейсов

    Как бы это странно ни выглядело, типы интерфейса определяются в CIL с помощью директивы .class. Но когда директива .сlass сопровождается атрибутом interface, соответствующий тип реализуется, как тип интерфейса CTS (Common Type System – общая система типов). После определения интерфейс можно привязать к типу класса или структуры с помощью CIL-атрибута implements.

    .namespace MyNamespace {

     // Определение интерфейса.

     .class public interface IMyInterface {}

     .class public MyBaseClass {}

     // Теперь DerivedTestClass реализует IAmAnInterface.

     class public MyDerivedClass

      extends MyNamespace.MyBaseClass implements MyNamespace.IMyInterface {}

    }

    Как было показано в главе 7, интерфейсы могут выступать в качестве базовых интерфейсов в отношении других типов интерфейса, в результате чего создаются иерархии интерфейсов. Однако, вопреки вашим возможным догадкам, атрибут extends нельзя использовать для получения интерфейса А из интерфейса В. Атрибут extends используется только для указания базового класса типа. Чтобы расширить интерфейс, вы должны еще раз использовать атрибут implements.

    // Расширение интерфейсов в терминах CIL.

    .class public interface IMyInterface {}

    .class public interface IMyOtherInterface implements MyNamespace.IMyInterface {}

    Определение структур

    Директива .class может использоваться и для определения CTS-структуры, если соответствующий тип расширяет System.ValueType. Кроме того, такая директива .class сопровождается атрибутом sealed (поскольку структура не может быть базовой по отношению к другим типам, характеризуемым значениями). Если вы попытаетесь сделать иначе, ilasm.exe сгенерирует ошибку компиляции.

    // Структура всегда должна быть изолированной.

    .class public sealed MyStruct extends [mscorlib]System.ValueType {}

    Полезно знать о том, что CIL предлагает специальное сокращение для определения типа структуры. Если вы используете атрибут value, новый тип будет производным от [mscorlib] System.ValueType и получит атрибут sealed автоматически. Таким образом, можно определить MyStruct так.

    // Сокращенная запись для определения структуры.

    .class public value MyStruct{}

    Определение перечней

    Перечни .NET (как вы помните) получаются из класса System.Enum, производного от System.ValueType (и, таким образом, тоже должны быть изолированными). Чтобы определить перечень в терминах CIL, следует просто расширить [mscorlib]System.Enum.

    // Перечень.

    .class public sealed MyEnum extends [mscorlib]System.Enum {}

    Как и для структур, для определения перечней имеется специальное сокращение, атрибут enum.

    // Сокращенная запись для определения перечня.

    .class public enum MyEnum {}

    Замечание. Последний из фундаментальных типов данных .NET, делегат, тоже имеет специальное представление в CIL. Подробности можно найти в главе 6.

    Компиляция файла CILTypes.il

    Даже если вы не добавите никаких членов или иного программного кода в определенные вами типы, вы можете скомпилировать файл *.il в компоновочный блок DLL (иное просто невозможно, поскольку вы не указали метод Main()).

    Откройте окно командной строки и введите следующую команду.

    ilasm /dll CilTypes.il

    После этого вы сможете открыть свой двоичный файл в ildasm.exe (рис. 15.4).

    Рис. 15.4. Содержимое компоновочного блока CILTypes.dll

    Проверив содержимое своего компоновочного блока, запустите для него peverify.exe. В результате будет выдан целый ряд сообщений об ошибках, поскольку все ваши типы пусты. Чтобы понять, как заполнить типы содержимым, мы должны сначала рассмотреть базовые типы данных CIL.

    Исходный код. Файл CilTypes.il размещен в подкаталоге, соответствующем главе 15.

    Соответствие между типами библиотеки базовых классов .NET, C# и CIL

    В табл. 15.4 показано соответствие между типами базовых классов .NET и ключевыми словами C#, а также между ключевыми словами C# и командами CIL. Там же представлены сокращенные обозначения констант, используемые для CIL-типов. Чуть позже вы сможете убедиться в том, что при использовании кодов операций C#, часто используются и ссылки на эти константы.

    Определение членов типов в CIL

    Вы уже знаете, что типы .NET могут определить различные члены. Перечни содержат некоторый набор пар имен и значений. Структуры и классы могут иметь конструкторы, поля, методы, свойства, статические члены и т.д. В предыдущих 14 главах вы уже могли видеть фрагменты определений CIL для таких элементов, но тем не менее, ниже предлагается краткая сводка того, как различные члены отображаются в примитивы CIL.

    Таблица 15.4. Связь между типами базовых классов .NET и ключевыми словами C#, а также их проекция в CIL

    Тип базового класса .NET Ключевое слово C# Представление CIL Обозначение для константы CIL
    System.SByte sbyte int8 I1
    System.Byte byte unsigned int8 U1
    System.Int16 short int16 I2
    System.UInt16 ushort unsigned int16 U2
    System.Int32 int int32 I4
    System.UInt32 uint unsigned int32 U4
    System.Int64 long int64 I8
    System.UInt64 ulong unsigned int64 U8
    System.Char char char CHAR
    System.Single float float32 R4
    System.Double double float64 R8
    System.Boolean bool bool BOOLEAN
    System.String string string
    System.Object object object
    System.Void void void VOID

    Определение полей данных

    Перечни, структуры и классы могут поддерживать поля данных. Во всех случаях для указания таких полей используется директива. field. Например, чтобы добавить немного сути в каркас MyEnum, давайте определим для него три пары имен и значений (заметьте, что значения здесь указываются в скобках).

    .class public auto ansi sealed MyEnum extends [mscorlib]System.Enum {

     .field public static literal valuetype MyNamespace.MyEnum NameOne = int32(0)

     .field public static literal valuetype MyNamespace.MyEnum NameTwo = int32(1)

     .field public static literal valuetype MyNamespace.MyEnum NameThree = int32(2)

    }

    Поля, размещаемые в рамках контекста типа .NET, производного от System.Enum, сопровождаются атрибутами static и literal. Вам должно быть ясно, что эти атрибуты соответствуют полям данных, имеющим фиксированное значение и доступным из данного типа непосредственно (например, с помощью MyEnum.NameOne).

    Замечание. Значения, присваиваемые полям перечня, могут также быть шестнадцатиричными.

    Конечно, при определении полей данных в пределах класса или структуры вы не ограничены использованием только открытых статических литералов. Можно, например, добавить в MyBaseClass поддержку двух приватных полей данных уровня экземпляра.

    .class public MyBaseClass {

     .field private string stringField

     .field private int32 intField

    }

    Как и в C#, полям данных класса будут автоматически назначены подходящие значения для непользовании по умолчанию. Чтобы позволить пользователю объекта указать во время создания объекта пользовательские значения для приватных полей данных, придется (конечно) создать пользовательские конструкторы.

    Определение конструкторов типов

    Система CTS (общая система типов) поддерживает конструкторы как уровня экземпляра, так и уровня класса (статические конструкторы). В терминах CIL для конструкторов уровня экземпляра используется лексема .ctor, а для статических конструкторов – лексема .cctor (конструктор класса). Обе эти лексемы CIL должны сопровождаться атрибутами rtspecialname (специальное имя возвращаемого типа) и specialname. Эти атрибуты используются для идентификации специальных лексем CIL, позволяющих уникальное толкование в каждом языке .NET. Например, в C# конструкторы не определяют возвращаемый тип, однако в терминах CIL возвращаемым значением конструктора на самом деле будет void.

    .class public MyBaseClass {

     .field private string stringField

     .field private int32 intField

     .method public hidebysig specialname rtspecialname instance void .ctor(string s, int32 i) cil managed {

      // Задача: добавить необходимый программный код.

     }

    }

    Обратите внимание на то, что директива .ctor сопровождается атрибутом instance (поскольку это не статический конструктор). Атрибуты cil managed означают, что в контексте этого метода содержится программный код CIL (а не программный код, не являющийся управляемым), который может использоваться в межплатформенных запросах.

    Определение свойств

    Свойства и методы также имеют специальные представления в CIL. Чтобы в нашем примере обеспечить в MyBaseClass поддержку открытого свойства TheString, можно использовать следующий CIL-код (заметьте, что здесь опять используется атрибут specialname).

    .class public MyBaseClass {

     …

     .method public hidebysig specialname instance string get_TheString() cil managed {

      // Задача: добавить необходимый программный код…

     }

     .method public hidebysig specialname instance void set_TheString(string 'value') cil managed {

      // Задача: добавить необходимый программный ход.…

     }

     .property instance string TheString() {

      .get instance string MyNamespace.MyBaseClass::get_TheString()

      .set instance void MyNamespace.MyBaseClass::set_TheString(string)

     }

    }

    Напомним, что в терминах CIL свойства будут представлены парой методов, имеющих префиксы get_ и set_. Директива .property использует соответствующие директивы .get и .set, чтобы связать синтаксис свойства со "специально именованными" методами.

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

    Определение параметров членов

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

    Чтобы показать пример определения параметров непосредственно в CIL, предположим, что нам нужно построить метод, который получает int32 (по значению), int32 (по ссылке), [mscorlib] System.Collections.ArrayList и имеет единственный выходной параметр (типа int32). В терминах C# этот метод должен выглядеть приблизительно так.

    public static void MyMethod(int inputInt, ref int refInt, ArrayList ar, out int outputInt) {

     outputInt = 0; // Просто чтобы удовлетворить компилятор C#…

    }

    Если спроецировать этот метод в CIL-код, вы обнаружите, что ссылки на параметры C# будут обозначены знаком амперсанда (&), добавленного в виде суффикса к типу данных, соответствующему параметру (int32&). Для выходных параметров тоже используется суффикс &, но, кроме того, они обозначены маркером CIL [out], Также обратите внимание на то, что в том случае, когда параметр является ссылочным типом (как тип [mscorlib]System.Collections.ArrayList в нашем примере), ему предшествует лексема class (не путайте с директивой .class!).

    .method public hidebysig static void MyMethod(int32 inputInt, int32& refInt, class [mscorlib]System.Collections.ArrayList ar, [out] int32& outputInt) cil managed {

     …

    }

    Анализ кодов операций CIL

    Заключительной темой нашего обсуждения в этой главе в отношении программного кода CIL будет роль кодов операций. Напомним, что код операции – это просто лексема CIL, используемая для построения логики реализации данного члена. Полный набор кодов операций CIL (который сам по себе довольно велик) можно разбить на следующие большие категории.

    • Коды операций для управления программой

    • Коды операций для оценки выражений

    • Коды операций для осуществления доступа к значениям в памяти (через параметры, локальные переменный и т.п.)

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

    Таблица 15.5. Коды операций CIL, связанные с реализацией членов

    Коды операций Описание
    add, sub, mul, div, rem Позволяют выполнять сложение, вычитание, умножение и деление для пар значений (rem возвращает остаток от деления)
    and, or, not, xor Позволяют выполнять соответствующие бинарные операции для пар значений
    ceq, cgt, clt Позволяют сравнивать пару значений из стека различными способами, например: ceq: сравнение в отношении равенства cgt: сравнение в отношении "больше" clt: сравнение в отношении "меньше"
    box, unbox Используются для конвертирования ссылочных типов и типов, характеризуемых значениями
    ret Используется для выхода из метода и (если это необходимо) возвращения значения вызывающей стороне
    beq, bgt, ble, blt, switch Используются (в дополнение к множеству других родственных кодов операций) для управления логикой ветвления в методах, например: beq: переход к заданной метке, если выполняется равенство bgt: переход к заданной метке, если больше ble: переход к заданной метке, если меньше или равно blt: переход к заданной метке, если меньше Все коды операций, связанные с ветвлением, требуют указания метки CIL-кода, по которой должен осуществляться переход в том случае, когда соответствующее сравнение возвращает true
    call Используется для вызова члена указанного типа
    newarr, newobj Позволяет разместить в памяти новый массив или новый объект (cоответственно)

    Следующая большая категория кодов операций CIL (подмножество которой показано в табл. 15.6) используется для загрузки аргументов в виртуальный стек выполнения. Обратите внимание на то, что эти относящиеся к загрузке коды операций имеют префикс ld (load – загрузка).

    Таблица 15.6. Коды операций CIL для помещения данных в стек

    Код операции  Описание
    ldarg (с множеством вариаций) Помещает в стек аргумент метода. Вдобавок к общей операции ldarg (для которой требуется указать индекс, идентифицирующий аргумент), есть множество ее вариаций. Например, ldarg с числовым суффиксом (ldarg_0) используется для загрузки соответствующего аргумента. Другие вариации ldarg позволяют с помощью кодов констант CIL из табл. 15.4 указать конкретный тип загружаемых данных (например, ldarg_I4 для int32), а также тип данных и значение (ldarg_I4_5 для загрузки int32 со значением 5)
    ldc (с множеством вариаций) Помещает в стек значение константы
    ldfld (с множеством вариаций) Помещает в стек значение поля уровня экземпляра
    ldloc (с множеством вариаций) Помещает в стек значение локальной переменной
    ldobj Читает все значения объекта, размещенного в динамической памяти, и помещает их в стек
    ldstr Помещает в стек строковое значение 

    Вдобавок к множеству специальных кодов операций загрузки, CIL предлагает набор кодов операций, которые непосредственно "выталкивают" из стека самое верхнее значение. Как продемонстрировали первые несколько примеров этой главы, удаление значения из стека обычно выполняется с целью последующего сохранения этого значения в локальной памяти для дальнейшего использования (например, в качестве параметра при последующем вызове метода). С учетом этого становится ясно, почему многие коды операций, связанные с удалением текущего значения из виртуального стека выполнения, имеют префикс st (store – сохранять). Соответствующие описания приведены в табл. 15.7.

    Таблица 15.7. Коды операций для извлечения данных из cтека

    Код операции Описание
    pop Удаляет значение, находящееся в настоящий момент на вершине стека, но не обеспечивает сохранение этого значения
    starg Сохраняет значение из вершины стека в аргументе метода с указанным индексом
    stloc (c множеством вариаций) Удаляет значение, находящееся на вершине стека, и запоминает это значение в переменной с указанным индексом из списка локальных переменных
    stobj Копирует значение указанного типа из стека в память по указанному адресу
    stsfld Заменяет значение статического поля значением из cтека

    Следует также знать о том, что различные коды операций CIL при выполнении своих задач неявно удаляют значения из стека. Например, при вычитании одного числа из другого с помощью операции sub следует учитывать то, что прежде чем выполнить соответствующее вычисление, sub "вытолкнет" из стека два доступных значения. После выполнения операции в стек добавляется результат (как неожиданно!).

    Директива .maxstack

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

    .method public hidebysig instanсе void Speak() cil managed {

     // В контексте этого метода в стек помещается ровно

     // одно значение (строковый литерал).

     .maxstack 1

     ldstr "Всем привет…"

     call void [mscorlib]System.Consolr::WriteLine(string)

     ret

    }

    Объявление локальных переменных

    Давайте выясним, как объявляются локальные переменные. Предположим, что мы должны построить в терминах CIL метод MyLocalVariables(), не имеющий никаких аргументов и возвращающий void. В этом методе мы должны определить три локальные переменные типов System.String, System.Int32 и System.Object. В C# соответствующий программный код мог бы выглядеть так, как показано ниже (напомним, что локальные переменные не получают значения по умолчанию, поэтому им перед использованием необходимо присвоить начальные значения).

    public static void MyLocalVariables() {

     string myStr = "CIL me dude…";

     int myInt = 33;

     object myObj = new object();

    }

    Если создавать MyLocalVariables() непосредственно в CIL, можно было бы написать следующее,

    .method public hidebysig static void MyLocalVariables() cil managed {

     .maxstack 6

     // Определение трех локальных переданных.

     .locals init ([0] string myStr, [1]int32 myInt, [2]object myObj)

     // Загрузка строки в виртуальный стек выполнения.

    ldstr "CIL me dude…"

     // Извлечение текущего значения и сохранение его

     // в локальной переменной [0].

     stloc.0

     // Загрузка константы типа 'i4'

     // (сокращение для int32) со значением 33.

     ldc.i4 33

     // Извлечение текущего значения и сохранение его

     // в локальной переменной [1].

     stloc.1

     // Создание нового объекта и помещение его в стек.

    newobj instance void [mscorlib]System.Object::.ctor()

     // Извлечение текущего значения и сохранение его

     // в локальной переменной [2].

     stloc.2

     ret

    }

    Как видите, в CIL при размещении локальных переменных сначала используется директива .locals с атрибутом init. При этом в скобках каждая переменная связывается со своим числовым индексом (здесь это [0], [1] и [2]). Каждый индекс идентифицируется типом данных и (необязательно) именем переменной. После определения локальных переменных соответствующее значение загружается в стек (с помощью подходящих кодов операций, связанных с загрузкой) и запоминается в локальной переменной (с помощью подходящих кодов операций для сохранения значений).

    Связывание параметров с локальными переменными

    Вы только что видели, как в CIL с помощью .local init объявляются локальные переменные, однако нужно еще выяснить, как передать отступающие параметры локальным методом. Рассмотрим следующий статический метод C#.

    public static int Add(int a, int b) {

     return a + b;

    }

    Этот внешне "невинный" метод в терминах CIL существенно более "многословен". Во-первых, поступающие аргументы (а и b) следует поместить в виртуальный стек выполнение с помощью кода операций ldarg (загрузка аргумента). Затем используется код операции add, чтобы извлечь два значения из стека, найти сумму и снова сохранить значение в стеке. Наконец, эта сумма извлекается из стена и возвращается вызывающей стороне с помощью кода операции ret. Если дизассемблировать указанный метод C# с помощью ildasm.exe, вы обнаружите, что компилятор csc.exe добавляет множество дополнительных лексем, хотя сущность CIL-кода оказывается исключительно простой.

    .method public hidebysig static int32 Add(int32 a, int32 b) cil managed {

     .maxstack 2

     ldarg.0 // Загрузка 'a' в стек,

     ldarg.1 // Загрузка 'b' стек,

     add // Сложение этих значений.

     ret

    }

    Скрытая ссылка this

    Обратите внимание на то, что в рамках программного кода CIL для ссылок на два входных аргумента (а и b) используются их индексы позиции (индекс 0 и индекс 1, поскольку индексация в виртуальном стеке выполнения начинается с нуля).

    При анализе программного кода и его создании непосредственно в CIL следует быть очень внимательным, поскольку каждый (нестатический) метод, имеющий входные аргументы, автоматически получает неявный дополнительный параметр, который является ссылкой на текущий объект (это должно вызвать аналогию с ключевым словом C# this). Поэтому, если определить метод Add(), как нестатический

    // Уже не является статическим!

    public int Add(int a, int b) {

     return a + b;

    }

    то входные аргументы а и b будут загружаться с помощью ldarg.1 и ldarg.2 (а не с помощью ожидаемых ldarg.0 и ldarg.1). Причина как раз в том, что ячейка 0 будет содержать неявную ссылку this. Рассмотрите следующий псевдокод.

    // Это только псевдокод!

    .method public hidebysig static int32 AddTwoIntParams(MyClass_HiddenThisPointer this, int32 a, int32 b) cil managed {

     ldarg.0 // Загрузка MyClass_HiddenThisPointer в стек,

     ldarg.1 // Загрузка 'а' в стек.

     ldarg.2 // Загрузка 'b' в стек.

     …

    }

    Представление итерационных конструкций

    Итерационные конструкции в языке программирования C# представляются с помощью ключевых слов for, foreach, while и do, каждое из которых имеет свое специальное представление в CIL. Рассмотрим классический цикл for.

    public static void CountToTen() {

     for (int i = 0; i ‹ 10; i++);

    }

    Вы можете помнить о том, что коды операций br (br, blt и т.д.) используются для управления потоком программы в зависимости от выполнения некоторого условия. В нашем примере мы задали условие, по которому должен произойти выход из цикла, когда значение локальной переменной i станет равным 10. С каждым проходом к значению i добавляется 1, после чего сразу же выполняется тестовое сравнение.

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

    .method public hidebysig static void CountToTen() cil managed {

     .maxstack 2

     .locals init ([0] int32 i) // Инициализация локальной целой 'i'.

     IL_0000: ldc.i4.0 // Загрузка этого значения в стек.

     IL_0001: stloc.0 // Сохранение значения под индексом '0'.

     IL_0002: br.s IL_0008 // Переход к IL_0008.

     IL_0004: ldloc.0 // Загрузка значения с индексом 0.

     IL_0005: ldc.i4.1 // Загрузка значения '1' в стек.

     IL_0006: add // Добавление в стек под индексом 0.

     IL_0007: stloc.0

     IL_0008: ldloc.0 // Загрузка значения с индексом '0'.

     IL_0009: ldc.i4.s 10 // Загрузка значения '10' в стек.

     IL_000b: blt.s IL_0004 // Меньше? Если да, то к 1L_0004.

     IL_000d: ret

    }

    В сущности, этот программный код CIL начинается с определения локальной переменной int32 и загрузки ее в стек. Затем осуществляются переходы между командами с метками IL_0008 и IL_0004, причем каждый раз значение i увеличивается на 1 и проверяется, осталось ли это значение меньше 10. Если нет, то происходит выход из метода.

    Создание компоновочного блока .NET в CIL

    Теперь, освоив синтаксис и семантику CIL, вы можете закрепить свои знания на практике, построив приложение .NET с использованием только CIL и текстового редактора. Ваше приложение будет состоять из приватного одномодульного *.dll, содержащего два определения типов класса, и консольного *.exe, взаимодействующего с этими типами.

    Создание CILCars.dll

    Первым делом следует построить файл *.dll для использования клиентом. Откройте любой текстовый редактор и создайте новый файл *.il с именем CILCars.il. Этот одномодульный компоновочный блок будет использовать два внешних двоичных файла .NET, поэтому вы можете начать свой файл программного кода CIL так.

    // Ссылка на mscorlib.dll и

    // System.Windows.Forms.dll

    .assemblу extern mscorlib {

     .publickeytoken = (B7 7A 5С 56 19 34 E0 89)

     .ver 2:0:0:0

    }

    .assembly extern System.Windows.Forms {

     .publickeytoken = (B7 7A 5C 56 19 34 E0 89)

     .ver 2:0:0:0

    }

    // Определение одномодульного компоновочного блока.

    .assembly CILCars {

     .hash algorithm 0х00008004

     .ver 1:0:0:0

    }

    .modulе СILCars.dll

    Как уже было сказано, этот компоновочный блок будет содержать два типа класса. Первый тип, CILCar, определяет два поля данных и пользовательский конструктор. Второй тип, CarInfoHelper, определяет единственный статический метод с именем DisplayCarInfо(), который использует CILCar в качестве параметра и возвращает void. Оба типа находятся в пространстве имен CILCars. В терминах CIL класс CILCar можно реализовать так.

    // Реализация типа CILCars.CILCar.

    .namespace CILCars {

     .class public auto ansi beforefieldinit CILCar extends [mscorlib]System.Object {

      // Поле данных CILCar.

    .field public string petName

      .field public int32 currSpeed

      // Пользовательский конструктор, который дает пользователю

      // возможность присвоить полю данные.

      .method public hidebysig specialname rtspecialname instance void .ctor(int32 c, string p) cil managed {

       .maxstack 8

       // Загрузка первого аргумента в стек и вызов

       // конструктора базового класса.

       ldarg.0 // объект 'this', а не int32!

       call instance void [mscorlib]System.Object::.ctor()

       // Теперь загрузка первого и второго аргументов в стек.

       ldarg.0 // объект 'this'

       ldarg.1 // аргумент int32

       // Сохранение элемента вершины стека (int 32) в поле currSpeed.

       stfld int32 CILCars.CILCar::currSpeed

       // Загрузка строкового аргумента и сохранение в поле petName.

       ldarg.0 // объект 'this'

       ldarg.2 // аргумент string

       stfld string CILCars.CILCar::petName

       ret

      }

     }

    }

    Имея в виду, что настоящим первым аргументом любого нестатического члена является объектная ссылка this, в первом блоке CIL-кода мы просто загружаем эту объектную ссылку и вызываем конструктор базового класса. Затем поступающие аргументы конструктора помещаются в стек и запоминаются в полях данных типа с помощью кода операции stfld (сохранение в поле).

    Далее, вы должны реализовать второй тип в данном пространстве имен, а именно тип CILCarInfo. Суть типа находится в статическом методе Display(). Основной задачей этого метода является получение поступающего параметра CILCar, извлечение значения поля данных и вывод его в окне сообщения Windows Forms. Вот полная реализация CILCarInfo, а далее следует ее анализ.

    .class public auto ansi beforefieldinit CILCarInfo extends [mscorlib]System.Object {

     .method public hidebysig static void Display(class CILCars.CILCar c) cil managed {

      .maxstасk 8

      // Нам нужна локальная строковая переменная.

      .locals init ([0] string caption)

      // Загрузка строки и входного CILCar в стек.

      ldstr "Скорость [0]: "

      ldarg.0

      // Помещение значения petName класса CILCar в стек и

      // вызов статического метода String.Format().

      ldfld string CILCars.CILCar::petName

      call string [mscorlib]System.String::Format(string, object)

      stloc.0

      // Загрузка значения поля currSpeed и получение его строкового // представления (обратите внимание на вызов ToString()).

      ldarg.0

      ldflda int32 CILCars.CILCar::currSpeed

      call instance string [mscorlib]System.Int32::ToString()

      ldloc.0

      // Вызов метода MessageBox.Show() с загруженными значениями.

      call valuetype [System.Windows.Forms] System.Windows.Forms.DialogResult [Sуstem.Windоws.Forms] System.Windows.Forms.MessageBox::Show(string, string)

      pop

      ret

     }

    }

    Хотя здесь объем программного кода CIL заметно больше, чем в случае реализации CILCar, на самом деле все довольно просто. Во-первых, поскольку вы определяете статический метод, вам не придется иметь дел со скрытой объектной ссылкой (поэтому код операции ldarg.0 действительно загружает поступающий аргумент CILCar).

    Метод начинается с загрузки строки ("Скорость {0}: ") в стек за которой следует аргумент CILCar. Когда эти два значения оказываются в нужном месте, загружается значение поля petName и вызывается статический метод System.String. Format(), чтобы вместо замещающих фигурных скобок получить имя CILCar.

    Та же общая процедура выполняется и при обработке поля currSpeed, но следует отметить, что здесь используется код. операции ldarga, которая загружает адрес аргумента в стек. Затем вызывается System.Int32.ToString(), чтобы преобразовать значение, размещенное по указанному адресу, в строковый тип. Наконец, когда обе строки отформатированы так, как требуется, вызывается метод MessageBox.Show().

    Теперь вы можете скомпилировать свой новый файл *.dll с помощью ilasm.exe, используя команду

    ilasm /dll CILCars.il

    а затем проверить полученный CIL-код с помощью peverifу.exe.

    peverify CILCars.dll

    Создание CILCarClient.exe

    Теперь нам нужно построить простой компоновочный блок *.exe, который должен выполнить следующее.

    • Создать тип CILCar.

    • Передать этот тип статическому методу CILCarInfo.Display(),

    Создайте новый файл *.il и определите внешние ссылки на mscorlib.dll и CILCars.dll (не забудьте поместить копию этого компоновочного блока .NET в каталог приложения клиента!). Затем определите единственный тип (Program), который использует компоновочный блок CILCars.dll. Вот соответствующий программный код, приведенный полностью.

    // Ссылки на внешние компоновочные блоки.

    .assembly extern mscorlib {

     .publickeytoken = (B7 7A 5C 56 19 34 E0 89)

     .ver 2:0:0:0

    }

    .assembly extern CILCars {

     .ver 1:0:0:0

    }

    // Наш выполняемый компоновочный блок.

    .assembly CILCarClient {

     .hash algorithm 0x00008004

     .ver 0:0:0:0

    }

    .module CILCarClient.exe

    // Реализация типа Program.

    .namespace CILCarClient {

     .class private auto ansi beforefieldinit Program extends [mscorlib]System.Object {

      .method private hidebysig static void Main(string[] args) cil managed {

       // Обозначает точку входа *.exe.

       .entrypoint

       .maxstack 8

       // Объявление локального типа CILCar и добавление в стек

       // значений для вызова конструктора.

       .locals init ([0] class [CILCars]CILCars.CILCar myCilCar)

       ldc.i4 55

       ldstr "Junior"

       // Создание нового CILCar: сохранение и загрузка ссылки.

       newobj: instance void [CILCars] CILCars.CILCar::.сtor(int32, string)

       stloc.0

       ldloc.0

       // Вызов Display() и передача верхнего значения из стека.

       call void [CILCars] CILCars.CILCarInfo::Display(class [CILCars]CILCars.CILCar)

       ret

      }

     }

    }

    Здесь единственным кодом операции, заслуживающим комментария, является .entrуpoint. Напомним, что этот код операций используется для обозначения метода, который должен выступать в качестве точки входа модуля *.eхе. Ввиду того, что среда CLR идентифицирует начальный метод для выполнения именно с помощью.entrypoint, сам метод может называться как угодно (хотя в нашем примере он называется Main()). В остальном CIL-код метода Main() представляет действия, связанные с добавлением значений в стек и извлечением их из стека.

    Заметьте, однако, что для создания CILCar используется код операции.newobj. В связи с этим напомним, что при вызове члена типа непосредственно в CIL вы должны применить синтаксис с использованием двойного двоеточия и, как всегда, указать абсолютное имя типа. Восприняв сказанное, вы можете скомпилировать свой новый файл с помощью ilasm.exe, проверить полученный компоновочный блок с помощью peverifу.exe, а затем выполнить программу.

    ilasm CilCarClient.il

    peverify CilCarClient.exe

    CILCarClient.exe

    На рис. 15.5 показан конечный результат.

    Рис. 15.5. Ваш CILCar в действии

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

    Динамические компоновочные блоки

    Как видите, процесс создания сложного приложения .NET непосредственно в CIL оказывается довольно трудоемким. С одной стороны, CIL является чрезвычайно выразительным языком программирования, позволяющим взаимодействовать со всеми программными конструкциями, допустимыми в CTS. С другой стороны, создание CIL-кода является делом скучным, утомительным и сопряженным с множеством ошибок. Хотя верно и то, что знание – это сила, вы можете поинтересоваться, действительно ли это так важно, чтобы "загромождать" законами синтаксиса CIL свою память. Я отвечу так: это зависит от многого. Конечно, для большинства ваших .NET-проектов рассматривать, редактировать или непосредственно создавать программный код CIL не потребуется. Но, освоив азбуку CIL, вы теперь готовы к обсуждению динамических компоновочных блоков (которые называются так в противоположность статическим компоновочным блокам) и роли пространства имен System.Reflection.Emit.

    Здесь сразу же может возникнуть вопрос: "В чем разница между статическими и динамическими компоновочными блоками?" По определению, статические компоновочные блоки являются двоичными файлами .NET, загружаемыми по запросу CLR непосредственно с диска (в предположении о том, что они размещены где-то на вашем жестком диске в физическом файле или, возможно, во множестве файлов, если компоновочный блок является многомодульным). Как вы можете догадаться сами, каждый раз, когда вы компилируете исходный код C#, вы получаете статический компоновочный блок.

    Динамический компоновочный блок, с другой стороны, создается в памяти "на лету", с использованием типов, предлагаемых пространством имен System. Reflection.Emit. Пространство имен System.Reflection.Emit делает возможным создание компоновочного блока и его модулей, определений типов и логики реализации CIL прямо в среде выполнения. Создав компоновочный блок таким образом, вы можете сохранить свой находящийся в памяти двоичный объект на диск. В результате, конечно, получится новый статический компоновочный блок. Для понимания процесса построения динамического компоновочного блока с помощью пространства имен System.Reflection.Emit требуется определенный уровень понимания кодов операций CIL.

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

    • При создании инструментов программирования .NET. позволяющих по требованию динамически генерировать компоновочные блоки в зависимости от пользовательского ввода.

    • При создании программ, способных динамически генерировать агенты доступа к удаленным типам на основе получаемых метаданных.

    • При загрузке статических компоновочных блоков с динамическим добавлением новых типов в двоичный образ.

    Учитывая сказанное, давайте рассмотрим типы, предлагаемые в System.Reflection.Emit.

    Исследование пространства имен System.Reflection.Emit

    Для создания динамического компоновочного блока требуется в определенной мере понимать коды операций CIL, но типы пространства имен System.Reflection. Emit в максимальной мере "пытаются" скрыть сложность CIL. Например, вместо прямого указания необходимых директив и атрибутов CIL при определении типа класса вы можете просто использовать класс TypeBuilder. Точно так же, чтобы определить новый конструктор уровня экземпляра, нет никакой необходимости использовать specialname, rtspecialname и лексемы .ctor – вместо этого можно просто использовать ConstructorBuilder. Описания ключевых членов пространства имен System.Reflection.Emit приводятся в табл. 15.8.

    Таблица 15.8. Избранные члены пространства имен System.Reflection.Emit

    Члены Описание
    AssemblyBuilder Используется для создания компоновочного блока (*.dll или *.exe) в среде выполнения. В случае *.exe следует вызвать метод ModuleBuilder.SetEntryPoint(), чтобы указать метод, являющийся точкой входа в модуль. Если точка входа не указана, будет сгенерирована *.dll
    ModuleBuilder Используется для определения множества модулей в рамках данного компоновочного блока
    EnumBuilder Используется для создания типа перечня .NET
    TypeBuilder Может использоваться дли создания классов, интерфейсов, структур и делегатов в рамках модуля в среде выполнения
    MethodBuilder EventBuilder LocalBuilder PropertyBuilder FieldBuilder ConstructorBuilder CustomAttributeBuilder ParameterBuilder Используются для создания членов типа (таких как методы, локальные переменные, свойства, конструкторы и атрибуты) в среде выполнения
    ILGenerator Генерирует коды операций CIL в данном члене типа
    OpCodes Обеспечивает множество полей, отображающихся в коды операций CIL. Этот тип используется вместе с различными членами System.Reflection.Emit.ILGenerator

    В общем, типы пространства имен System.Reflection.Emit при построении динамического двоичного модуля позволяют представлять "сырые" лексемы CIL программными единицами. Возможности использования многих из указанных членов будут продемонстрированы в следующем примере, но тип ILGenerator заслуживает отдельного обсуждения.

    Роль System.Reflection.Emit.ILGenerator

    Как следует из самого имени указанного типа, роль ILGenerator заключается в добавлении кодов операций CIL в данный член типа. Обычно нет необходимости непосредственно создавать объект ILGenerator, а нужно просто получить действительную ссылку на тип ILGenerator, используя типы, связанные с компоновщиком (такие как MethodBuilder и ConstructorBuilder). Например:

    // Получение ILGenerator из объекта ConstructorBuilder

    // с именем 'myCtorBuilder'.

    ConstructorBuilder myCtorBuilder = new ConstructorBuilder (/*…различные аргументы… */);

     ILGenerator myCILGen = myCtorBuilder.GetILGenerator();

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

    Таблица 15.9. Подборка методов ILGenerator

    Метод Описание
    BeginCatchBlock() Начинает блок catch
    BeginExceptionBlock() Начинает блок неотфильтрованного исключения
    BeginFinallyBlock() Начинает блок finally
    BeginScope() Начинает лексический контекст
    DeclareLocal() Объявляет локальную переменную
    DefineLabel() Объявляет новую метку
    Emit() Является перегруженным и позволяет генерировать коды операций CIL
    EmitCall() Вставляет код операции call или callvirt в поток CIL
    EmitWriteLine() Генерирует вызов Console.WriteLine() с различными типами значений
    EndExceptionBlock() Завершает блок исключения
    EndScope() Завершает лексический контекст
    ThrowException() Создает инструкцию для генерирования исключения
    UsingNamespace() Указывает пространство имен, которое будет использоваться для оценки локальных переменных и наблюдаемых значений в текущем активном лексическом контексте

    Ключевым методом ILGenerator является метод Emit(), который работает в совокупности с типом класса System.Reflection.Emit.OpCodes. Как уже упоминалось в этой главе, данный тип открывает большой набор доступных только для чтения полей, отображающихся в коды операций CIL. Полностью эти члены описаны в оперативно доступной системе справки, но целый ряд примеров вы сможете увидеть и на следующих страницах.

    Генерирование динамического компоновочного блока

    Чтобы проиллюстрировать процесс определения компоновочного блока .NET в среде выполнения, давайте создадим одномодульный динамический компоновочный блок с именем MyAssembly.dll. В этом модуле будет содержаться класс HelloWorld. Тип HelloWorld поддерживает конструктор, используемый по умолчанию, и пользовательский конструктор для присваивания значения приватной переменной (theMessage) типа string. Кроме того, HelloWorld предлагает открытый метод экземпляра с именем SayHello(), который выводит приветствие в стандартный поток ввода-вывода, а также еще один метод экземпляра, GetMsg(), который возвращает внутреннюю приватную строку. В результате вы должны программно сгенерировать следующий тип класса.

    // Этот класс будет создан в среде выполнения

    // с помощью System.Reflection.Emit.

    public class HelloWorld {

     private string theMessage;

     HelloWorld() {}

     HelloWorld(string s) { theMessage = s; }

     public string GetMsg() { return theMessage; }

     public void SayHello() {

      System.Console.WriteLine("Привет от класса HelloWorld!");

     }

    }

    Предположим, вы cоздали новый проект консольного приложения в Visual Studio 2005, назвав его DynAsmBuilder. Переименуйте исходный класс в MyAsmBuilder и определите статический метод с именем CreateMyAsm(). Этот единственный метод будет ответственен за следующее:

    • определение характеристик динамического компоновочного блока (имя, версия и т.д.);

    • реализацию тина HelloClass;

    • запись компоновочного блока, сгенерированного в памяти, в физический файл.

    Также отметим, что метод CreateMyAsm() использует в качестве единственного параметра тип System.AppDomain, который будет использоваться для получения доступа к типу AssemblyBuilder, связанному с текущим доменом приложения (см. главу 13, где обсуждаются домены приложений .NET). Вот полный программный код, с последующим анализом.

    // Вызывающая сторона посылает тип AppDomain.

    public static void CreateMyAsm(AppDomain currAppDomain) {

     // Установка общих характеристик компоновочного блока.

     AssemblyName assemblyName = new AssemblyName();

     assemblyName.Name = "MyAssembly";

     assemblyName.Version = new Version("1.0.0.0");

     // Создание нового компоновочного блока

     // в рамках текущего домена приложения.

     AssemblyBuilder assembly = curAppDomain.DefineDynamicAssembly(assemblyName, AssemblyBuilderAccess.Save);

     // Поскольку создается одномодульный компоновочный блок,

     // имя модуля будет совпадать с именем компоновочного блока.

     ModuleBuilder module = assembly.DefineDynamicModule("MyAssembly", "MyAssemblу.dll");

     // Определение открытого класса с именем "HelloWorld".

     TypeBuilder helloWorldClass = module.DefineType("MyAssembly.HelloWorld", TypeAttributes.Public);

     // Определение приватной переменной String с именем "theMessage".

     FieldBuilder msgField = helloWorldClass.DefineField("theMessage", Type.GetType("System.String"), FieldAttributes.Private);

     // Создание пользовательского конструктора.

     Type[] constructorArgs = new Type[1];

     constructorArgs[0] = typeof(string);

     ConstructorBuilder constructor = helloWorldClass.DefineConstructor(MethodAttributes.Public, CallingConventions.Standard, constructorArgs);

     ILGenerator constructorIL = constructor.GetILGenerator();

     constructorIL.Emit(OpCodes.Ldarg_0);

     Type objectClass = typeof(object);

     ConstructorInfo superConstructor = objectClass.GetConstructor(new Type[0]);

     constructorIL.Emit(OpCodes.Call, superConstructor);

     constructorIL.Emit(Opcodes.Ldarg_0);

     constructorIL.Emit(Opcodes.Ldarg_1);

     constructorIL.Emit(OpCodes.Stfld, msgField);

     constructorIL.Emit(OpCodes.Ret);

     // Создание конструктора, заданного по умолчанию.

     helloWorldClass.DefineDefaultConstructor(MethodAttributes.Public);

     // Теперь создание метода GetMsg().

     MethodBuilder getMsgMethod = helloWorldClass.DefineMethod("GetMsg", MethodAttributes.Public, typeof(string), null);

     ILGenerator methodIL = getMsgMethod.GetILGenerator();

     methodIL.Emit(OpCodes.Ldarg_0);

     methodIL.Emit(OpCodes.Ldfld, msgField);

     methodIL.Emit(Opcodes.Ret);

     // Создание метода SayHello.

     MethodBuilder sayHiMethod = helloWorldClass.DefineMethod("SayHello", MethodAttributes.Public, null, null);

     methodIL = sayHiMethod.GetILGenerator();

     methodIL.EmitWriteLine("Привет от класса HelloWorld!");

     methodIL.Emit(Opcodes.Ret);

     // Генерирование класса HelloWorld.

     helloWorldClass.CreateType();

     // (Необязательно.) Сохранение компоновочного блока в файл.

     assembly.Save("MyAssembly.dll");

    }

    Генерирование компоновочного блока и набора модулей

    Метод начинается с указания минимального набора характеристик компоновочного блока, для чего используются типы AssemblyName и Version (определенные в пространстве имен System.Reflection). Затем с помощью метода уровня экземпляра AppDomain.DеfineDynamicAssembly() вы получаете тип AssemblyBuilder (напомним, что вызывающая сторона передаст в метод CreateMyAsm() ссылку на AppDomain).

    // Установка общих характеристик компоновочного блока

    // и получение доступа к типу AssemblyBuilder.

    public static void CreateMyAsm(AppDomain currAppDomain) {

     AssemblyName assemblyName = new AssemblyName();

     assemblyName.Name = "MyAssembly";

     assemblyName.Version = new Version("1.0.0.0");

     // Создание нового компоновочного блока в текущем AppDomain.

     AssemblyBuilder assembly = currAppDomain.DefineDynamicAssembly(assemblyName, AssemblyBuilderAccess.Save);

     …

    }

    Как видите, при вызове AppDomain.DefineDynamicAssembly() вы должны указать режим доступа к компоновочному блоку. Этот режим может задаваться любым из значений, указанных в табл. 15.10.

    Таблица 15.10. Значения перечня AssemblyBuilderAccess 

    Значение Описание
    ReflectionOnly Динамический компоновочный блок может только отображаться
    Run Динамический компоновочный блок может выполняться в памяти, но не сохраняться на диск
    RunAndSave Динамический компоновочный блок может выполняться в памяти и сохраниться на диск
    Save Динамический компоновочный блок может сохраняться на диск, но не выполняться в памяти

    Следующей задачей является определение набора модулей для нового компоновочного блока. Поскольку данный компоновочный блок является одномодульным, вы должны определить только один модуль. Если с помощью метода DefineDynamicModule() требуется построить многомодульный компоновочный блок, вы должны указать необязательный второй параметр, задающий имя данного модуля (например, myMod.dotnetmodule). Однако при создании одномодульного компоновочного блока имя модуля будет идентично имени самого компоновочного блока. Так или иначе, после завершения работы метода DefineDynamicModule() вы получите ссылку на действительный тип ModuleBuilder.

    // Одномодульный компоновочный блок.

    ModuleBuilder module = assembly .DefineDynamicModule("MyAssembly", "MyAssembly.dll");

    Роль типа ModuleBuilder

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

    Таблица 15.11. Подборка членов типа ModuleBuilder

    Метод Описание
    DefineEnum() Используется для генерирования определения перечня .NET
    DefineResource() Определяет управляемый встроенный ресурс, который должен храниться в данном модуле
    DefineType() Конструирует TypeBuilder, который позволяет определять типы значений, интерфейсы и типы класса (в том числе и делегаты)

    Ключевым членом класса ModuleBuilder, о котором следует знать, является DefineType(). Вдобавок к указанию имени типа (в виде простой строки), вы должны использовать перечень System.Reflection.TypeAttributes, чтобы непосредственно описать формат типа. Основные члены перечня TypeAttributes представлены в табл. 15.12.

    Таблица 15.12. Подборка элементов перечня TypeAttributes 

    Член Описание
    Abstract Указывает абстрактный тип
    Class Указывает тип класса
    Interface Указывает тип интерфейса
    NestedAssembly Указывает, что класс вложен в область видимости компоновочного блока и поэтому доступен только для методов соответствующего компоновочного блока
    NestedFamAndAssem Указывает, что класс вложен в область видимости семейства и компоновочного блока и поэтому доступен только для методов, принадлежащих пересечению соответствующего семейства и компоновочного блока
    NestedFamily Указывает, что класс вложен в область видимости семейства и поэтому доступен только для методов соответствующего типа и его подтипов
    NestedFamORAssem Указывает, что класс вложен в область видимости семейства или компоновочного блока и поэтому доступен только для методов, принадлежащих объединению соответствующего семейства и компоновочного блока
    NestedPrivate Указывает вложенный класс с приватной областью видимости
    NestedPublic Указывает вложенный класс с общедоступной областью видимости
    NotPublic Указывает класс, не являющийся открытым
    Public Указывает открытый класс
    Sealed Указывает изолированный класс, который не может быть расширен
    Serializable Указывает класс, допускающий сериализацию

    Генерирование типа HelloClass и принадлежащей ему строковой переменной

    Теперь вы понимаете роль метода ModuleBuilder.CreateType(), и пришло время выяснить, как сгенерировать открытый тип класса HelloWorld и приватную строковую переменную.

    // Определение открытого класса MyAssembly.HelloWorld.

    TypeBuilder helloWorldClass = module.DefineType("MyAssembly.HelloWorld", TypeAttributes.Public);

    // Определение принадлежащей классу приватной переменной String

    // с именем theMessage.

    FieldBuilder msgField =hellоWоrldclass.DefineField("theMessage", typeof(string), FieldAttributes.Private);

    Обратите внимание на то, что метод TypeBuilder.DefineField() обеспечивает доступ к типу FieldBuilder. Класс TypeBuilder определяет также другие методы, обеспечивающие доступ к другим типам "построителя". Например, DefineConstructor() возвращает ConstructorBuilder.DefineProperty() – PropertyBuilder и т.д.

    Генерирование конструкторов

    Как уже упоминалось выше, для определения конструктора типа может использоваться метод TypeBuilder.DefineConstructor(). Однако в нашей реализации конструктора HelloClass, чтобы назначить поступающий параметр внутренней приватной строке, мы добавим CIL-код в тело конструктора непосредственно. Чтобы получить тип ILGenerator, вызывается метод GetILGenerator() соответствующего типа "построителя", на который имеется ссылка (в данном случае это тип ConstructorBuilder).

    Метод Emit() класса ILGenerator отвечает за размещение CIL-кода в реализации члена. Сам метод Emit() часто использует тип класса OpCodes, который с помощью полей, доступных только для чтения, открывает доступ к набору кодов операций CIL. Например, OpCodes.Ret указывает возврат вызова метода, OpCodes.Stfld выполняет присваивание значения члену-переменной, a OpCodes.Call используется для вызова метода (в нашем случае это конструктор базового класса). С учетом сказанного рассмотрите следующую программную логику конструктора.

    // Создание пользовательского конструктора, имеющего

    // один аргумент System.String.

    Type[] constructorArgs = new Type[1];

    constructorArgs[0] = typeof(string);

    ConstructorBuilder constructor = helloWorldClass.DefineConstructor(MethodAttributes.Public, CallingConventions.Standard, constructorArgs);

    // Теперь в конструктор добавляется необходимый CIL-код.

    ILGenerator constructorIL = constructor.GеtILGenerator();

    constructorIL.Emit(OpCodes.Ldarg_0);

    Type objectClass = typeof(object);

    ConstructorInfo superConstructor = objectClass.GetConstructor(new Type[0]);

    constructorIL.Emit(OpCodes.Call, superConstructor); // Вызов конструктора базового класса.

    // Загрузка указателя 'this' объекта в стек.

    constructorIL.Emit(OpCodes.Ldarg_0);

    // Загрузка входного аргументе в стек и сохранения в msgField.

    constructorIL.Emit(Opcodes.Ldarg_1);

    constructorIL.Emit(Opcodes.Stfld, msgField); // Присвоение msgField.

    constructorIL.Emit(Opcodes.Ret); // Возврат.

    Вы, конечно, хорошо знаете, что как только для типа определяется пользовательский конструктор, конструктор, заданный по умолчанию, автоматически "отключается". Чтобы переопределить конструктор, не имеющий аргументов, просто вызовите метод DefineDefaultConstructor() типа TypeBuilder, как показано ниже.

    // Восстановление конструктора, заданного по умолчанию.

    helloWorldClass.DefineDefaultConstructor(MethodAttributes.Public);

    Следующий вызов порождает стандартный CIL-код для определения конструктора, заданного по умолчанию.

    .method public hidebysig specialname rtspecialname instance void .ctor() cil managed {

     .maxstack 1

     ldarg.0

     call instance void [mscorlib]System.Object::.ctor()

     ret

    }

    Генерирование метода HelloWorld()

    Наконец, рассмотрим задачу генерирования метода SayHello(). Первой задачей здесь оказывается получение типа MethodBuilder из переменной helloWorld-Class. После этого определяется указанный метод и получается ILGenerator, позволяющий добавить соответствующие CIL-инструкции.

    // Создание метода SayHello.

    MethodBuilder sayHiMethod = helloWorldClass.DefineMethod("SayHello", MethodAttributes.Public, null, null);

    methodIL = sayHiMethod.GetILGenerator();

    // Вывод на консоль.

    methodIL.EmitWriteLine("Всем привет!");

    methodIL.Emit(Opcodes.Ret);

    Здесь создается открытый метод (MethodAttributes.Public), не имеющий параметров и не возвращающий ничего (на это указывают значения null в вызове DefineMethod()). Также обратите внимание на вызов EmitWriteLine(). Этот вспомогательный член класса ILGenerator автоматически записывает строку в стандартный поток вывода.

    Использование динамически сгенерированного компоновочного блока

    Теперь, когда имеется вся программная логика, позволяющая создать и сохранить компоновочный блок, нужен класс для запуска этой логики. Для того чтобы замкнуть цикл, предположим, что в проекте определен второй класс, названный AsmReader. С помощью метода Thread.GetDomain() в Main() получается доступ к текущему домену приложения, который используется для принятия динамически создаваемого компоновочного блока. Получив соответствующую ссылку, вы можете вызвать метод CreateMyAsm().

    Чтобы сделать процесс немного более интересным, после завершения вызова CreateMyAsm() будет выполнено динамическое связывание (см. главу 12), обеспечивающее загрузку нового компоновочного блока в память и взаимодействие с членами класса HelloWorld.

    using System;

    using System.Reflection.Emit;

    using System.Reflection;

    using System.Threading;

    public class Program {

     static void Main(string[] args) {

      Console.WriteLine("********* Чудесный построитель **********");

      Console.WriteLine ("*** динамических компоновочных блоков ***");

      // Получение домена приложения для данного потока.

      AppDomain currAppDomain = Thread.GetDomain();

      // Создание динамического компоновочного блока с помощью f(х).

      СreateMyAsm(currAppDomain);

      Console.WriteLine("-› Завершение создания MyAssembly.dll.");

      // Теперь загрузка нового компоновочного блока из файла.

      Console.WriteLine("-› Загрузка MyAssembly.dll из файла.");

      Assembly a = Assembly.Load("MyAssembly");

      // Получение типа HellоWorld.

      Type hello = a.GetType("MyAssembly.HelloWorld");

      // Создание объекта HelloWorld и вызов нужного конструктора.

      Console.Write("-› Введите сообщение для класса HelloWorld: ");

      string msg = Console.ReadLine();

      object[] ctorArgs = new object[1];

      ctorArgs[0] = msg;

      object obj = Activator.CreateInstance(hello, ctorArgs);

      // Вызов SayHello и вывод возвращенной строки.

      Console.WriteLine("-› Вызов SayHello()");

      Console.WriteLine(" через динамическое связывание.");

      MethodInfo mi = hello.GetMethod("SayHello");

      mi.Invoke(obj, null);

      // Подключение GetMsg(). Метод Invoke() возвращает объект,

      // содержащий возвращенное значение метода.

      mi = hello.GetMethod("GetMsg");

      Console.WriteLine(mi.Invoke(obj, null));

     }

    }

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

    На этом наш обзор CIL и роли динамических компоновочных блоков завершается. Я надеюсь, эта глава позволила расширить горизонты вашего понимания системы типов .NET, а также синтаксиса и семантики CIL.

    Замечание. Обязательно загрузите свой динамически созданный компоновочный блок в ildasm.exe, чтобы выяснить, как функциональные возможности пространства имен System. Reflection.Emit реализуются в программном коде CIL

    Исходный код. Проект DynAsmBuilder размещен в подкаталоге, соответствующем главе 15.

    Несколько слов о System.CodeDOM


    Теперь, когда мы с вами выяснили, как создаются динамические компоновочные блоки с помощью System.Reflection.Emit и различных лексем CIL, я должен сообщить вам, что есть и другая (часто более простая) альтернатива. Платформа .NET предлагает технологию под названием модель DOM для программного кода (модель code DOM), которая позволяет представить структуру .NET-типа в независимых от языка терминах с помощью объектного графа. Построив такой граф с помощью членов пространства имен System.CodeDOM, вы получаете возможность динамически перевести его содержимое в файл программного кода, соответствующего любому языку (C#, Visual Basic .NET или любому языку стороннего поставщика, обеспечившего поддержку code DOM). Кроме того, пространство имен System.CodeDOM.Compiler и связанные с ним другие пространства имен могут использоваться для компиляции объектного графа, находящегося в памяти (или сохраненного) объекта в действительный статический компоновочный блок .NET.

    К сожалению, в этой книге нет места для подробного обсуждения технологии code DOM. Поэтому если вам нужна дополнительная информация, выполните поиск по ключу "CodeDOM, quick reference" в документации .NET Framework 2.0 SDK.

    Резюме

    В этой главе предлагается краткий обзор возможностей синтаксиса и семантики CIL. В отличие от управляемых языков высшего уровня, таких как, например, C#, в CIL не просто определяется набор ключевых слов, но и директивы (для определения структуры компоновочного блока и его типов), атрибуты (уточняющие характеристики соответствующей директивы) и коды операций (используемые для реализации членов типов). Был также рассмотрен компилятор CIL (ilasm.exe). Вы узнали о том, как изменить содержимое компоновочного блока .NET, непосредственно изменяя его программный код CIL, и рассмотрели основные этапы, процесса построения компоновочного блока .NET с помощью CIL.

    Вторая половина главы была посвящена обсуждению пространства имен System.Reflection.Emit. Используя соответствующие типы, вы можете создавать компоновочные блоки .NET в памяти динамически. При желании можно также сохранить созданный в памяти образ в физическом файле на диске. Многие типы System.Reflection.Emit автоматически генерируют подходящие директивы и атрибуты CIL, используя другие связанные с ними типы, такие как ConstructorBuilder, TypeBuilder и т.д. Тип ILGenerator может использоваться для добавления необходимых кодов операций CIL в члены типа. И хотя существует целый ряд вспомогательных типов, призванных упростить процесс создания программ при использовании кодов операций CIL, для успешного создания динамических компоновочных блоков вам понадобится хорошее понимание языка CIL.


    Примечания:



    1

    Символы кириллицы в пользовательских строках программа ildasm.exe просто игнорирует и в окне метаданных не отображает. – Примеч. ред.



    2

    Сообщение гласит: "Чтобы выполнить это приложение, установите одну из следующих версий .NET Framework: v1.0.3705. Обратитесь к разработчику приложения для получения инструкций по поводу установки нужной версии .NET Framework."









    Главная | Контакты | Нашёл ошибку | Прислать материал | Добавить в избранное

    Все материалы представлены для ознакомления и принадлежат их авторам.