Александр Юдаков, когда базовый домен не подходит(будь то безопасность, удобность и прочее) , приходится создавать свой домен и загружать туда все библиотеки для работы.
Моя задача была в том что-бы передать хотя-бы ссылку на объект спешскрина из центрального домена (где сплеш создается) в дочерний домен (где уничтожается).
Много бился, в итоге забил и рефлексией выдирал hHANDLE окна сплешскрина (учитывая что сплешскрин легковесное окно, следовательно при создании объекта идет инициализация через базовый WinAPI, следовательно в объекте должен быть hHANDLE окна для обработчика) и передавал его через SetData
После чего в дочернем домене, убивал окно с помощью базовых функций winAPI.
Это только одна из легкий задач.
А так, есть множество задач на ту же отказоустойчивость приложения.
В буквальном смысле - никак. Managed объект существует только внутри одного AppDomain. Объект использует, в частности, кучу, GC и другие сервисы того домена, которому принадлежит.
По поводу частного случая со сплэшскрином - соглашусь, что лучше hHANDLE не придумаешь. Т.е. мы имеем один процесс ОС с двумя AppDomain внутри, соответственно можем свободно передавать хэндлы ресурсов ОС между этими AppDomain.
Во всех остальных случаях, когда нам хотелось-бы имитировать передачу управляемого объекта в другой домен, придется использовать сериализацию в том или ином виде:
1) можно имитировать передачу самого объекта, т.е. сериализовать / десериализовать его данные (поля, либо свойства) - технологии можно использовать разные, суть одна: мы передаем данные;
2) можно проксировать вызов метода объекта, тогда мы сериализуем фактические параметры вызова, передаем их в целевой домен, там их десериализуем, выполняем метод, возвращаемое значение (или исключение) сериализуем и передаем обратно, в завершение в вызывающем домене десериализуем ответ. Одну из технологий предложили выше (.Net Remoting). Сами Microsoft рекомендуют вместо этого сейчас использовать WCF, но суть та-же: мы передаем не объекты, а вызовы методов (фактические параметры вызова - в одну сторону; результат вызова, либо исключение - в обратную сторону).
Взаимодействие как по первой схеме, так и по второй мне приходилось реализовывать в распределенных приложениях (где домены располагаются на разных компах). Каждый раз, почему-то, оказалось проще и эффективнее использовать свой простой способ сериализации/десериализации (xml, либо json) вместо красивых, модных и громоздких .Net Remoting, WCF и др. В этом случае проще адаптировать механизм под имеющиеся условия.
Поэтому, еще раз - без использования сериализации - никак. Managed объект существует только внутри одного AppDomain.
