c# - Bombas de mensaje y AppDomains

Question

Tengo una aplicación C # (FFx 3.5) que carga archivos DLL como complementos. Estos complementos se cargan en AppDomains por separado (por muchas buenas razones, y esta arquitectura no puede cambiar). Esto está todo bien.

Ahora tengo un requisito para mostrar un cuadro de diálogo de uno de esos complementos. Tenga en cuenta que no puedo devolver el Formulario de diálogo a la aplicación principal y que se muestre allí (la infraestructura actual no lo admite).

Fracaso 1

En mi DLL, creé un Formulario y lo llamé Show. El esquema del diálogo apareció pero no pintó y no responde a los eventos del mouse. Supuse que esto es porque la DLL está en un Dominio de Aplicación separado y la bomba de mensajes para la aplicación de alguna manera no puede enviar mensajes al nuevo Formulario.

Fracaso 2

En mi DLL creé un Formulario y lo llamé ShowDialog, que con todos los derechos debería crear una bomba de mensajes interna para el diálogo. El cuadro de diálogo se muestra y responde a los clics (hurra), pero parece que la aplicación primaria ya no está procesando o despachando mensajes de Windows porque deja de pintar y ya no responde a los eventos del mouse. Por alguna razón, ahora parece que la bomba de mensajes de la aplicación principal no despacha.

Fracaso 3

En mi DLL creé un Formulario y llamé a Application.Run. Esto sin duda creará una bomba de segundo mensaje completa. Obtengo el mismo comportamiento que Failure 2: el diálogo se comporta, pero la aplicación que llama no.

¿Alguna idea de qué es exactamente lo que está sucediendo aquí y cómo podría mostrar un cuadro de diálogo de la DLL del otro dominio de la aplicación y hacer que la persona que llama y la persona que llama sigan respondiendo y pintando correctamente?

Answer 1

Intente utilizar el formulario principal BeginInvoke de appdomain1 con un delegado que muestre el formulario de appdomain2. Entonces en Pseudocódigo:

Appdomain1:
AppDomain2.DoSomething(myMainForm);
AppDomain2:
DoSomething(Form parent)
{
Form foolishForm = new Form();
parent.BeginInvoke(new Action( delegate { foolishForm.Show(); } ));
}

El código puede no ser perfecto, pero demuestra el concepto.

Por cierto, si tiene problemas para pasar formularios debido a la comunicación remota, puede:

public class Container<T> : MarshalByRefObject
{
private T _value;
public T Value { get { return _value; } set { _value = value; } }
public Container() { }
public Container(T value) { Value = value; }
public static implicit operator T(Container<T> container)
{
return container.Value;
}
}

Eso contendrá el objeto que le arrojes.

Answer 2

Tenemos una aplicación muy similarmente diseñada que carga los archivos DLL y los complementos. Cada archivo DLL se carga en un dominio de aplicación separado, que se crea en un hilo separado. Tenemos un control de terceros en un formulario que no aparecería a menos que llamemos a System.Windows.Forms.Application.DoEvents() regularmente.

Pseudo código:

<In new thread>
<Application domain created. Start called inside new application domain.>
<Start loads new DLL file, calls init function in DLL file>
<Start loops, calling DoEvents until the DLL file exits>
<Application domain unloaded>
<Thread exits>

Esto resolvió todos nuestros problemas con la GUI.

Answer 3

Una cosa que he usado antes es implementar un DomainManager . Es posible personalizar las diversas aplicaciones de seguridad / enlace / contexto del dominio de aplicación para manejar problemas complejos o de tipo huevo de gallina con respecto al bombeo de sus datos donde lo desee;)

Por lo general, he hecho esto desde un archivo native.exe, iniciando el CLR a través de las interfaces COM (código psudo pero los nombres de los pedidos y métodos son correctos;):

CorBindToRuntimeEx()
SetHostControl()
GetCLRControl()
SetAppDomainManagerType("yourdomainmanger","info")
// Domain manager set before starting runtime
Start()
HostControl -- GetDomainManagerForDefaultDomain()
DomainManager -- Run()

Su administrador de dominio puede ser cualquier biblioteca CLR , por lo que no es mucho más nativa C.

Una nota al margen, si estuvieras en WPF ; Realmente me gusta usar el método "Microsoft.DwayneNeed.Controls". Donde puede tener hilos separados con su propia bomba Dispatcher en el mismo control UI (sin necesidad de recurrir a Window () completamente nuevo).

Lo único que tiene que ver con el uso de este enfoque es que incluso si el subproceso principal de UI está bloqueado / ocupado (algunas operaciones pesadas, escanear el sistema de archivos, etc.), estos otros subprocesos pueden pintar / actualizar su UIElement sin ningún tipo de problema.