Application.ApplicationExit 事件是否可以在非 Winforms 应用程序中通知退出？

Question

我们的代码库需要在应用程序退出时得到通知。所以我们订阅了 System.Window.Forms.Application.ApplicationExit 事件。这适用于 Winforms 应用程序，但它是否也适用于其他类型的应用程序，例如控制台应用程序、服务和 Web 应用程序（例如 ASP.NET）？命名空间会表明它没有，并且它可能会在调用 Application.Exit() 时（显式或隐式）被引发，这对于这些其他情况可能不正确。

是否有其他事件在这些其他情况下会更好或更普遍（如果它也适用于 Winforms，那就太好了）？例如，调用Environment.Exit() 时是否有事件（控制台应用程序）？

我在 System.Diagnostic.Process 中发现了一个 Exited 事件的提及，但这似乎是为了监视 另一个 进程的退出，并且似乎没有被进程接收到本身（例如，Process.GetCurrentProcess().Exited += Process_Exited; Process.GetCurrentProcess().EnableRaisingEvents = true;）。我认为它可能只有在进程实际退出后才会被提出，所以这是行不通的。

这尤其适用于 .NET 2.0 和 C#。

Answer 1

我们终于找到了更多关于此的信息（但到那时我的机器已经重建并且在此处丢失了我未注册个人资料的 cookie；希望它会让我们发布这个答案）。

进一步调查最终发现了一些我们认为有帮助的事件：

System.Windows.Forms.Application.ThreadExit - 当消息循环退出时触发 System.Windows.Forms.Application.ApplicationExit - 当所有消息循环退出时触发 System.AppDomain.CurrentDomain.DomainUnload - 当非默认域退出时触发 System.AppDomain.CurrentDomain.ProcessExit - 默认应用程序域退出时触发 System.AppDomain.CurrentDomain.UnhandledException - 发生未捕获的异常时触发，结束应用程序。

对于给定的应用程序域，只有一个 DomainUnload 或 ProcessExit 事件是可能的，这取决于它是进程的默认（顶级）域还是被创建为子域（例如，在网络服务器）。如果一个应用程序不知道它可能是哪一个（如我们的例子），它需要订阅两者，如果它想自己捕获实际的卸载。此外，似乎UnhandledException（从 .NET2.0 开始总是致命的）可能会阻止其他两个事件，因此这可能是第三种需要处理的情况。这三个事件应该适用于任何 .NET 应用程序。

需要注意的是，ProcessExit 的执行时间是有限的（大约 4 秒？），因此可能无法在该事件处理程序中进行大量的“最终”工作。它必须是可以快速完成的事情。

Application 事件仅适用于 WinForms 应用程序（但我们怀疑它们可能不适用于纯 WPF 应用程序）。命名可能会产生误导，因为它们是根据具有某些假设的最基本的正常用法命名的。 ThreadExit 与实际的 System.Threading.Thread 无关，而是与 UI 线程的消息循环 (Application.Run())) 相关，ApplicationExit 与一个或多个 UI 线程上的应用程序表单的集合类似。通常，一旦调用Application.Run()返回，从线程的入口方法调用，入口方法很快结束，然后线程本身结束。一旦所有 UI 线程都退出，WinForms 应用程序通常会全部完成并退出。

另一个值得注意的事件是System.Windows.Forms.Application.ThreadException 事件。 Windows 消息循环可以配置为捕获处理消息时发生的异常并发送此事件，而不是让它们成为未捕获（因此是致命的）异常。捕获这些异常允许消息循环（和那个 UI 线程）继续运行（在中止当前消息处理程序之后）。对于给定的线程，在任何时候都只能有一个订阅者（订阅会覆盖任何以前的订阅者），并且必须在创建和订阅任何表单之前配置它，然后再进入消息循环。请参阅此事件的 MSDN 帮助和System.Windows.Forms.Applicaton.SetUnhandledExceptionMode() 了解更多信息。