|
Глава 22.
хостинг CLR и домены
приложений
В этой главе обсуждаются две темы, позволяющие по-настоящему оценить до-
стоинства Microsoft .NET Framework, —
хостинг
(hosting) и
домены приложений
(AppDomains). Благодаря хостингу любое приложение может использовать возмож-
ности общеязыковой среды CLR, в частности существующие приложения можно,
по крайней мере, частично, переписать при помощи управляемого кода. Кроме того,
хостинг позволяет настраивать и дополнять приложения на программном уровне.
Поддержка дополнений означает возможность включения в свои программы кода
сторонних разработчиков. В Microsoft Windows загрузка чужих DLL-библиотек
была исключительно рискованным мероприятием. В такой библиотеке очень легко
мог оказаться код, разрушающий структуры данных, и код приложений. Кроме
того, библиотека могла использовать контекст безопасности приложений для
получения доступа к ресурсам, к которым в обычных условиях доступа у нее нет.
Домены приложений позволили решить эти проблемы. Именно они дают возмож-
ность запускать не пользующийся доверием код сторонних разработчиков, а CLR
гарантирует безопасность и целостность структур данных и кода, а также невоз-
можность использовать в неблаговидных целях контекст безопасности.
Обычно хостинг и домены приложений используют наряду с загрузкой сборок
и отражением. Совместное применение этих четырех технологий превращает CLR
в невероятно богатую и мощную платформу. Эта глава посвящена в основном хо-
стингу и доменам приложений, а о загрузке сборок и отражении рассказывается
в следующей главе. Изучив и освоив эти технологии, вы узнаете, почему усилия,
затраченные на освоение .NET Framework, с лихвой окупятся в будущем.
хостинг CLR
Платформа .NET Framework работает поверх Microsoft Windows. Это значит, что
в ее основе должны лежать технологии, с которыми Windows может взаимодей-
ствовать. Для начала все файлы управляемых модулей и сборок должны иметь
формат PE (portable executable), являться исполняемыми файлами Windows (EXE)
или динамически подключаемыми библиотеками (DLL).
В Microsoft разработали CLR в виде COM-сервера, содержащегося в DLL. То
есть разработчики определили для CLR стандартный COM-интерфейс и присвоили
этому интерфейсу и COM-серверу глобально уникальные идентификаторы (GUID).
607
Хостинг.CLR
При установке .NET Framework COM-сервер, представляющий CLR, регистрирует-
ся в реестре Windows как любой другой COM-сервер. Подробнее см. заголовочный
файл C++
MetaHost h
из .NET Framework SDK — в этом файле определены все
GUID-идентификаторы и неуправляемый интерфейс
ICLRMetaHost
.
Любое Windows-приложение может стать хостом (управляющим приложением)
для CLR. Однако не следует создавать экземпляры COM-сервера CLR функцией
CoCreateInstance
; вместо этого неуправляемый хост должен вызывать функцию
CLRCreateInstance
, объявленную в файле
MetaHost h
. Эта функция реализована
в библиотеке
MSCorEE dll
, которая обычно расположена в каталоге
C:\Windows\
System32
. Обычно эту библиотеку называют
оболочкой совместимости
(shim) — она не
содержит COM-сервер CLR, а только определяет, какую версию CLR следует создать.
На одной машине допускается установка нескольких версий CLR, но может
быть только одна версия файла
MSCorEE dll
(оболочка совместимости)
1
. Версия
библиотеки
MSCorEE dll
совпадает с версией самой последней установленной сре-
ды CLR, поэтому эта версия
MSCorEE dll
«знает», как найти любые более ранние
версии CLR, которые устанавливались на машине.
Код CLR содержится в файле, имя которого зависит от версии. Для версий
1.0, 1.1 и 2.0 это файл
MSCorWks dll
, а для версии 4.0 — файл
Clr dll
. Так как на один
компьютер можно установить несколько версий CLR, эти файлы располагаются
в разных папках
2
:
версия 1.0 — в папке
C:\Windows\Microsoft NET\Framework\v1 0 3705
;
версия 1.1 — в папке
C:\Windows\Microsoft NET\Framework\v1 0 4322
;
версия 2.0 — в папке
C:\Windows\Microsoft NET\Framework\v2 0 50727
;
версия 4.0 — в папке
C:\Windows\Microsoft NET\Framework\v4 0 21006
.
Функция
CLRCreateInstance
возвращает интерфейс
ICLRMetaHost
. Хост-
приложение может вызывать функцию
GetRuntime
этого интерфейса, указывая
ту версию CLR, которую следует создать. После этого оболочка совместимости
загружает эту версию в текущий процесс.
По умолчанию оболочка совместимости анализирует управляемый исполняемый
файл и извлекает из него сведения о версии CLR, с которой было построено и про-
тестировано приложение. Однако приложение может переопределить заданные
по умолчанию сведения, записав элементы
requiredRuntime
и
supportedRuntime
в конфигурационный XML-файл (см. главы 2 и 3).
1
В 64-разрядной версии Windows в действительности установлены два варианта файла
MSCorEE.dll. Первый — это 32-разрядная версия x86, расположенная в папке C:\Windows\
SysWOW64, второй — 64-разрядная версия x64 или IA64 (в зависимости от архитектуры
процессора), расположенная в папке C:\Windows\System32.
2
Обратите внимание, что версии .NET Framework 3.0 и 3.5 поставляются с CLR 2.0. Я не
указываю, в каких папках находятся версии .NET Framework 3.0 и 3.5, так как DLL-библиотека
CLR загружается из папки v2.0.50727.
608
Do'stlaringiz bilan baham: |
