如何检测如果当前的应用程序池在IIS7.5和Asp.Net清盘3.5+ [英] How to detect if the current application pool is winding up in IIS7.5 and Asp.Net 3.5+
问题描述
好 - 正是因为这个问题受到美国 - ？你会如何做任何想法
Well - exactly as the question subject states - any ideas on how you might do this?
我看过了在System.Web.Hosting的对象，但没有什么突出。
I've been looking over the objects in System.Web.Hosting but nothing is standing out.
原因是什么？我收到这是一个循环过程中通常存在的一个或两个应用程序错误（他们碰巧相隔约25小时，我已经离开我的应用程序池回收时间默认值），所以我想知道，如果他们发生在线程这是在池中的关停，或者一个的开始（ED / ING）了。
The reason? I'm getting one or two application errors which are typically occuring during a recycle (they happen about 25 hours apart and I've left my app pool recycle time at the default) and so I want to know if they're happening on a thread that's in the pool that's shutting down, or the one that's start(ed/ing) up.
推荐答案
我最近偶然发现的这篇文章Brain.Save（）这一现象从托管WCF的角度谈论正是这个问题（他是史蒂夫缅因州 - 微软在对关联33.060.99部项目经理）。
I recently stumbled across this article on Brain.Save() which talks about exactly this issue from the point of view of hosting WCF (he's Steve Maine - A program manager at Redmond on the Connected Servies Division).
他们需要的是能够做到这一点，当一个WCF服务里面Asp.Net托管，因为它们需要能够来关闭所有打开的监听器，这样在新的应用领域的WCF引擎将能够打开他们都起来试。
They need to be able to do this when a WCF service is hosted inside Asp.Net since they need to be able to shutdown any open listeners so that the WCF engine in the new app domain will be able to open them all up again.
正如文章表明，答案是实施的 IRegisteredObject接口，通话 ApplicationManager.CreateObject 来创建对象的实例，然后用 HostingEnvironment.RegisterObject （MSDN文档界面中的所有详细说明）。
As the article demonstrates, the answer is to implement the IRegisteredObject interface, call ApplicationManager.CreateObject to create an instance of your object and then register it with HostingEnvironment.RegisterObject (all detailed in the MSDN documentation for the interface).
在此对象的 IRegisteredObject.Stop（布尔）实现被称为与假作为参数，这是通知该应用程序域正在与呼叫关闭，而且对象应该被注销（有点像一个全球性的处置），以 HostingEnvironment.UnregisterObject 。
When this object's IRegisteredObject.Stop(bool) implementation is called with false as the parameter, this is notification that the app domain is being shut down and that the object should be unregistered (kind of like a global dispose) with a call to HostingEnvironment.UnregisterObject.
当它被称为与真正这意味着你已经没有及时登记，而如果你不立即注销，它会为你做。
When it's called with true it means you've not unregistered in good time, and that if you don't Unregister immediately, it'll be done for you.
我当然可以使用这种机制来发现，发生异常时，如果在AppDomain中被杀害或没有。问题抛出异常的对象的性质意味着，如果它不是在关机时，它必须是初始启动过程中。
I can certainly use this mechanism to find out, when an exception occurs, if the AppDomain is being killed or not. The nature of the object in question that throws the exception means that if it's not at shutdown, it must be during initial startup.
然而，同样，我可能开始寻找这个持久性机制的一些我的其他更复杂的静态信息！
Equally, however, I may well start looking at this persistence mechanism for some of my other more complicated static information!
文章还解释了一些历史和基本原理，你为什么会想使用 IRegisteredObject ，而不是的Application_Start 和 Application_End 的方法的Global.asax ：
The article also explains some of the history, and rationale, of why you would want to use IRegisteredObject rather than Application_Start and Application_End methods in global.asax:
传统的ASP.NET应用程序可以连接应用程序生命周期事件（应用程序启动/关机）通过实施在Global.asax中一样的Application_Start和Application_Stop方法。然而，Global.asax的是应用程序code。基础件（其中WCF托管系统就是其中之一）需要挂钩不涉及在Global.asax文件倾销基础设施code AppDomain的生命周期事件的机制。这空间保留给你，用户，这将是粗鲁使用污染与一群托管咕我们需要使整个事情的工作。相反，ASP.NET乡亲Whidbey的发布过程中做了一些伟大的工作，以开拓托管的API，让人们更容易喜欢WCF一起去钩的方式，是不可见的应用程序code这些生命周期事件。
Traditional ASP.NET applications can hook application lifecycle events (application startup/shutdown) by implementing methods like Application_Start and Application_Stop in global.asax. However, global.asax is for application code. Infrastructure pieces (of which the WCF hosting system is one) need a mechanism of hooking AppDomain lifecycle events that do not involve dumping infrastructure code in your global.asax file. That space is reserved for you, the user, and it would be rude of use to pollute that with a bunch of hosting goo we need to make the whole thing work. Instead, the ASP.NET folks did some great work during the Whidbey release to open up the hosting API’s and make it easy for people like WCF to come along and hook these lifecycle events in a way that’s invisible to application code.
这篇关于如何检测如果当前的应用程序池在IIS7.5和Asp.Net清盘3.5+的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
