Windows 服务和计划任务，我们更喜欢哪一个？
如果我们需要编写一个定期运行的程序，我们更喜欢哪种方式？ 编写一个 Windows 服务或编写一个按计划任务工作的控制台应用程序？
If we need to write a program that works periodically, which way do we prefer?
Writing a windows service or writing a console application which works as scheduled task?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（10）
如果可以的话，我建议将进程作为计划任务运行，并且仅在需要时才编写服务。 服务（正确地）编写起来要困难得多，并且如果您按照任何类型的时间表运行进程，那么使用 Windows 调度程序比尝试构建自己的调度程序要好得多（在服务）。
如果您想在两者之间做出决定，那么显然使用任务计划程序是一个可行的选择。 如果使用任务计划程序是一个可行的选择，那么构建服务几乎肯定是错误的选择。
I would suggest running the process as a scheduled task if you can, and writing a service only if you need to. Services are quite a bit more difficult to write (correctly), and if you're running your process on a schedule of any sort, you're much better off using the windows scheduler than attempting to build a scheduler of your own (within the servce).
If you're trying to decide between the two, then obviously using the Task Scheduler is a viable option. And if using the Task Scheduler is a viable option, then building a service is almost certainly the wrong choice.
取决于您需要它运行的频率。
如果它需要全天每 60 秒运行一次，我会选择 Windows 服务。
如果它只需要每天运行一次，我会选择计划任务
中间的任何内容...请使用您的判断:)
Depends on just how regular you need it to run.
If its something that needs to run every 60 seconds all day, I'd go with a Windows Service.
If its something that only needs to run once a day, I'd go with Scheduled Task
Anything in the middle... use your judgement :)
从控制台应用程序开始。 分离位于循环-进程-睡眠循环内部的逻辑，然后您实际上可以轻松地在它们之间切换 - 即使在同一个 EXE 中也是如此。
我已经做到了这一点。 我们可以调用：
ourservice.exe -console
，它就会运行。 或者
ourservice.exe -install
它将作为服务安装:)
在 99% 的情况下我会执行计划任务。 如果您需要一直运行、监听端口、监视文件夹（也许 - 每 10 秒就可以完成一次，没有问题）：然后在服务中执行。 如果您所做的只是醒来，进行一些处理（或不进行处理），然后返回睡眠状态：使用调度程序。 它更容易、更干净（内存管理，特别是如果您使用 COM 对象，如果您使用 MAPI，则真的如此），并且 MS 调度程序的选项（每周一次，但不是星期二下午 5 点）比您在时间......这不是时间，因为它已经存在并且是免费的
哦，调试控制台应用程序（调度程序）比服务更容易......:)或者让某人“运行它”。
Start with a console app. Seperate the logic which would sit inside your loop-process-sleep loop, then you can actually switch between them easily - even in the same EXE.
I've done this. We could call:
ourservice.exe -console
and it'd just run. Or
ourservice.exe -install
and it'll install as a service :)
I'd go scheduled task in 99% of cases. If you need to run all the time, listen on ports, watch a folder (maybe - can be done every 10 seconds without a problem): then do it in a service. If all you do is wake up, do some processing (or not), and then go back to sleep: use the scheduler. It's easier, cleaner (memory management, esp if you are using COM objects, and REALLY if you are using MAPI), and the options (weekly, but not on tuesdays at 5pm) with the MS scheduler are better than you can write in the time..... which is NO time, as it already exists and is free
Oh, and it's easier to debug a console app (scheduler) than a service.... :) Or have someone "just run it".
如果它确实是“定期”，那么我会选择计划任务。 这些可以设置为以任何所需的频率运行。
服务（根据我的经验）更多地适用于必须响应本质上随机事件的程序，例如通过 FTP 到达的文件，或者必须监视文件系统或数据库状态的程序。
If it truly is "periodically" then I'd go with Scheduled Task. These can be set up to run at any desired frequency.
Services are (in my experience) more for programs that have to respond to essentially random events, such as files arriving via FTP, or ones that have to monitor the state of the file system or database.
我认为如果您想使用 WCF 或 .NET Remoting 并让客户端应用程序与某些主机服务进行通信，那么服务可能会很有用； 否则，如果更复杂的服务没有添加任何新内容，我同意计划任务比服务更可取。
@Tom，他关于必须保持登录计算机才能运行计划任务的说法是错误的。 我刚刚测试了自己，并确认即使您没有登录，Windows 计划任务仍然会运行（当然，除非您选择该任务仅在登录时运行的选项）。
I think a service might be useful if you want to use WCF or .NET Remoting and have client applications communicating with some host service; otherwise I agree that a scheduled task is preferable to a service if the more complicated service adds nothing new.
And @Tom, his statement about having to stay logged into a computer for a scheduled task to run is false. I just tested myself, and confirmed that a Windows schedule task will still run even if you're not logged in (unless of course you select the option that the task only runs while you're logged on).
或者，如果您希望定期运行某些内容，请查看quartz.net。 它是一个预构建的框架，允许您安排任务并节省您自己编写服务部分。
Alternatively have a look at quartz.net if you want something to run periodically. It's a pre-built framework that allows you to schedule tasks and saves you writing the service part yourself.
避免使用某项服务，除非您必须使用该服务。
它是一个进程 - 这意味着它一直运行。 无偿地使用系统资源是不好的做法。
我个人认为其他人在我的计算机上 24/7 执行他们的进程是一种侮辱，而这完全没有必要。 他们正在耗尽我的表现。 我禁用所有不必要的后台服务。
Avoid a service unless you must use it.
It is a process - which means it runs all the time. Gratitious use of system resources is bad practise.
I personally find it insulting that other people have their process executing 24/7 on MY computer when it is entirely unnecessary. It's MY performance they're using up. I disable all non-necessary background services.
这取决于你所说的定期是什么意思？ 每秒、每分钟、每小时、每天？
我想说任务运行得越频繁，Windows 服务就越受欢迎。
It depends on what you mean with periodically? Each second, Each minute, each hour, each day?
I would say the more frequent a task is to be running, the more a Windows Service is preferred.
“这取决于”，但为了简单起见，我通常更喜欢计划任务：
如果这或多或少是一次性的，并且需要您自己安装和控制，那么计划任务可能是一个好主意。
对于应该具有成品感觉并且客户应该自行安装的东西，我会选择 Windows 服务。
而且日程安排也是一个问题。 计划任务的最短时间为一分钟。 如果低于此值，您要么需要使用 Windows 服务，要么在您的工作中构建一个循环。
"It depends", but I usually prefer scheduled tasks, for simplicity:
If this is a more or less a one off, and something that you will install and controll yourself, a scheduled task is probably a good idea.
For something that should have the feel of a finished product, and the customer should install themselves, I would go with a Windows Service.
And the schedule is also an issue. The minimum schedule for a scheduled task is one minute. Anything below that, you either need to use a windows service, or build a loop into your job.
我认为这还取决于您是否可以让计算机保持登录状态。 我发现除非设置任务的人登录，否则 Windows 计划任务无法运行。如果计算机无法保持登录状态，则该程序必须作为计划任务的服务运行。
I would think it would also depend on if you can leave the computer logged in or not. I've found that a Windows Scheduled Task cannot run unless the person that set up the task is logged in. If the computer cannot stay logged into, the program must be run as a service vice Scheduled Task.