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

Выгрузка доменов
Одна из замечательных особенностей CLR — возможность выгрузки доменов 
приложений. При этом выгружаются и все загруженные в них сборки, а также 
освобождается куча загрузчика доменов. Провести эту процедуру легко: доста-
точно вызвать статический метод 
Unload
класса 
AppDomain
(как показано в моем 
приложении в начале главы). Это заставляет CLR выполнить набор операций по 
корректной выгрузке указанного домена.
1. CLR приостанавливает все потоки в процессе, которые когда-либо выполняли 
управляемый код.
2. CLR проверяет все стеки на наличие потоков, которые в текущий момент вы-
полняют код выгружаемого домена или могут рано или поздно вернуться к вы-
полнению такого кода. CLR вынуждает все потоки, в стеке которых находится 
выгружаемый домен, сгенерировать исключение 
ThreadAbortException
(при 
этом выполнение потока возобновляется). В результате потоки переходят 
к выполнению блоков 
finally
, то есть корректно завершают свою работу. При 
отсутствии кода, перехватывающего исключение 
ThreadAbortException
, оно 
переходит в разряд необработанных и «проглатывается» CLR; поток заверша-
ется, но процессу разрешается продолжить работу. Такое поведение отличается 
от стандартного, потому что в любых других ситуациях при возникновении 
необработанного исключения CLR уничтожает процесс.
1
Кстати, именно поэтому класс System.String является запечатанным. Если бы это было не 
так, вы могли бы определять собственные классы, производные от String, и добавлять к ним 
собственные поля. В результате среда CLR не смогла бы гарантировать неизменность строк.

---

625
Выгрузка.доменов
ВниМание
CLR.не.уничтожит.немедленно.поток,.который.выполняет.код.блока.finally.или.catch,.
конструктора.класса,.критической.области.или.неуправляемый.код .Уничтожение.
таких.потоков.сделало.бы.невозможным.выполнение.кода.очистки,.восстановления.
после.ошибок,.инициализации.типа,.критического.кода.или.любого.кода,.который.
CLR.не.знает.как.обрабатывать .Это.стало.бы.причиной.непредсказуемого.поведения.
приложений.и.появлению.дыр.в.системе.безопасности .Уничтожаемому.потоку.раз-
решается.закончить.выполнение.таких.блоков,.и.только.после.этого.CLR.вынуждает.
его.сгенерировать.исключение.ThreadAbortException 
3. После выгрузки из домена всех потоков, обнаруженных на втором шаге, CLR 
проходит по куче и устанавливает флаг для каждого объекта-представителя, 
который ссылается на объект, созданный в выгружаемом домене. Так объекты-
представители «узнают», что реальный объект, на который они ссылаются, 
уничтожен. В результате при попытке вызвать метод «неправильного» объекта-
представителя появляется исключение 
AppDomainUnloadedException
.
4. CLR инициирует принудительную уборку мусора, чтобы освободить память, 
занятую объектами выгружаемого домена. Вызываются методы финализации 
для этих объектов, давая им шанс выполнить нужную очистку.
5. CLR возобновляет работу всех оставшихся потоков. Поток, вызвавший метод 
AppDomain.Unload
, продолжает работу; вызовы 
AppDomain.Unload
выполняются 
синхронно.
В моем приложении всю работу выполняет один поток. Всякий раз, когда 
код приложения вызывает метод 
AppDomain.Unload
, в выгружаемом домене не 
оказывается потоков, поэтому CLR не приходится генерировать исключение 
ThreadAbortException
(о нем мы поговорим чуть позже).
Кстати, при вызове потоком метода 
AppDomain.Unload
CLR ждет 10 секунд, 
чтобы потоки выгружаемого домена могли его покинуть. Если после этого поток, 
вызвавший метод 
AppDomain.Unload
, не возвращает управление, он генерирует 
исключение 
CannotUnloadAppDomainException
, и домен может быть (а может и не 
быть) выгруженным в будущем.