为什么我会通过Web API服务选择Windows服务？

-4

对我来说，Windows服务不方便且麻烦，足以在所有不是“查看此文件夹以进行更改，对此更改作出反应”的应用程序中对其有效性提出质疑。为什么我会通过Web API服务选择Windows服务？

据我所知，这种过于简单化是无知的，为什么会选择通过Web API的Windows服务。

来源

2016-04-27 Chazt3n

内部服务器管理，自动化，事件跟踪/链接......并非所有事情都是基于网络的......为什么要调用Web API来轮询/响应Windows事件日志？或者服务用于其他任何数量的内部操作？ – jleach

每次你有什么东西没有被HTTP请求激活？

要获得提示，请从WIN+R（运行程序）运行services.msc。浏览服务并尝试查看是否所有服务都可以托管在IIS中。

如果不是：那么，你的答案是。

我确实相信我们可以通过我们的集中监控服务以及IIS“永不落脚”模块重新启动问题进行滑冰。我选择在自动部署时将服务作为Windows服务保留，但是我并不完全相信这是值得安装 - >附加调试器 - >更改 - >启动/停止 - >附加调试器 - >枷时因为服务锁定了一个文件调试失败，等等

恕我直言，这是更脆弱，依赖于监控服务和总是模块，当你有东西对于已经内置到Windows（监控= Windows事件日志）。

至于调试windows服务，它们很容易在Program.cs中进行小调整。我已经在这里写了：http://blog.gauffin.org/2011/09/05/an-easier-way-to-debug-windows-services/

来源

2016-04-27 17:11:11 jgauffin

好的，现在我们正在做饭。假设我有一个自行托管的Web API在Windows服务中运行。如果他还要订阅一个消息队列，让他成为一个Web服务会是一个糟糕的主意吗？ – Chazt3n

您是否100％确定可以保持应用程序池和IIS运行？重启后会发生什么？ IIS通常只在第一个请求到达时启动应用程序。它闲置时会被取下。这意味着你的消息队列将不会被读取。有了Windows服务，您肯定知道它在Windows下启动，并在关闭wndows时正常关闭。 – jgauffin

我确实相信我们可以通过我们的集中监控服务以及IIS“永不停机”模块来重新启动问题。我选择在自动部署时将服务作为Windows服务保留，但是我并不完全相信这是值得安装 - >附加调试器 - >更改 - >启动/停止 - >附加调试器 - >当调试程序因为服务锁定文件等而失败时，会发生连锁故障。 – Chazt3n

为什么我会通过Web API服务选择Windows服务？

回答

相关问题