Events Application.ApplicationExit事件在非Winforms应用程序中发出退出通知时有效吗？

当应用程序退出时，需要通知我们的代码库。因此，我们已订阅System.Window.Forms.Application.ApplicationExit事件。这对Winforms应用程序很有效，但对其他类型的应用程序（如控制台应用程序、服务和web应用程序（如ASP.NET））也有效吗？名称空间将表明它没有，并且它可能在调用

Application.Exit（）

时（显式或隐式）被引发，这对于其他情况来说可能不正确

是否有其他事件在这些其他情况下更好，或者更通用（如果它也适用于Winforms，那就太好了）？例如，当调用

Environment.Exit（）

时（控制台应用程序），是否存在事件

我在System.Diagnostic.Process中发现一个已退出的事件，但这似乎是为了监视另一个进程的退出，并且它似乎没有被进程本身接收到（例如，

Process.GetCurrentProcess（）.Exited+=Process\u Exited；Process.GetCurrentProcess（）.EnableRaisingEvents=true；

）。我认为它可能只有在进程实际退出后才会被提出，所以这是行不通的

---

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

我们终于找到了更多关于这一点的信息（但那时我的机器已经重建，cookies丢失到了我未注册的配置文件中；希望它能让met发布这个答案）

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

System.Windows.Forms.Application.ThreadExit

-在消息循环退出时激发

System.Windows.Forms.Application.ApplicationExit

-在所有消息循环退出时激发

System.AppDomain.CurrentDomain.DomainUnload

-当默认域以外的域退出时激发

System.AppDomain.CurrentDomain.ProcessExit

-在默认应用程序域退出时激发

System.AppDomain.CurrentDomain.UnhandledException

在发生未捕获的异常时激发，结束应用程序

给定的应用程序域只能有一个

DomainUnload

或

ProcessExit

事件，这取决于它是进程的默认（顶级）域还是创建为子域（例如在web服务器上）。如果应用程序不知道它可能是哪一个（在我们的例子中），那么如果它想要捕获自己的实际卸载，它需要同时订阅这两个。此外，似乎

未处理异常

（从.NET2.0开始一直是致命的）可能会阻止其他两个事件，因此这可能是需要处理的第三种情况。这三个事件应该适用于任何.NET应用程序

需要注意的是，

ProcessExit

的执行时间是有限制的（大约4秒？），因此可能无法在该事件处理程序中执行大量的“最终”工作。这需要一些能够迅速完成的事情

应用程序

事件仅适用于WinForms应用程序（但我们怀疑它们可能不适用于纯WPF应用程序）。命名可能会产生误导，因为它们是根据其最基本的正常用法命名的，而这些用法有一定的假设

ThreadExit

与实际的

System.Threading.Thread

不相关，而是与UI线程的消息循环（

Application.Run（）

）相关，而

ApplicationExit

类似地与一个或多个UI线程上的应用程序表单集合相关。通常，一旦从线程的entry方法调用

Application.Run（）

返回调用，entry方法将快速结束，然后线程本身结束。一旦所有UI线程都退出，WinForms应用程序通常都完成并退出

另一个值得注意的事件是

System.Windows.Forms.Application.ThreadException

事件。可以将Windows消息循环配置为捕获在处理消息时发生的异常并发送此事件，而不是让它们成为未捕获的（因此是致命的）异常。捕获这些异常允许消息循环（以及该UI线程）继续运行（在中止当前消息处理程序之后）。给定线程在任何时候只能有一个此事件的订阅服务器（订阅覆盖任何以前的订阅服务器），并且必须在创建和订阅任何表单之前对其进行配置，然后才能进入消息循环。有关此事件的详细信息，请参阅MSDN帮助和

System.Windows.Forms.Applicaton.SetUnhandledExceptionMode（）