预定的控制台应用程序与 Windows 服务？什么时候适合使用每个

Scheduled console app vs Windows service? When is it appropriate to use each

提问by Kyle West

I just read this: What is the benefit of developing the application as a windows service?but I'm still unsure of when to use a windows service.

我刚刚读到：将应用程序开发为 Windows 服务有什么好处？但我仍然不确定何时使用 Windows 服务。

I have a couple tasks that need to be run at intervals (i.e. every 5 minutes). Which project type should I use? Are there any examples of the types of applications that should be Windows services?

我有几个任务需要每隔一段时间（即每 5 分钟）运行一次。我应该使用哪种项目类型？是否有任何应为 Windows 服务的应用程序类型的示例？

回答by Stephen Martin

For single or narrow purpose applicationsrun on a schedule, running a console application via the Task Scheduler is almost always the correct design.

对于按计划运行的单一或狭窄用途的应用程序，通过任务计划程序运行控制台应用程序几乎总是正确的设计。

For long running or complex tasksthat may need interaction such as manual start, stop, pausing, continuing, etc. then, in general, a Windows Service is the better option.

对于可能需要手动启动、停止、暂停、继续等交互的长时间运行或复杂任务，通常，Windows 服务是更好的选择。

Scheduled tasks can be run under any account and do not need a user logged in just like Services. For single purpose tasks such as those you propose external control of the task is usually irrelevant so you have no need of the controllability of a Service.

计划任务可以在任何帐户下运行，不需要像服务一样需要用户登录。对于单一用途的任务，例如您建议的任务的外部控制通常无关紧要，因此您不需要服务的可控性。

A big factor also is the Task Scheduler is a very robust and flexible event based scheduler. It is extremely unlikely that you could write a scheduler that was more robust and could handle the vagaries of time and trigger based scheduling. In fact there are a number of questions about using timers for scheduling tasks in services on this site and it is remarkable the number of answers (including some of the 'correct' answers) that are poor quality or outright incorrect.

一个重要的因素也是任务调度程序是一个非常健壮和灵活的基于事件的调度程序。您极不可能编写一个更健壮的调度程序，并且可以处理变幻莫测的时间和基于触发器的调度。事实上，有许多关于在本站点上的服务中使用计时器调度任务的问题，而且质量差或完全不正确的答案（包括一些“正确”答案）的数量非常多。

EDIT: It's also interesting to note that Microsoft policy is shifting away from using services for task based actions. If you check Vista, Win2K8 and Win7 you will notice a growing list of special purpose scheduled tasks that perform system maintenance and many system services.

编辑：值得注意的是，微软的政策正在从使用服务进行基于任务的操作转移。如果您查看 Vista、Win2K8 和 Win7，您会注意到执行系统维护和许多系统服务的特殊目的计划任务的列表越来越多。

回答by Sam Schutte

For any scheduled task, I would usually recommend a Windows Service, for the following reasons:

对于任何计划任务，我通常会推荐 Windows 服务，原因如下：

• A Windows Service will run even if a user is not logged into the PC (will run even if the server is sitting at the login prompt) (***Note - this may depend on the version of Windows you are running).
• A service can run as high-authority accounts such as Network Service or Local System, or a User - they have more configurability in that regard
• A service also comes built in with options for starting, stopping, restarting, and pausing while running (sometimes)
• You can also set up failure conditions for services, like if it fails have it auto-restart

• 即使用户未登录到 PC，Windows 服务也会运行（即使服务器处于登录提示时也会运行）（***注意 - 这可能取决于您运行的 Windows 版本）。
• 服务可以作为高权限帐户（例如网络服务或本地系统）或用户运行 - 他们在这方面具有更多的可配置性
• 服务还内置了启动、停止、重新启动和运行时暂停的选项（有时）
• 您还可以为服务设置失败条件，例如如果失败让它自动重启

As far as other examples of applications that can be windows services, a lot of times they are useful for applications such as remoting - you can have a service run a remoting server that clients connect to. Obviously very useful for data processing tasks that you want to run in the background as well, or processes where you want to send an email on certain conditions, etc.

至于可以是 Windows 服务的其他应用程序示例，很多时候它们对远程处理等应用程序很有用 - 您可以让服务运行客户端连接到的远程处理服务器。显然，对于您想在后台运行的数据处理任务，或者您想在某些条件下发送电子邮件的流程等，这非常有用。

In general I've always found scheduled tasks to be much more fragile and unreliable. And unless you have them log properly, often harder to debug.

总的来说，我一直发现计划任务更加脆弱和不可靠。除非您正确记录它们，否则通常更难调试。

In reference to the bug with the Timer - if you read the bug report on MS's site, you can see that it is caused when you call "Stop" inside the Timer_Elapsed event. The answer to this is simple - don't call stop. Instead, wrap the whole thing in a check for a "IsRunning" boolean and only run if IsRunning is false. Even if there wasn't an issue with the timer, you need to do this anyway because the timer might re-fire during your execution if your execution takes longer than your timer interval.

关于 Timer 的错误 - 如果您阅读 MS 站点上的错误报告，您可以看到它是在 Timer_Elapsed 事件中调用“停止”时引起的。答案很简单——不要叫停。相反，将整个事情包装在检查“IsRunning”布尔值中，并且仅在 IsRunning 为 false 时运行。即使计时器没有问题，您仍然需要这样做，因为如果您的执行时间超过您的计时器间隔，计时器可能会在您的执行期间重新触发。

Anyway, I still think using scheduled tasks is a weak solution and gives me flashbacks of Windows 95.

无论如何，我仍然认为使用计划任务是一个薄弱的解决方案，并且让我想起了 Windows 95。

回答by Seth Spearman

Having had to do write, debug, deploy and support both, I prefer Scheduled Tasks far and away. I don't doubt that there are use cases where this would be the wrong choice. But for any relatively trivial task a console app running as a schedule task works great.

不得不编写、调试、部署和支持两者，我更喜欢计划任务。我不怀疑在某些用例中这是错误的选择。但是对于任何相对微不足道的任务，作为计划任务运行的控制台应用程序效果很好。

In my experience, scheduled tasks are extremely reliable. I don't recall a single failure and I support about a half dozen different scheduled tasks that run anywhere from daily to every 15 minutes. (Not that there have been no failures but they were all code or config issues. And were logged and notifications were sent. The problem has NEVER been with the Task Scheduling infrastucture.)

根据我的经验，计划任务非常可靠。我不记得有一次失败，而且我支持大约六种不同的计划任务，这些任务从每天到每 15 分钟在任何地方运行。（并不是说没有失败，而是它们都是代码或配置问题。并且被记录下来并发送了通知。问题从来没有出现在任务调度基础设施上。）

Task Scheduler tasks can run under any user context and does not need anyone to be logged in.

任务计划程序任务可以在任何用户上下文下运行，不需要任何人登录。

My biggest plus is in deployment. For console apps, just publish the EXE to the correct target folder. For windows services you need to stop the service (using net.exe), uninstall the service (using InstallUtil.exe), wait (I have the deployment sleep for 25 seconds), publish the EXE and then do it all in reverse (install, start).

我最大的优点是部署。对于控制台应用程序，只需将 EXE 发布到正确的目标文件夹即可。对于 Windows 服务，您需要停止服务（使用 net.exe），卸载服务（使用 InstallUtil.exe），等待（我有 25 秒的部署睡眠），发布 EXE，然后反向执行所有操作（安装， 开始）。

If I were to develop a windows service again I would write it as a console app and then find a way to wrap it into a service to make debugging less of a headache.

如果我要再次开发 Windows 服务，我会将其编写为控制台应用程序，然后找到一种方法将其包装到服务中，以减少调试的麻烦。

回答by Frank

I have a number of windows scheduled tasks that run hourly on a production web server. They are not reliable at all. They are running in Windows 2003 Server under a specific machine account. Most of the time they work perfectly, but occasionally they fail to run and sometimes they terminate before they are finished.

我有许多 Windows 计划任务，它们在生产 Web 服务器上每小时运行一次。他们根本不可靠。它们以特定的计算机帐户在 Windows 2003 Server 中运行。大多数情况下它们运行良好，但偶尔它们无法运行，有时它们在完成之前就终止了。

Some of this may be due to the fact that they are vbscripts and the way they are written, but I've seen scheduled tasks with WS FTP Pro (commercial FTP software) that behave the same way.

其中一些可能是由于它们是 vbscripts 和它们的编写方式，但我已经看到 WS FTP Pro（商业 FTP 软件）的计划任务的行为方式相同。

I've converted many of these to windows services and have never had to worry about them again.

我已经将其中的许多转换为 Windows 服务，并且再也不用担心它们了。

I would definitely lean towards windows services. Like some of the other comments, I have been burned by windows scheduled tasks too many times. I don't trust them for enterprise level solutions.

我肯定会倾向于 Windows 服务。像其他一些评论一样，我被windows计划任务烧了太多次了。我不相信他们的企业级解决方案。

回答by naasking

I would recommend a scheduled task in all cases except programs that need to run at very short intervals, or that run continuously. Programs that start, perform their function, and shutdown have well defined resource lifetimes, perform the appropriate setup and cleanup in a bounded number of steps (and if not, the fact that they don't terminate in the expected time is indication of a bug), and thus are easier to reason about. And you don't need to fiddle about with timers and such.

除了需要以非常短的时间间隔运行或连续运行的程序外，我建议在所有情况下都使用计划任务。启动、执行其功能和关闭的程序具有明确定义的资源生命周期，在有限数量的步骤中执行适当的设置和清理（如果没有，它们没有在预期时间内终止的事实表明存在错误)，因此更容易推理。而且你不需要摆弄计时器之类的东西。

Scheduled tasks have equivalent operations to the stop and restart commands of services, ie. disable task, enable task. Simple, and it lets any current operations in progress complete instead of trying to abort them, which is inherently correctway to handle this. Doing all of this state/transition management resource lifetimes manually is just error-prone in the presence of refactoring.

计划任务具有与服务的停止和重启命令等效的操作，即。禁用任务，启用任务。很简单，它可以让正在进行的任何当前操作完成，而不是试图中止它们，这本质上是处理这个问题的正确方法。在重构的情况下，手动执行所有这些状态/转换管理资源生命周期很容易出错。

回答by Otávio Décio

That is a typical case for windows service, IMO.

这是 Windows 服务 IMO 的典型案例。

回答by Kb.

I would prefer windows service in most cases.
One good thing when using scheduled tasks:
All used resources are released when the scheduled task have finished.

在大多数情况下，我更喜欢 Windows 服务。
使用计划任务时的一件好事：
当计划任务完成时，所有使用的资源都会被释放。

When using windows service (without stopping the service), the process never dies. And you must in your program make sure that resources are released.

使用windows服务时（不停止服务），进程永远不会死。而且你必须在你的程序中确保资源被释放。