【发布时间】：2016-03-22 14:21:35
【问题描述】：
目前我正在Startup.Auth.cs 中启动一个长时间运行的线程
这是应用程序启动时 ASP.NET 应用程序调用 ConfigureAuth 的位置。目前我在这里启动我的线程，内容如下：
try {
LaunchListenThread();
}
catch (ThreadAbortException e) {
Console.WriteLine("Thread - caught ThreadAbortException - resetting.");
Console.WriteLine("Exception message: {0}", e.Message);
Thread.ResetAbort();
LaunchListenThread();
}
函数LaunchListenThread()本质上只是启动Startup.Auth.cs中声明的线程
线程被声明为
private readonly ThreadStart nThread = new ThreadStart(NetComms.StartListening);
我主要关心的是捕获ThreadAbortException，例如，如果我输入StartListening，它似乎不会被前面提到的Catch 块捕获。
我想知道的是在 IIS 中启动像这样的长期运行线程的更标准或可接受的方式，特别是我能够捕获 ThreadAbortException
到目前为止，我已经通过以下方式进行了测试：
System.Threading.Thread.CurrentThread.Abort();
catch(ThreadAbortException te) {
throw te;
}
错误被抛出，但此后丢失。
如果有任何其他信息会有所帮助，请告诉我。
【问题讨论】：
-
由于 appdomains 可以（并且将会）被回收，我养成了不在 ASP.Net 中运行长时间运行的进程的习惯。我通常通过 WCF 调用一个外部独立服务来完成这项工作。
-
我已经很好地配置了 IIS，不回收我的线程，并且我允许线程闲置几天到几周，它仍然保持活动状态。我现在主要关心的似乎是流氓 ThreadAbortExceptions。我不确定这是否真的发生过，我更担心无法正确捕捉。
-
我还是不推荐它；前任由于多个应用程序域、网络农场问题等，您最终可能会使用多个线程。ASP.NET 根本不是为了做这样的事情而设计的。无论如何，如果您不相信，这些异常通常是
Request.End()之类的结果以及 ASP.Net 处理请求的方式之一。无论哪种方式，ThreadAbortException都可以中止。例如te.ResetAbort()。这种行为的后果当然是你的...... -
好的，感谢您的回复。我可能应该注意到，这是一个严格的非互联网 Intranet 应用程序，它只能处理很少的用户，并且应用程序的运行方式几乎没有变化。
标签： c# asp.net multithreading iis