Funziona evento Application.ApplicationExit da notificare di uscita non Winforms app?

Question

La nostra biblioteca codice deve essere notificato quando l'applicazione è uscita. Così abbiamo sottoscritto l'evento System.Window.Forms.Application.ApplicationExit. Questo funziona bene per le applicazioni WinForms, ma funziona anche per altri tipi di applicazioni come applicazioni console, servizi e applicazioni web (come ad esempio ASP.NET)? Lo spazio dei nomi suggerirebbe che non è così, ed è presumibilmente viene sollevata quando viene chiamato Application.Exit() (esplicitamente o implicitamente pone), che non può essere corretto chiamare per questi altri casi.

C'è qualche altro evento che sarebbe meglio in questi altri casi, o che sarebbe più universale (grande se funziona per WinForms, troppo)? Ad esempio, c'è un evento per quando Environment.Exit() si chiama (console app)?

Ho trovato una menzione di un evento uscito al System.Diagnostic.Process, ma questo sembra essere per monitorare l'uscita di altro di processo, e non sembra essere ricevuti da un processo su stesso (ad esempio, Process.GetCurrentProcess().Exited += Process_Exited; Process.GetCurrentProcess().EnableRaisingEvents = true;). Vorrei pensare che potrebbe essere sollevato solo dopo che il processo è in realtà uscito, in modo che non avrebbe funzionato.

Questo è particolarmente for .NET 2.0 e C #.

Answer 1

Abbiamo finalmente trovato più su questo (ma da allora la mia macchina era stata ricostruita e perso i biscotti al mio profilo non registrati qui; si spera, vi permetterà posta incontrato questa risposta).

Ulteriori indagini alla fine ha trovato un paio di eventi che abbiamo trovato utili:

System.Windows.Forms.Application.ThreadExit - Viene eseguito quando un ciclo di messaggi uscite System.Windows.Forms.Application.ApplicationExit - Incendi quando tutto loop di messaggi di uscita System.AppDomain.CurrentDomain.DomainUnload - Viene eseguito quando un dominio diverso le uscite di default System.AppDomain.CurrentDomain.ProcessExit - Viene eseguito quando le uscite di dominio predefiniti app System.AppDomain.CurrentDomain.UnhandledException -. Gli incendi quando si verifica un'eccezione non rilevata, che termina l'applicazione

Solo uno degli eventi DomainUnload o ProcessExit sono possibili per un dato dominio applicazione, a seconda se si è l'impostazione predefinita (di primo livello) di dominio per il processo o è stato creato come un sottodominio (ad es. Su un server web). Se un'applicazione non sa quale potrebbe essere (come nel nostro caso), ha bisogno di iscriversi a entrambi se si vuole catturare lo scarico reale per sé. Inoltre, sembra che UnhandledException (che al .NET2.0 è sempre fatale) può impedire gli altri due eventi, in modo che può essere un terzo caso da gestire. Questi tre eventi dovrebbero funzionare per qualsiasi applicazione .NET.

V'è un avvertimento che il tempo di esecuzione per ProcessExit è delimitata (circa 4 secondi?), Quindi potrebbe non essere possibile fare un ampio lavoro "finale" in questo gestore di eventi. Ha bisogno di essere qualcosa che può essere fatto in fretta.

Gli eventi Application valgono solo per le applicazioni WinForms (abbiamo il sospetto che non si possono verificare nelle applicazioni WPF pure, però). La denominazione può essere fuorviante, perché sono chiamati per la loro maggior uso normale di base che ha alcune ipotesi. ThreadExit non riguarda il System.Threading.Thread effettivo, ma piuttosto al ciclo di messaggi (Application.Run())) di un thread UI, e ApplicationExit analogamente si riferisce alla raccolta di moduli applicativi su uno o più fili UI. Normalmente, una volta che la chiamata a Application.Run() rendimenti, chiamati dal metodo di inserimento di un filo, il metodo di inserimento si conclude velocemente e il filo si finisce poi. E una volta che tutte le discussioni UI sono usciti, un'applicazione WinForms di solito è tutto fatto ed esce.

Un altro evento di nota è l'evento System.Windows.Forms.Application.ThreadException. Un ciclo di messaggi di Windows può essere configurato per rilevare le eccezioni che si verificano nella gestione di un messaggio e invia questo evento, piuttosto che servano da non gestite fanno (e quindi fatali) eccezioni. Facendo queste eccezioni consente il ciclo di messaggi (e che thread UI) per continuare la corsa (dopo aver interrotto il gestore di messaggi corrente). Ci può essere un solo abbonato a questo evento in qualsiasi momento, per un dato filo (abbonamenti sovrascrivono ogni abbonato precedente), e deve essere configurato prima di creare qualsiasi forma e sottoscritto prima di entrare nel ciclo di messaggi. Vedere l'aiuto MSDN per questo evento e System.Windows.Forms.Applicaton.SetUnhandledExceptionMode() per maggiori informazioni.