Язык программирования С# 2005 и платформа .NET 2.0.

Приложения .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 (*.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 является чувствительным к регистру символов).

 ‹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

Используя любой из указанных подходов, установите 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›

Следующий вопрос, который мы должны рассмотреть в рамках обсуждения возможностей конфигурации, это роль политики публикации компоновочных блоков. Вы только что убедились, что с помощью файлов *.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›

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

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

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

Чтобы понять, как использовать пространство имен 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

Получение Туре с помощью 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.

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

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

Замечание. Указанный атрибут применяется только к элементу, непосредственно следующему за атрибутом. Например, единственным не сохраняемым полем класса 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. Некоторые атрибуты уровня компоновочного блока

В следующих разделах мы с вами проанализируем пример, иллюстрирующий процесс создания расширяемого приложения 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.

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

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

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

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

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

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

Чтобы привести пример обработки типов 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

Перед тем как двигаться дальше, следует заметить, что тип 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.

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

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

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

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

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

Хотя один процесс и может принять множество доменов приложения, так бывает не всегда. Как минимум, процесс ОС будет содержать то, что обычно называют доменом приложения, созданным по умолчанию. Этот специальный домен приложения автоматически воздается средой CLR во время запуска процесса.

После этого CLR создает дополнительные домены приложения по мере необходимости, Если потребуется (хотя это и маловероятно), вы можете программно создавать домены приложения в среде выполнения в рамках выполняемого процесса, используя статические методы класса System.AppDomain. Этот класс оказывается также полезным для осуществления низкоуровневого контроля доменов приложения. Основные члены этого класса описаны в табл. 13.4.

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

Таблица 13.4. Основные члены класса AppDomain

Таблица 13.5. События типа AppDomain

Список доменов приложения процесса

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

Для конечного пользователя запуск выполняемого блока .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 имеют только один поток и, тем не менее, оказываются очень полезными, первичный поток компоновочного блока (порождаемый средой 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, но с помощью делегатов это делается намного проще.

Если для вас тема многопоточных приложений является новой, вы можете спросить, чем же на самом деле является асинхронный вызов метода. Вы, без сомнения, знаете о том, что для выполнения некоторых программных операций требуется время. Предыдущий метод 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 является класс Thread. Этот класс представляет собой объектный контейнер отдельной ветви выполнения в конкретном домене приложения. Он определяет ряд методов (как статических, так и общедоступных), которые позволяют создавать новые потоки в текущем домене приложения, а также приостанавливать, останавливать и завершать отдельные потоки. Рассмотрите описания основных статических членов, приведенные в табл. 14.2.

Таблица 14.2. Основные статические члены типа Thread

Класс Thread также поддерживает набор членов уровня экземпляра. Описания некоторых из этих членов приведены в табл. 14.3.

Таблица 14.3. Члены уровня экземпляра типа Thread

Получение информации об отдельном потоке

Напомним, что точка входа компоновочного блока (т.е. метод 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

Хотя это может и не казаться очевидным на первый взгляд, процесс атомарного изменения одного значения является вполне типичным в многопоточном окружении. Предположим, что у нас есть метод 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.