private bool LoadExternalModule(string path) {
bool foundSnapIn = false;
IAppFunctionality itfAppFx;
// Динамическая загрузка выбранного компоновочного блока.
Assembly theSnapInAsm = Assembly.LоadFrom(path);
// Получение всех типов компоновочного блока.
Tуре[] theTypes = theSnapInAsm.GetTypes();
// Поиск типа с реализацией IAppFunctionality.
for (int i = 0; i ‹ theTypes.Length; i++) {
Type t = theTypes[i].GetInterface("IAppFunctionality");
if (t != null) {
foundSnapIn = true;
// Динамическое связывание для создания типа.
object о = theSnapInAsm.CreateInstance(theTypes[i].FullName);
// Вызов DoIt() через интерфейс.
itfAppFx = о as IAppFunctionality;
itfAppFx.DoIt();
lstLoadedSnapIns.Items.Add(theTypes[i].FullName);
}
}
return foundSnapIn;
}
Теперь вы можете выполнить свое приложение. При выборе компоновочных блоков CSharpSnapIn.dll и VbNetSnapIn.dll вы должны увидеть соответствующее сообщение. На рис. 12.13 показан один из возможных вариантов выполнения.
Рис. 12.13. Подключение внешних компоновочных блоков
Завершающей задачей будет отображение метаданных, соответствующих атрибуту [CompanyInfo]. Для этого просто обновите LoadExternalModule(), чтобы перед выходом из контекста if вызывалась новая вспомогательная функция DisplayCompanyData(). Эта функция имеет один параметр типа System.Type.
private bool LoadExternalModule(string path) {
…
if (t != null) {
…
// Отображение информации о компании.
DisplayCompanyData(theTypes[i]);
}
return foundSnapIn;
}
Для поступающего на вход типа просто отобразите атрибут [CompanyInfo].
private void DisplayCompanyData(Type t) {
// Получение данных [CompanyInfo].
object[] customAtts = t.GetCustomAttributes(false);
// Вывод данных.
foreach (CompanyInfoAttribute с in customAtts) {
MessageBox.Show(с.Url, String.Format("Дополнительные сведения о {0} ищите по адресу", с.Name));
}
}
Превосходно! На этом рассмотрение примера завершается. Я надеюсь, что к этому моменту нашего обсуждения вы осознаете, что подходы, представленные в этой главе, могут найти применение и на практике, а не только при разработке средств построения программ.
Исходный код. Программный код приложений CommonSnappableTypes, CSharpSnapIn, VbNetSnapIn и MyExtendableApp размещен в подкаталоге, соответствующем главе 12.
Резюме
Сервис отображения оказывается весьма интересным аспектом построения надежного окружения при использовании объектно-ориентированного подхода. В среде .NET ключевыми элементами сервиса отображения являются тип System.Туре и пространство имен System.Reflection. Отображение представляет собой процесс выяснения основных характеристик и возможностей типа в среде выполнения.
Динамическое связывание предполагает создание типа и вызов его членов при отсутствий априорной информации о конкретных именах соответствующих членов. Как показывает пример создаваемого в этой главе расширяемого приложения, это очень мощная техника, которая может использоваться как создателями инструментов разработки приложений, так и пользователями этик инструментов, В главе была также рассмотрена роль программирования с помощью атрибутов. При добавлении атрибутов в определения типов добавляется соответствующая информация в метаданные компоновочного блока.
ГЛАВА 13. Процессы, домены приложений, контексты и хосты CLR
В предыдущих двух главах мы рассмотрели шаги, которые предпринимаются в среде CLR при выяснении параметров размещения внешних компоновочных блоков, а также роль метаданных .NET. В этой главе мы рассмотрим подробности того, как CLR обрабатывает компоновочный блок, и попытаемся понять взаимосвязь между процессами, доменами приложений и контекстами объектов.
В сущности, домены приложений (или АррDотаin) представляют собой логические подразделы в рамках данного процесса, содержащие наборы связанных компоновочных блоков .NET. Вы увидите, что домены приложений разделяются контекстными границами, которые используются для группировки подобных .NET-объектов. С использованием понятия контекста среда CLR подучает возможность гарантировать, что объекты с особыми требованиями к среде выполнения будут обрабатываться надлежащим образом.
Обладая пониманием того, как среда CLR обрабатывает компоновочный блок, мы с вами сможем выяснить, что такое хостинг CLR. Как уже говорилось в главе 1, сама среда CLR представляется (по крайней мере, отчасти) файлом mscoree.dll. При запуске выполняемого компоновочного блока файл mscoree.dll загружается автоматически, но, как вы сможете убедиться, в фоновом режиме при этом выполняется целый ряд шагов, скрытых от глаз пользователя.
Выполнение традиционных процессов Win32
Понятие "процесс" существовало в операционных системах Windows задолго до появления платформы .NET. Упрощенно говоря, термин процесс используется для обозначения множества ресурсов (таких, как внешние библиотеки программного кода и первичный поток) и выделяемой памяти, необходимых для работы приложения. Для каждого загруженного в память файла *.ехe операционная система создает отдельный и изолированный процесс, используемый в течение всего "жизненного цикла" соответствующего приложения. В результате такой изоляции приложений повышается надежность и устойчивость среды выполнения, поскольку отказ в ней одного процесса не влияет на функционирование другого.
Каждому процессу Win32 назначается уникальный идентификатор PID (Process ID – идентификатор процесса), и процесс, при необходимости, может независимо загружаться или выгружаться операционной системой (или программными средствами с помощью вызовов Win32 API). Вы, возможно, знаете, что на вкладке Процессы в окне Диспетчер задан Windows (которое можно активизировать нажатием комбинации клавиш ‹Ctrl+Shift+Esc>) можно увидеть информацию о процессах, выполняющихся на машине, включая информацию PID и имя образа (рис. 13.1).
Замечание. Если столбец PID в окне Диспетчер задач Windows не отображается, выберите в этом окне команду Вид→Выбрать столбцы… из меню и в открывшемся после этого окне установите флажок Идентификатор процесса (PID).
Рис. 13.1. Диспетчер задач Windows
Обзор потоков
Каждый процесс Win32 имеет один главный "поток", выполняющий функции точки входа в приложение. В следующей главе будет выяснено, как создавать дополнительные потоки и соответствующий программный код, применяя возможности пространства имен System.Threading, но пока что для освещения вопросов, представленных здесь, нам нужно выполнить определенную вспомогательную работу. Во-первых, заметим, что поток – это "нить" выполнения в рамках данного процесса. Первый поток, созданный точкой входа процесса, называется первичным потоком. Приложения Win32 с графическим интерфейсом пользователя определяют в качестве точки входа приложения метод WinMain(). Консольные приложения для этой цели используют метод Main(). Процессы, состоящие из одного первичного потока, будут потокоустойчивыми, поскольку в них в каждый момент времени только один поток может получить доступ к данным приложения. Однако одно-поточный процесс (особенно если он основан на графическом интерфейсе) часто бывает "склонен" не отвечать пользователю при выполнении потоком достаточно сложных действий (например, связанных с печатью большого текстового файла, запутанными вычислениями или попытками соединиться с удаленным сервером).
Учитывая эти потенциальные недостатки однопоточных приложений, Win32 API позволяет первичным потокам порождать дополнительные вторичные потоки (также называемые рабочими потоками), используя, например, такую удобную функцию Win32 API, как CreateThread(). Каждый поток (первичный или вторичный) в таком процессе становится уникальным элементом выполнения и получает доступ ко всем открытым элементам данных на условиях конкуренции.
Вы можете сами догадаться, что разработчики создают дополнительные потоки, как правило, для того, чтобы программа могла быстрее реагировать на. действия пользователя. Многопоточные процессы обеспечивают иллюзию того, что все действия выполняются приблизительно за одно и то же время. Например, приложение может порождать рабочий поток для выполнения действий, требующих много времени (снова вспомним о печати большого файла). Как только созданный вторичный поток начинает свою работу, главный поток снова получает возможность отвечать на пользовательский ввод, что позволяет процессу в целом потенциально обеспечить лучшую производительность. Хотя в реальности этого может и не произойти: использование слишком большого числа потоков в рамках одного процесса может ухудшить производительность, поскольку процессору придется часто переключаться между активными потоками (а это требует немало времени).
