2008-10-03 16 views
5

Tenemos un SmartClient integrado en C# que permanece abierto cuando se reinicia el PC en funcionamiento. Esto detiene el proceso de reinicio a menos que el usuario cierre primero el SmartClient o haya alguna otra intervención manual.C# .NET exe no se cierra cuando se reinicia la PC, impidiendo que la máquina se reinicie

Esto causa problemas cuando el equipo de infraestructura instala de forma remota un nuevo software que requiere un reinicio de la máquina.

¿Alguna idea para hacer que la aplicación SmartClient reconozca el evento de apagado/reinicio desde Windows y se mata?

ACTUALIZACIÓN: Esta es una aplicación muy roscada con múltiples hilos de gui. sí, múltiples hilos de gui. Es realmente una consolidación de muchos proyectos que en sí mismos podrían ser aplicaciones independientes, todas las cuales se inician y administran desde un único ejecutable que centraliza esos métodos de administración y hace un seguimiento de esos hilos. No creo que usar hilos de fondo sea una opción.

+0

¿Está ejecutando material en subprocesos que no son de fondo? – Will

+0

¿Tiene acceso al código fuente de la aplicación SmartClient? –

Respuesta

5

bien, si tiene acceso a la aplicación, se puede controlar el evento SessionEnded.

... 
Microsoft.Win32.SystemEvents.SessionEnded +=new 
    Microsoft.Win32.SessionEndedEventHandler(shutdownHandler); 

... 

private void shutdownHandler(object sender, Microsoft.Win32.SessionEndedEventArgs e) { 
    // Do stuff 
} 
+1

Solo una nota: probablemente desee el evento SessionEndING, no el SessionEnded (si necesita abortar hilos y cerrar formularios, etc.). – Sire

+0

+1 para aprender algo nuevo. – Ikaso

0

Normalmente, una aplicación .Net respondería correctamente, al menos, ese es el comportamiento "de fábrica". Si no es así, podría haber una serie de cosas sucediendo. Lo mejor que puedo hacer sin saber nada más acerca de su programa es que tiene un proceso de larga ejecución en el hilo principal de la interfaz de usuario que impide que la aplicación responda a los mensajes de la ventana.

+0

Procesos que no son de larga ejecución pero que tienen Threading como Catalin mencionado anteriormente. Aún así, eso no responde realmente a la pregunta: realmente estoy buscando una forma de detectar cuándo se reiniciará la máquina. – ScottCher

1

¿O tal vez la aplicación .Net ignora los mensajes de cierre o de abandono a propósito?

+0

esto es un comentario imo – Konstantinos

5

Debe seguir un subproceso para evitar que se cierre la aplicación. Si está utilizando el enhebrado, una solución fácil sería establecerlo en segundo plano.

Un subproceso es un subproceso o un subproceso en primer plano. Los subprocesos de fondo son idénticos a los subprocesos de primer plano, excepto que los subprocesos de fondo no impiden que un proceso finalice. Una vez que todos los hilos de primer plano que pertenecen a un proceso han terminado, el tiempo de ejecución de lenguaje común finaliza el proceso. Los hilos de fondo restantes se detienen y no se completan.

http://msdn.microsoft.com/en-us/library/system.threading.thread.isbackground.aspx

+0

De hecho, esta es una aplicación de subprocesos. Ver la actualización a la publicación original. Sin embargo, teniendo en cuenta lo que estamos haciendo con los hilos, ¿sigue siendo viable crearlos? Es decir, múltiples hilos de GUI. – ScottCher

1

hilos de fondo era una solución rápida y sucia, mejor solución es el uso de objetos de sincronización (ManualResetEvent, Mutex o algo más) para detener a los otros hilos;

O bien haga un seguimiento de todas sus ventanas abiertas y envíe el mensaje WM_CLOSE cuando se cierre la aplicación principal.

Tiene que dar más información acerca de cómo iniciar esas aplicaciones GUI. tal vez inicie un hilo por cada aplicación y llame al Application.Run(new Form1());?

También puede buscar en la creación de un AppDomain para cada aplicación GUI

5

Cuando un usuario inicia la sesión fuera o Windows se está cerrando, WM_QUERYENDSESSION mensaje se envía a todas las ventanas de nivel superior.Ver MSDN documentation here.

El comportamiento predeterminado de una aplicación WinForm en respuesta a este mensaje es para lanzar el evento FormClosing con CloseReason == WindowsShutDown u otros. Sin embargo, el controlador de eventos puede elegir ser terco y rechazar cerrar la aplicación, manteniendo así el sistema en funcionamiento.

Compruebe FormClosing manejadores de sus aplicaciones. Tal vez hay algo allí. He visto este tipo de cosas un par de veces.

Cuestiones relacionadas