Liberación de "propiedad" del objeto COM en .NET

Question

Tengo un cliente/socio que intenta vincular su aplicación con la nuestra utilizando nuestra funcionalidad COM expuesta. Hasta el momento, tienen un objeto COM que representa una instancia de nuestro paquete de software y luego usan nuestros métodos COM para crear algo programáticamente para el usuario en función de lo que han hecho en su aplicación. Es esencialmente una característica de "exportación".

Lo que me han pedido que haga, lo que no sé cómo hacer es permitir que el usuario decida cuándo se cierra la instancia. Lo que quiero decir con esto es cuando nuestro paquete de software está cargado, es visible y el usuario lo interactúa. Cuando hayan terminado, naturalmente harán clic en la cruz en la parte superior derecha para salir del software. Esto no funciona ya que el objeto COM aún está "activo" en su aplicación. Nuestro paquete de software solo se puede cerrar matando el proceso en el administrador de tareas mientras la aplicación que lo cargó a través de COM permanece abierta. Una vez que su aplicación finalice, la nuestra se cerrará automáticamente. Parece como si su aplicación "posee" la nuestra debido a la llamada COM.

He hecho una aplicación de demostración rápida en C# para tratar de usar cosas como Marshal.FinalReleaseComObject(myObject) en vano.

Me doy cuenta de que usar COM para este tipo de cosas no es para lo que está destinado, pero espero que haya algún tipo de solución alternativa? El cliente/socio está usando VB.NET, pero C# está bien.

Answer 1

Ha omitido alguna información crítica acerca de su propia aplicación, incluido lo más importante, cómo está implementando las interfaces COM que expone a la aplicación cliente. Un aspecto de su descripción que es una señal de alerta para mí es la creación de instancias de su aplicación. Usted dice que la aplicación cliente es "usar VB para comenzar un nuevo proceso al hacer referencia a nuestro exe". Esto no debería ser necesario si ha implementado y registrado correctamente su servidor COM. Déjame que te cuente la arquitectura que usaría para lograr lo que preguntas, y espero que esto te sea útil.

Para empezar, si desea proporcionar un objeto COM desde un proceso separado, la forma correcta es implementar un COM fuera del servidor de procesos. Con un servidor fuera de proceso, COM iniciará su aplicación automáticamente cuando un cliente solicite una de sus interfaces a través de COM. Parte de los requisitos de implementación de un servidor fuera de proceso es cerrar automáticamente cuando el último cliente COM libera su último puntero de interfaz.

Para exponer una interfaz de usuario del servidor fuera de proceso, querrá engendrar un subproceso independiente de un único subproceso (STA) con un bucle de mensaje. Esto le permitirá cerrar cualquier ventana en el hilo STA, incluida la ventana principal, sin matar su servidor COM. Esto se debe a que la implementación del servidor COM ejecutará su propio subproceso de ciclo de mensajes de Múltiples subprocesos (MTA) para admitir el COM de las llamadas de proc. El subproceso MTA es el subproceso principal de la aplicación, y el servidor lo cerrará cuando se lance la última interfaz de cliente.

Un servidor COM no debe cerrarse mientras las interfaces permanecen inéditas. Esto significa que la aplicación cliente tiene la responsabilidad de liberar las interfaces correctamente. Pero su marco de prueba .NET debería haber hecho esto, por lo que parece que algo no está bien con su implementación.

Suponiendo que sigue estas instrucciones, necesitará un plan para manejar el escenario en el que se libera la última interfaz del cliente, pero todavía tiene ventanas de IU abiertas. Una vez que haya configurado todo correctamente, este no debería ser un problema importante. Por ejemplo, simplemente puede tomar una referencia a una de sus propias interfaces mientras la interfaz de usuario está abierta, esto evitaría el cierre de MTA.