Эндрю Троелсен - ЯЗЫК ПРОГРАММИРОВАНИЯ С# 2005 И ПЛАТФОРМА .NET 2.0. 3-е издание

public static void anotherAD_DomainUnload(object sender, EventArgs e) {

Console.WriteLine("***** Выгрузка anotherAD! *****\n");

}

Если вы хотите получить извещение при выгрузке домена приложения, созданного по умолчанию, измените метод Main() так, чтобы обработать событие ProcessEvent, соответствующее домену приложения по умолчанию:

static void Main(string [] args) {

…

AppDomain defaultAD = AppDomain.CurrentDomain;

defaultAD. ProcessExit+=new EventHandler(defaultAD_ProcessExit);

}

и определите подходящий обработчик событий.

private static void defaultAD_ProcessExit (object sender, EventArgs e) {

Console.WriteLine("***** Выгрузка defaultAD! *****\n");

}

Исходный код.Проект AppDomainManipulator размещен в подкаталоге, соответствующем главе 13.

Итак, вы могли убедиться, что домены приложения – это логические разделы в рамках процесса, предназначенные для загрузки компоновочных блоков .NET. Домен приложения, в свою очередь, можно делить дальше на контекстные области со своими границами. В сущности, контекст .NET обеспечивает домену приложения возможность создать "Отдельную комнату" для данного объекта.

Используя контекст, среда CLR может гарантировать, что объекты, которые выдвигают специальные требования в среде выполнении, будут обработаны надлежащим образам и в нужном порядке, поскольку для этого среда использует перехват вызовов, пересекающих границу контекста. Слой перехвата позволяет среде CLR корректировать текущие вызовы методов в соответствии с контекстно-зависимыми установками данного объекта. Например, если вы определите тип класса C#, требующий автоматической поддержки множества потоков (используя атрибут [Synchronization]), то среда CLR при его размещении создаст "синхронизированный контекст".

Точно так же, как процесс определяет создаваемый по умолчанию домен приложения, каждый домен приложения имеет создаваемый по умолчанию контекст. Этот создаваемый по умолчанию контекст (на который иногда ссылаются, как на контекст 0, поскольку он всегда оказывается первым контекстом, создаваемым в домене приложений) применяется для тех объектов .NET, которые не имеют никаких особых или уникальных контекстных требований. Вы вправе ожидать, что подавляющее большинство объектов .NET должно загружаться в контекст 0. Когда среда CLR определяет новый объект, имеющий специальные требования, создаются новые границы контекста в рамках объемлющего домена приложения. На рис. 13.9 показана схема взаимодействия процесса, доменов приложения и контекстов.

Рис. 13.9. Процессы, домены приложения и границы контекста

Типы .NET которые не предъявляют никаких специальных контекстных требований, называются контекстно-независимыми объектами. Эти объекты доступны из любого места в рамках соответствующего домена приложения, без каких бы то ни было особых требований к среде выполнения. Построение контекстно-независимых объектов не требует больших усилий, поскольку ничего специального делать не приходится (в частности, не требуется наделять тип контекстными атрибутами или получать производные базового класса System.ContextBoundObject).

// Контекстно-независимый объект загружается в контекст 0.

public class SportsCar()

С другой стороны, объекты, которые требуют контекстного размещения, называются контекстно-связанными объектами, и они должны быть производными от базового класса System.ContextBoundObject. Этот базовый класс закрепляет тот факт, что соответствующий объект сможет правильно функционировать только в рамках контекста, в котором он был создан. С учетом роли контекста .NET должно быть ясно, что в случае, когда контекстно-связанный объект оказывается в несоответствующем контексте, в любой момент могут возникнуть проблемы.

Вдобавок к необходимости получения типа из System.ContextBoundObject, контекстно-связанный тип будет наделен рядом специальных атрибутов .NET, называемых контекстными атрибутами (что вполне логично). Все контекстные атрибуты получаются из базового класса. System.Runtime.Remoting.Contexts. ContextAttribute:

public class System.Runtime.Remoting.Contexts.ContextAttribute: Attribute, IContextAttribute, IContextProperty {

public ContextAttribute(string name);

public string Name { virtual get; }

public object TypeId { virtual get; }

public virtual bool Equals(object o);

public virtual void Freeze(System.Runtime.Remoting.Contexts.Context newContext);

public virtual int GetHashCode();

public virtual void GetPropertiesForNewContext(System.Runtime.Remoting.Activation.IConstructionCallMessage сtorMsg);

public Type GetType();

public virtual bool IsContextOK(System.Runtime.Remoting.Contexts.Context ctx, System.Runtime.Remoting.Activation.IConstructionCallMessage ctorMsg);

public virtual bool IsDefaultAttribute();

public virtual bool IsNewContextOK(System.Runtime.Remoting.Contexts.Context newCtx);

public virtual bool Match(object obj);

public virtual string ToString();

}

Поскольку класс ContextAttribute не является изолированным, вполне возможно строить свои собственные пользовательские контекстные атрибуты (для этого следует получить класс, производный от ContextAttribute, и переопределить необходимые виртуальные методы). После этого вы сможете создать пользовательский программный код, отвечающий на контекстные установки.

Замечание.В этой книге не рассматриваются подробности создания пользовательских контекстов объектов, но если вы заинтересованы узнать об этом больше, прочитайте книгу Applied .NET Attributes (Apress, 2003).

Чтобы определить класс (SportsCarTS), автоматически поддерживающий потоковую безопасность, без добавления в него сложной логики синхронизации патока при реализации членов, следует взять объект, производный от ContextBoundObject, и применить атрибут [Synchronization], как показано ниже.

using System.Runtime.Remoting.Contexts;

// Этот контекстно-связанный тип будет загружен только

// в синхронизированном (т.е. многопоточном) контексте.

[Synсhronization]

public class SportsCarTS: ContextBoundObject{}

Типы с атрибутом [Synchronization] загружаются в контексте сохранения потоков. С учетом специальных контекстуальных требований типа класса MyThreadSafeObject представьте себе те проблемы, которые должны возникнуть, если размещенный объект перевести из синхронизированного контекста в несинхронизированный. Объект вдруг перестанет быть защищенным в отношении потоков и превратится в потенциального нарушителя целостности данных, поскольку другие потоки могут пытаться взаимодействовать с этим ссылочным объектом (теперь уже не сохраняющим потоки). Для гарантии того, что среда CLR не переместит объекты SportsCarTS за рамки синхронизированного контекста, достаточно взять объект, производный от ContextBoundObject.