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

ВниМание
При.загрузке.сборки.CLR.использует.политики.и.конфигурацию.целевого.домена.
(в.частности,.у.домена.приложений.может.быть.другой.каталог.AppBase.или.инфор-
мация.о.перенаправлении.версий) .Эти.различия.в.политиках.могут.помешать.CLR.
в.поиске.сборки .Если.сборку.загрузить.не.удается,.возникает.исключение,.а.целевой.
домен.приложений.не.получает.ссылку.на.объект 

---

623
Домены.приложений
На этом этапе объекты в исходном и целевом доменах существуют независимо 
друг от друга, поэтому их состояния также могут меняться независимо. Если в ис-
ходном домене нет корней, предохраняющих исходный объект от уничтожения 
уборщиком мусора (как в созданном мною приложении), его память будет осво-
бождена при следующей уборке.
Чтобы убедиться, что объект, возвращенный методом 
MethodWithReturn
, не 
является ссылкой на объект-представитель, мое приложение вызывает откры-
тый статический метод 
IsTrasparentProxy
типа 
System.Runtime.Remoting.
RemotingService
, передавая ему в качестве параметра ссылку, возвращенную 
методом 
MethodWithReturn
. Как видно из результатов работы программы, метод 
IsTrasparentProxy
возвращает значение 
false
, означающее, что объект является 
реальным объектом, не представителем.
Итак, моя программа использует реальный объект для вызова метода 
ToString
. 
Так как переменная 
mbvt
ссылается на реальный объект, вызывается реальная 
реализация этого метода и никаких переходов между доменами приложений не 
происходит. Это легко проверить, проанализировав информацию в окне 
Call
Stack
отладчика: строка 
[AppDomain
Transition]
там не появится.
Чтобы более убедительно доказать, что это не представитель, мое приложение 
выгружает новый домен, после чего пытается снова вызвать метод 
ToString
. В от-
личие от примера 1 на сей раз запрос успешно выполняется, потому что выгрузка 
нового домена никак не влияет на объекты, расположенные в основном домене, 
в том числе на объект, продвинутый по значению.