Estamos creando una aplicación (WinForms, .NET 3.5) que carga archivos DLL de "plugins" en un dominio de aplicación secundario. El dominio de aplicación secundario debe comunicarse ocasionalmente con el primero (más específicamente, llamar u obtener datos de objetos que se crean en el dominio de aplicación principal).

He leído la mayoría del material sobre AppDomains y la comunicación entre ellos.

Hasta ahora, la única solución fácil que he visto fue heredar de MarshalByRefObject y pasando un TransparentProxy en el segundo dominio de aplicación, llamando a métodos en el Proxy.

Este método tiene sus inconvenientes (no siempre es posible heredar de MBRO en el caso de tipos de marcos, por ejemplo, o tipos que ya heredan de otra clase, campos / clases estáticas, etc.)

ado que los puntos de comunicación actuales son bastante constantes (solo 2-3 escenarios que requieren comunicación), he considerado crear un @ simpMediado clase con las siguientes propiedades:

Se creará en el primer dominio de aplicación (principal). Funcionaría solo como un "mensaje de paso" para los objetos "reales" que se crean en el AppDomain principal. Heredará de MBRO, y se enviará una referencia de proxy al segundo dominio de aplicación.

e llamarían @Methods en este objeto proxy, que a su vez llamará a los métodos en los objetos "reales" en el primer AppDomain.

Mis preguntas -

¿Parece esto un diseño lógico? Más importante aún, ¿ya existe una clase mediadora / mensajera en WCF o en cualquier otro marco de comunicación? parece un concepto genérico y me pregunto si hay algo similar.