Для борьбы с нечисткой за собой ресурсов одной .dll hешил попробовать исполнять ее в ином домене.

Из .dll наружу смотрит 1 объект-враппер мной написанный со свойствами Init(), Run(), Close(). Внутри объекта прочие объекты (в том числе несериализуемые) и сложная логика.

При AppDomain.CreateInstanceFromAndUnwrap() была ругань про отсутствие [Serialize] у моего объекта.

Вопрос: Что именно должно сериализоваться у моего враппера для нормальной работы ?

Я предполагаю, что сериализуемости самого враппера (но не его private-членов) достаточно для создания прокси и нормальной работы ?

Здравствуйте, Nikolay_P_I, Вы писали:

N_P>Для борьбы с нечисткой за собой ресурсов одной .dll hешил попробовать исполнять ее в ином домене.

N_P>Из .dll наружу смотрит 1 объект-враппер мной написанный со свойствами Init(), Run(), Close(). Внутри объекта прочие объекты (в том числе несериализуемые) и сложная логика.

N_P>При AppDomain.CreateInstanceFromAndUnwrap() была ругань про отсутствие [Serialize] у моего объекта.

N_P>Вопрос: Что именно должно сериализоваться у моего враппера для нормальной работы ?

N_P>Я предполагаю, что сериализуемости самого враппера (но не его private-членов) достаточно для создания прокси и нормальной работы ?


если вы сделаете враппер сериализуемым, то после вызова CreateInstanceFromAndUnwrap() получите в основном домене его точную копию, вызовы методов которой никак не скажутся на обьекте в другом домене . В вашем случае, ИМХО, враппер должен быть пронаследован от MarshalByRefObject. В этом случае в результате CreateInstanceFromAndUnwrap() в основном домене будет создан прокси для доступа к удаленному обьекту

Здравствуйте, Nikolay_P_I, Вы писали:

N_P>Для борьбы с нечисткой за собой ресурсов одной .dll hешил попробовать исполнять ее в ином домене.

Домены это чисто управляемая конструкция. Поэтому изоляция обеспечивается исключительно для управляемого кода. Чистке ресурсов домен не поможет.