我一直在看System.Web.Hosting中的对象,但没有什么是突出的.
原因？我正在收到一个或两个应用程序错误,这些错误通常在回收期间发生(它们发生在大约25个小时,我已经将我的应用程序池的回收时间设置为默认值),所以我想知道他们是否在线程正在关闭的池中,或正在开始(ed / ing)的池中.
解决方法
当WCF服务托管在Asp.Net中时,他们需要能够执行此操作,因为它们需要能够关闭所有打开的监听器,以便新的应用程序域中的WCF引擎将能够再次打开它们.
正如文章所示,答案是实现IRegisteredObject interface,调用ApplicationManager.CreateObject来创建一个对象的实例,然后将其注册到HostingEnvironment.RegisterObject(在MSDN文档中详细介绍了该接口).
当该对象的IRegisteredObject.Stop(bool)实现被调用为false作为参数时,这是通知应用程序域被关闭,并且该对象应该被注销(类似于全局处理),并调用HostingEnvironment. UnregisterObject.
当它被称为真实的时候,这意味着你没有及时取消注册,如果你不立即注销,那将是为你完成的.
我可以使用这个机制找出当发生异常时,如果AppDomain被杀死了.抛出异常的对象的性质意味着如果它不在关闭状态,则必须在初始启动期间.
然而,同样地,我可能会开始关注这种持久性机制,以便我的一些其他更复杂的静态信息！
历史
本文还解释了为什么要在global.asax中使用IRegisteredObject而不是Application_Start和Application_End方法的一些历史和理由：
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.
