我们在 Asp.Net Web 应用程序中实现了一个“后台服务”，它以随机间隔从 MSMQ 接收消息，而不需要 HTTP 请求来启动应用程序。我们使用 serviceAutoStartProvider。
当 IIS 最初启动、服务器重新启动等时，一切正常，我们收到消息也很好。 但是如果我们只是停止 IIS 中的站点（不接触应用程序或应用程序池），应用程序将停止接收 MSMQ 消息。当我们再次启动网站时，serviceAutoStartProvider 不会再次被调用，因此我们的应用程序不会再次开始侦听 MSMQ 消息！
如果我们在 IIS 站点停止并再次启动后向 Web 应用程序发出 HTTP 请求，它会再次开始侦听 MSMQ 消息。
-
即使 IIS 站点停止，我们的“后台服务”Web 应用程序不应该继续侦听 MSMQ 消息吗？它不会收到任何请求，但我认为它应该继续运行。
-
当 IIS 站点停止时，Asp.Net 应用程序/应用程序池中到底会发生什么？我们可以连接任何触发的事件吗？应用程序池声称已在 IIS 管理器中“启动”，但代码并未在其中运行。
-
为什么当站点再次启动时我们的 serviceAutoStartProvider 没有被调用？我相信这是“设计使然”，因为应用程序并没有真正停止。但应用程序也没有运行，必须由实际的 HTTP 请求唤醒。
We've implemented a "background service" in our Asp.Net web app that receives messages from MSMQ at random intervals without requiring an HTTP request to start up the application. We auto start this web app using a serviceAutoStartProvider.
Everyhing works when IIS initially starts up, the server is rebooted and so on, we receive messages just fine. BUT if we just stop the site in IIS (not touching the application or app pool), the application stops receiving MSMQ messages. And when we start the web site again, the serviceAutoStartProvider is not called again, so our app does not start listening to MSMQ messages again!
If we issue a HTTP request against the web app after the IIS site has been stopped and started again, it starts listening to MSMQ messages again.
-
Shouldn't our "background service" web app continue to listen to MSMQ messages even if the IIS site is stopped? It won't get any requests, but I think it should continue to run.
-
What exactly happens in an Asp.Net application/app pool when the IIS site is stopped? Any events fired that we can hook up to? The app pool claims to be "started" in IIS manager, but code is not running in it.
-
Why isn't our serviceAutoStartProvider called when the site is started again? I believe it is "by design", since the application isn't really stopped. But the applications isn't running, either, has to be waken up by an actual HTTP request.
发布评论
评论（3）
当 IIS Web 应用程序关闭时（例如，由于在超时时间内没有新的 HTTP(S) 请求），.NET 应用程序域（在应用程序池工作进程内）将完全关闭并卸载。这包括所有后台线程，包括 .NET 线程池使用的线程。
Web 应用程序可以配置更长（或没有）的超时，然后后台工作线程可以继续处理工作。
但更好的办法是在完全单独管理的专业服务流程中运行这些工作人员。
或者，更好的是，使用 IIS 应用程序托管和 WCF 来创建 MSMQ 侦听器。据我所知，在这种情况下，如果在关闭后收到新消息，Windows Process Activation Services 与 IIS 的集成将重新启动 Web 应用程序。
When the IIS Web App shuts down (eg. due to no new HTTP(S) requests for the timeout time) the .NET app domain (within the app pool worker process) completely closes and unloads. This includes all background threads, including those used by the .NET thread pool.
A Web App can be configured with a longer (or no) timeout, then background worker threads could continue to process work.
But better would be to either run such workers in a specialist service process managed completely separately.
Or, even better, use IIS application hosting with WCF to create the MSMQ listener. I understand in this case the integration of Windows Process Activation Services with IIS would restart the Web App if a new message arrived after it had been shutdown.
我将在 Windows 服务中托管 MSMQ 侦听器。为什么要把它耦合到 IIS？
更新
实际上我的意思是为什么将 MSMQ 和 ASPNET 耦合在同一个应用程序池中？
I would host the MSMQ listenner in a windows service. Why couple it to IIS?
UPDATE
Actually what I mean is why couple the MSMQ and ASPNET in the same app pool?
您现在可以使用 IIS8（和 IIS7.5）的“应用程序初始化”功能，包括版本可用性和使用文档在内的更多信息可以在以下位置找到：
http://www.iis.net/learn/get-started/whats-new-in-iis-8/iis-80-application-initialization
这取代了“应用程序预热”不再支持“模块”，它为我们提供了在“始终运行”场景中对组件/服务初始化的适当控制。
You can now use "Application Initialization" feature of IIS8 (and IIS7.5), more information including version availability and usage documentation can be found at:
http://www.iis.net/learn/get-started/whats-new-in-iis-8/iis-80-application-initialization
This replaces "Application Warm-Up Module" which is no longer supported, and provides us with proper control over component/service initialization in an "always running" scenario.