2010-10-11 6 views
8

Tengo problemas con una biblioteca mal hecha que arroja una excepción en un finalizador, que por supuesto bloquea la aplicación.¿Puedo evitar que una excepción no detectada en otro AppDomain cierre la aplicación?

Para evitar esto, he intentado cargar la biblioteca en su propio dominio de aplicación, pero sigue siendo la excepción burbujas a la superficie y se bloquea la aplicación.

tal como se documenta en MSDN, registrando a AppDomain.UnhandledException no impide la excepción de burbujeo, pero estoy bastante sorprendido de que no hay otra manera de capturar una excepción como en un "dominio de aplicación sub".

¿Cómo anfitriones de plugins o aplicaciones que utilizan dominios de aplicación al recinto de seguridad potencialmente dañinas de código, hacer para detener las excepciones no controladas? ¿Es de hecho posible?

Nota: Ya tengo otra solución, la que se describe here. El finalizador incorrecto está en un objeto de larga duración, que parece que solo se recopila durante el apagado, por lo que es suficiente para ocultar este error "falso" del usuario. Aún así, encuentro que esta solución es frágil, ya que ocultará otros errores reales o arriesgará la voladura de mi aplicación si el objeto se recopila anteriormente.

+0

Por qué no se puede capturar la excepción – rerun

+0

La excepción se produce en un Finalizador, que se ejecuta en su propio hilo gestionado por el CLR, por lo que no puedo poner un controlador de excepción en el hilo. Además, esta es una biblioteca de la "herencia, y unmaintaiend componente importante sin código fuente disponible" tipo ... –

Respuesta

4

Un dominio de aplicación es muy bueno, ya que puede abandonar el estado del programa, pero todavía tiene el problema de que el hilo está muerto. Que esto suceda en el hilo del finalizador es fatal, el CLR abortará el proceso sin recurso.

La única 'solución' es ejecutar este componente en su propio proceso. Puede dispararlo en la cabeza con Process.Kill() para evitar que el hilo del finalizador se ejecute en la salida del proceso. Utilice uno de los mecanismos de comunicación entre procesos compatibles con .NET para hablar con él. Un socket, named pipe, Remoting o WCF. Suerte con ello.

+0

Gracias por la respuesta, pensé que había un mejor aislamiento entre dominios de aplicación, mala suerte. Creo que nos quedaremos con la solución actual por ahora, y aislaremos la biblioteca en su propio proceso en la próxima versión. –

0

En realidad, ya en .NET 1.0/1.1, se comportó como sea necesario. Todavía se puede volver a este comportamiento, simplemente añadiendo esta línea a su archivo de configuración de la aplicación, dentro del nodo "tiempo de ejecución":

<runtime> 
    <legacyUnhandledExceptionPolicy enabled="1"/> 
</runtime> 

Esto evitará que una excepción no controlada en un hilo diferente de terminar todo el proceso.

+2

Conozco esta opción, pero eso escondería excepciones de cada hilo, que definitivamente no es lo que quiero. –

Cuestiones relacionadas