Net framework 5, а также среды Visual Studio 2012 и C#

618
Глава.22 .Хостинг.CLR.и.домены.приложений
ПриМеЧание
Существуют.перегруженные.версии.CreateInstanceAndUnwrap,.которые.позволяют.
вызывать.конструктор.типа.с.передачей.аргументов 
Однако все не так радужно, как могло бы показаться. Ведь CLR не позволяет 
переменной (корню), находящейся в одном домене, ссылаться на объект из другого. 
Если бы метод 
CreateInstanceAndUnwrap
просто вернул ссылку на объект, это на-
рушило бы изоляцию, а ведь именно ради нее создавались домены! Поэтому непо-
средственно перед возвращением ссылки на объект метод 
CreateInstanceAndUnwrap
выполняет некоторые дополнительные операции.
Обратите внимание, что тип 
MarshalByRefType
наследует от специального 
базового класса 
System.MarshalByRefObject
. Обнаружив, что метод 
Create-
InstanceAndUnwrap
выполняет продвижение объекта типа, производного от 
Marshal By Ref Object
, CLR выполняет продвижение объекта по ссылке в дру-
гой домен. Поясню, что означает продвижение объекта по ссылке из одного 
домена (в котором объект был создан) в другой (в котором вызывается метод 
CreateInstanceAndUnwrap
).
Когда домену-источнику нужно передать ссылку на объект в целевой домен 
приложений или вернуть ее обратно, CLR определяет в куче загрузчика этого 
домена тип 
представителя
(proxy). Этот тип определяется посредством метадан-
ных исходного типа, представителем которого он является, поэтому выглядит он 
в точности как исходный тип — у него совпадают все экземплярные члены (свой-
ства, события и методы). Экземплярные поля к типу не относятся, но об этом мы 
поговорим чуть позже. В новом типе действительно определяются некоторые 
экземплярные поля, но они не идентичны полям исходного типа данных. Вместо 
этого эти поля указывают, который из доменов «владеет» реальным объектом и как 
найти этот объект в домене-владельце. (Внутренне объект-представитель исполь-
зует экземпляр 
GCHandle
, который ссылается на реальный объект. Тип 
GCHandle
обсуждается в главе 21).
После определения этого типа в целевом домене метод 
CreateInstanceAndUnwrap
создает экземпляр типа представителя, инициализирует его поля таким обра-
зом, чтобы они указывали на домен-источник и реальный объект, и возвращает 
в целевой домен ссылку на объект-представитель. В моем варианте кода на этот 
представитель ссылается переменная 
mbrt
. При этом возвращенный методом 
CreateInstanceAndUnwrap
объект не является экземпляром типа 
MarshalByRefType
. 
Обычно CLR не разрешает приведение к несовместимым типам, однако в этой си-
туации преобразование выполняется, потому что члены экземпляров нового и ис-
ходного типов совпадают. В сущности, если вы используете объект-представитель 
для вызова метода 
GetType
, представитель вводит вас в заблуждение, представляясь 
объектом 
MarshalByRefType
.
Впрочем, при желании можно узнать, что объект, возвращенный методом 
CreateInstanceAndUnwrap
, в реальности является ссылкой на объект-представитель. 

---

619
Домены.приложений
Для этого мы используем открытый статический метод 
IsTransparentProxy
типа 
System.Runtime.Remoting.RemotingService
, которому в качестве параметра 
передается ссылка, возвращенная методом 
CreateInstanceAndUnwrap
. Если метод 
IsTransparentProxy
возвращает значение 
true
, значит, объект является предста-
вителем.
Итак, мое приложение использует представителя для вызова метода 
SomeMethod
. 
Так как переменная 
mbrt
ссылается на объект-представитель, вызывается реализация 
этого метода в представителе. В ней информация из полей объекта-представителя 
используется для направления вызывающего потока из основного домена при-
ложения в новый. Теперь любые действия этого потока выполняются в контексте 
безопасности и конфигурации нового домена. Далее поток использует поле 
GCHandle
объекта-представителя для поиска в новом домене реального объекта, после чего 
вызывает для него метод 
SomeMethod
.
Есть два способа узнать, что запрашивающий поток перешел от основного к ново-
му домену. Во-первых, в методе 
SomeMethod
я вызываю метод 
Thread.GetDomain().
FriendlyName
. В результате возвращается 
AD
#2
(что подтверждается выходными 
данными), так как поток теперь выполняется в новом домене, созданном методом 
AppDomain.CreateDomain
с параметром 
AD
#2
в качестве значимого имени. Во-
вторых, при пошаговом выполнении кода в отладчике с открытым окном 
Call
Stack
строка 
[AppDomain
Transition]
отмечает переход потока через границу между 
доменами (рис. 22.2).