Solución alternativa. El dominio de aplicación .net solo pasa objetos por valor

Question

Estoy desarrollando una aplicación .net que depende mucho de los complementos. La aplicación en sí contiene una conexión a un servidor remoto.

Recientemente busqué en dominios de aplicación y los veo como la solución ideal para aislar el código del complemento del resto de la aplicación.

Sin embargo, hay una gran desventaja que me impide implementar los dominios de aplicación para alojar los complementos. Parece que no hay forma de pasar un objeto por referencia a otro dominio de aplicación que se necesita para pasar una referencia al objeto de conexión.

Esperaba que alguien me pudiera dar una solución para poder pasar una referencia a ese objeto.

Nota: Crear un proxy está fuera de discusión, la capa de conexión ya actúa como un proxy ya que las clases se generan automáticamente.

Nota2: System.AddIn no se puede usar ya que no está disponible en el marco compacto.

Answer 1

¿Has intentado derivar de MarshalByRefObject ? Es un dolor porque arruina tu jerarquía de herencia, pero creo que es lo que quieres.

De los documentos:

  

MarshalByRefObject es la clase base   para objetos que se comunican   límites de dominio de aplicación por   intercambiando mensajes usando un proxy.   Objetos que no heredan de   MarshalByRefObject están implícitamente   Mariscal por valor. Cuando un control remoto   aplicación hace referencia a un mariscal por   objeto de valor, una copia del objeto es   pasado a través del dominio de la aplicación   límites.

     

Los objetos MarshalByRefObject son   accedido directamente dentro de la   límites de la aplicación local   dominio. La primera vez que una aplicación   en un dominio de aplicación remota   accede a un MarshalByRefObject, un proxy   se pasa a la aplicación remota.   Las llamadas posteriores en el proxy son   dirigido de nuevo al objeto que reside   en el dominio de la aplicación local.

     

Los tipos deben heredar de   MarshalByRefObject cuando el tipo es   utilizado en el dominio de la aplicación   límites y el estado de la   el objeto no debe copiarse porque el   los miembros del objeto no son utilizables   fuera del dominio de la aplicación donde   fueron creados.

En mi experiencia, puede ser bastante limitante: realmente necesita hacer lo menos posible a través del límite de AppDomain, preferiblemente restringiéndose a operaciones que solo requieren tipos, cadenas y matrices primitivas de ambos. Esto puede deberse a mi propia inexperiencia en trabajar con múltiples AppDomains, pero es solo una advertencia de que es un poco un campo minado.

Answer 2

Para hablar con la misma instancia entre AppDomains, debe heredar de MarshalByRefObject . Hecho de esta manera, cada llamada de método al objeto (incluidas las propiedades, etc.) es en realidad una llamada remota al otro dominio de la aplicación. ¿Eso ayuda?

Answer 3

Tenga en cuenta que la limpieza de los proxies MarshalByRefObject se limpia en función de un contrato de arrendamiento. En resumen, si no utiliza el objeto durante un tiempo específico, será reclamado. Puede controlar esto anulando InitializeLifetimeService para devolver un objeto de arrendamiento que coincida con sus necesidades. Si devuelve null , deshabilita efectivamente el arrendamiento y luego el objeto solo se recupera cuando se descarga el AppDomain.