用StartMode="AlwaysRunning“在ASP .NET 4上运行Windows Service型应用的思考
通常，我会考虑编写一个Windows服务来管理不适合托管在web应用程序中的任务。这些类型的任务通常是长时间运行的进程或计划任务。虽然这通常是处理这些类型任务的主要方法，但people通过在Global.asax公开的Application_Start事件中启动许多线程，研究了在web应用程序中运行这些类型的后台进程的方法。这种方法的问题一直是，如果您的IIS工作进程死了，那么您的后台线程也会被终止(实际上，您的“Windows服务”将停止，直到收到下一个请求)。
ASP.NET .NET 4.0提供了解决这个问题的方法。您现在可以将StartMode设置为'AlwaysRunning‘，如Scott Gu在此blog post中所述。Somewhere在这篇文章的评论中，有人问了一个关于在IIS中托管Windows Service类型任务的可行性的问题，因为新功能确保了工作进程始终在运行。Scott提到，它肯定会支持这种情况。此外，最近引入的AppFabric意味着微软自己正在提供简单的挂钩，用于在web应用程序中托管和监控WCF和WF服务。
这对我们这些曾经编写Windows服务来支持我们的web应用程序的人来说意味着什么？我们应该采用这种模式吗？陷阱是什么？据我所知，在web应用程序中托管“Windows服务”进程有许多好处，最有用的是易于部署。此外，我们实际上可以开始为我们的服务开发简单的用户界面，这些界面提供了关于运行时发生的事情的信息。
如果我必须走这条路，我不认为我会在面向客户的web应用程序中托管我的“Windows Service”类型的功能。我可能会开发一个新的web应用程序项目(就像我在Windows服务上下文中所做的那样)，它将托管我的长时间运行/计划的任务流程。我想这样做的原因很少。
- Security.对于显示有关正在运行的后台进程的信息的UI，可能存在不同的安全模型。除了运营团队，我不想将这个UI公开给任何人。此外，web应用程序可以作为具有提升的permissions.
- Maintenance.集的不同用户运行如果能够将更改部署到托管后台进程的应用程序，而不会影响使用前端website.
- Performance.的用户，那就太好了将应用程序与处理用户请求的主站点分开意味着后台线程不会削弱IIS处理传入请求队列的能力。此外，如果需要，可以将处理后台任务的应用程序部署到单独的服务器上。
我真的很想听听你对这种方法的看法，以及我是否应该坚持使用Windows服务。我很想尝试这种新方法。
回答 3
Stack Overflow用户
发布于 2010-09-16 21:13:31
这对我们这些曾经编写Windows服务来支持我们的web应用程序的人来说意味着什么？
我认为这是一个关键的场景，你可以从Windows服务转移到使用持续运行的网站。
我们应该采用这种模式吗？
标准开发答案:依赖;)
陷阱是什么？
我能看到的一个问题是IIS依赖。如果您需要在用户的机器上运行服务，我不会觉得要求他们安装IIS只是为了运行我的服务。在这里，我认为传统模型效果更好。
监控和跟踪是主要问题，但正如您也指出的那样，这是由AppFabric解决的。它甚至比你从窗口服务中得到的更好。但是，您添加了另一个依赖项，该依赖项也需要Windows4.0和相对较新的.NET版本。我在这里也可能是错的，但我的理解是，在客户端操作系统上的生产环境中不支持AppFabric，这可能会带来额外的麻烦。
在连续网站模型中，你也会失去暂停功能。
最后，IIS杀死不活跃的应用程序池并不是应用程序池可以回收的唯一方法。例如，编辑web.config文件会导致这种情况，这可能不是理想的情况。
最有用的是易于部署。
我还认为开发要容易得多--在过去，我有一个控制台应用程序和一个windows服务，这样我就可以使用控制台应用程序在我的机器上进行开发/测试，然后在它发布时将其更改为windows服务。现在dev/test变得容易多了。
Stack Overflow用户
发布于 2010-09-20 18:07:25
陷阱是什么？
我发现了一个，没有停机事件。当网站启动时你有AppStart (不是global.asax，因为那只是超文本传输协议)，但是你没有办法处理关机，这可能意味着处理成为一个问题。
Stack Overflow用户
发布于 2010-09-15 01:03:06
我建议继续使用windows服务。问题出在你的号码2上。如果不重新启动整个网站，你将无法更新网站的服务部分。
https://stackoverflow.com/questions/3711081
复制相似问题
腾讯云开发者
