这主要是关于您需要什么的问题。 Windows 计划任务可能会为您提供所需的一切。但是，如果您需要集群（分布式工作人员）、对触发或失火处理规则的细粒度控制，您可能需要检查 Quartz.NET 在这些领域提供的功能。
采用最简单的方法来满足您的要求，但足够抽象以允许更改。
With Quartz.NET I could contrast some of the earlier points:
Code to write - You can express your intent in .NET language, write unit tests and debug the logic
Integration with event log, you have Common.Logging that allows to write even to db..
Robust and reliable too
Even richer API
It's mostly a question about what you need. Windows Scheduled tasks might give you all you need. But if you need clustering (distributed workers), fine-grained control over triggering or misfire handling rules, you might like to check what Quartz.NET has to offer on these areas.
Take the simplest that fills your requirements, but abstract enough to allow change.
My gut reaction would be to try and get the integral WinScheduler to work with your needs first before installing yet another scheduler - reasoning:
no installation required - installed and enabled by default
no code to write - jobs expressed as metadata
integration with event log etc.
robust and reliable - good enough for MSFT, Google etc.
reasonably rich API - create jobs, check status etc.
integrated with remote management tools
security integration - run jobs in different credentials
monitoring tooling
Then reach for Quartz if it doesn't meet your needs. Quartz certainly has many of these features too, but resist adding yet another service to own and manage if you can.
One important distinction, for me, that is not included in the other answers is what gets executed by the scheduler.
Windows Task Scheduler can only run executable programs and scripts. The code written for use within Quartz can directly interact with your project's .NET components.
With Task Scheduler, you'll have to write a shell executable or script. Inside of that shell, you can interact with your project's components. While writing this shell code is not a difficult process, you do have to consider deploying the extra files.
If you anticipate adding more scheduled tasks over the lifetime of the project, you may end up needing to create additional executable shells or script files, which requires updates to the deployment process. With Quartz, you don't need these files, which reduces the total effort needed to create and deploy additional tasks.
Unfortunately, Quartz.NET job assemblies can't be updated without restarting the process/host/service. That's a pretty big one for some folks (including myself).
It's entirely possible to build a framework for jobs running under Task Scheduler. MEF-based assemblies can be called by a single console app, with everything managed via a configuration UI. Here's a popular managed wrapper:
I did enjoy my brief time of working with Quart.NET, but the restart requirement was too big a problem to overcome. Marko has done a great job with it over the years, and he's always been helpful and responsive. Perhaps someday the project will get multiple AppDomain support, which would address this. (That said, it promises to be a lot of work. Kudos to he and his contributors if they decide to take it on.)
To paraphrase Marko, if you need:
Clustering (distributed workers)
Fine-grained control over triggering or misfire handling rules
发布评论
评论（4）
使用 Quartz.NET，我可以对比之前的一些观点：
这主要是关于您需要什么的问题。 Windows 计划任务可能会为您提供所需的一切。但是，如果您需要集群（分布式工作人员）、对触发或失火处理规则的细粒度控制，您可能需要检查 Quartz.NET 在这些领域提供的功能。
采用最简单的方法来满足您的要求，但足够抽象以允许更改。
With Quartz.NET I could contrast some of the earlier points:
It's mostly a question about what you need. Windows Scheduled tasks might give you all you need. But if you need clustering (distributed workers), fine-grained control over triggering or misfire handling rules, you might like to check what Quartz.NET has to offer on these areas.
Take the simplest that fills your requirements, but abstract enough to allow change.
我的直觉反应是，在安装另一个调度程序之前，首先尝试让集成的 WinScheduler 满足您的需求 - 推理：
如果 Quartz 不能满足您的需求，请使用 Quartz 。 Quartz 当然也有许多这样的功能，但如果可以的话，不要再添加另一个服务来拥有和管理。
My gut reaction would be to try and get the integral WinScheduler to work with your needs first before installing yet another scheduler - reasoning:
Then reach for Quartz if it doesn't meet your needs. Quartz certainly has many of these features too, but resist adding yet another service to own and manage if you can.
对我来说，其他答案中未包含的一个重要区别是调度程序执行的内容。
Windows 任务计划程序只能运行可执行程序和脚本。为在 Quartz 中使用而编写的代码可以直接与项目的 .NET 组件交互。
使用任务计划程序，您必须编写 shell 可执行文件或脚本。在该 shell 内，您可以与项目的组件进行交互。虽然编写此 shell 代码并不是一个困难的过程，但您确实必须考虑部署额外的文件。
如果您预计在项目的生命周期内添加更多计划任务，则最终可能需要创建额外的可执行 shell 或脚本文件，这需要更新部署过程。使用 Quartz，您不需要这些文件，这减少了创建和部署其他任务所需的总工作量。
One important distinction, for me, that is not included in the other answers is what gets executed by the scheduler.
Windows Task Scheduler can only run executable programs and scripts. The code written for use within Quartz can directly interact with your project's .NET components.
With Task Scheduler, you'll have to write a shell executable or script. Inside of that shell, you can interact with your project's components. While writing this shell code is not a difficult process, you do have to consider deploying the extra files.
If you anticipate adding more scheduled tasks over the lifetime of the project, you may end up needing to create additional executable shells or script files, which requires updates to the deployment process. With Quartz, you don't need these files, which reduces the total effort needed to create and deploy additional tasks.
不幸的是，如果不重新启动进程/主机/服务，Quartz.NET 作业程序集就无法更新。对于某些人（包括我自己）来说，这是一个相当大的问题。
完全有可能为在任务计划程序下运行的作业构建一个框架。基于 MEF 的程序集可以由单个控制台应用程序调用，所有内容都通过配置 UI 进行管理。这是一个流行的托管包装器：
我确实很享受使用 Quart.NET 的短暂时光，但重启要求是一个太大的问题，难以克服。多年来，Marko 在这方面做得非常出色，而且他总是乐于助人且反应灵敏。也许有一天，该项目将获得多个 AppDomain 支持，这将解决这个问题。 （也就是说，这肯定需要大量工作。如果他和他的贡献者决定接受它，我会向他们表示敬意。）
如果您需要的话，可以套用 Marko 的话：
...那么 Quartz.NET 将是您的要求。
Unfortunately, Quartz.NET job assemblies can't be updated without restarting the process/host/service. That's a pretty big one for some folks (including myself).
It's entirely possible to build a framework for jobs running under Task Scheduler. MEF-based assemblies can be called by a single console app, with everything managed via a configuration UI. Here's a popular managed wrapper:
I did enjoy my brief time of working with Quart.NET, but the restart requirement was too big a problem to overcome. Marko has done a great job with it over the years, and he's always been helpful and responsive. Perhaps someday the project will get multiple
AppDomainsupport, which would address this. (That said, it promises to be a lot of work. Kudos to he and his contributors if they decide to take it on.)To paraphrase Marko, if you need:
...then Quartz.NET will be your requirement.