【发布时间】：2011-07-04 03:50:43
【问题描述】：
【问题讨论】：
标签： windows scheduled-tasks scheduling quartz.net
【发布时间】：2011-07-04 03:50:43
【问题描述】：
我的直觉是在安装另一个调度程序之前先尝试让完整的 WinScheduler 满足您的需求 - 推理：
- 无需安装 - 默认已安装并启用
- 无需编写代码 - 以元数据表示的作业
- 与事件日志等集成。
- 强大且可靠 - 足以满足 MSFT、Google 等的需求。
- 相当丰富的 API - 创建作业、检查状态等
- 与远程管理工具集成
- 安全集成 - 以不同的凭据运行作业
- 监控工具
如果 Quartz 不能满足您的需求，请使用它。 Quartz 当然也有很多这样的功能，但是如果可以的话，不要再添加另一个服务来拥有和管理。
【讨论】：
-
我有同样的理由：当 Windows 满足您的需求时，为什么要使用一些 3rd 方？我想确保我没有错过任何一艘船。
-
@Reader：这似乎很明显，但是...如果您选择使用 Windows 任务计划程序，您实际上是在将应用程序的一部分暴露给外部世界。任何拥有适当权限的人都可以修改（甚至删除）您的应用程序的任务。这可能对您来说是一个问题，也可能不是。
-
@Pressacco 请原谅我对这么老的帖子发表评论，但这不就是内联测试的用途吗？伪示例：
if (task.Exists) do nothing else (task.Create)? -
@Wolfish：我想说的是，如果您依赖外部服务（例如 Windows 任务计划程序），那么您的应用程序将暴露给外部超出您控制范围的事件（例如意外删除的任务）。另一方面，如果您的应用程序在内部管理调度......那么防御性代码就不是问题了。我的偏好是将调度保留在应用程序内部。话虽如此，有些项目根本没有意义。 en.wikipedia.org/wiki/Defensive_programming
-
@Pressacco 啊，但我们不是一直在与我们代码的用户作斗争吗？呵呵。不过，我明白你的意思。
使用 Quartz.NET，我可以对比前面的一些观点：
- 要编写的代码 - 您可以用 .NET 语言表达您的意图、编写单元测试和调试逻辑
- 与事件日志集成，您拥有 Common.Logging 甚至允许写入 db..
- 坚固可靠
- 更丰富的 API
这主要是关于您需要什么的问题。 Windows 计划任务可能会为您提供所需的一切。但是，如果您需要集群（分布式工作器）、对触发或失火处理规则的细粒度控制，您可能希望查看 Quartz.NET 在这些领域提供的功能。
采用满足您要求的最简单的方法，但要足够抽象以允许更改。
【讨论】：
-
+1 如果您既不了解 Windows Scheduler API 也不了解 Quartz.Net API，那么我认为您使用 Quartz.Net 会更快
-
@Marko，Quartz.Net 可能会影响网站性能。因为在 Windows 调度程序的情况下，它在不同的线程中运行。请提出建议。
-
您可能会在这里混淆线程和进程。 Windows 调度程序确实在它自己的进程中。只要他们都坐在同一个盒子上，他们就会从机器上吃资源。您始终可以在 Windows 服务下托管您的调度程序，无论是在同一个盒子上还是在完全不同的盒子上。
-
quartz-scheduler.net 因为指向quartznet.sourceforge.net 的现有链接不再有效。
-
@MarkoLahma 我认为 Quartz.NET 真的非常有用和聪明。另一方面，我无法创建每周计划。你能看看this的问题吗？
对我来说，其他答案中未包含的一个重要区别是调度程序执行的内容。
Windows 任务计划程序只能运行可执行程序和脚本。为在 Quartz 中使用而编写的代码可以直接与项目的 .NET 组件交互。
使用任务计划程序，您必须编写一个 shell 可执行文件或脚本。在该外壳内部，您可以与项目的组件进行交互。虽然编写此 shell 代码不是一个困难的过程，但您必须考虑部署额外的文件。
如果您预计在项目的生命周期内添加更多计划任务，您最终可能需要创建额外的可执行 shell 或脚本文件，这需要更新部署过程。使用 Quartz，您不需要这些文件，从而减少了创建和部署额外任务所需的总工作量。
【讨论】：
很遗憾，如果不重新启动进程/主机/服务，就无法更新 Quartz.NET 作业程序集。对于某些人（包括我自己）来说，这是一个相当大的问题。
完全有可能为在任务计划程序下运行的作业构建框架。基于 MEF 的程序集可以由单个控制台应用程序调用，所有内容都通过配置 UI 进行管理。这是一个流行的托管包装器：
我确实很享受使用 Quart.NET 的短暂时光，但重新启动要求是一个无法克服的大问题。多年来，Marko 在这方面做得非常好，而且他总是乐于助人且反应迅速。也许有一天该项目将获得多个AppDomain 支持，这将解决这个问题。 （也就是说，这肯定是一项艰巨的工作。如果他和他的贡献者决定接受它，我们要向他们致敬。）
如果需要的话，套用 Marko 的话：
- 集群（分布式工作人员）
- 对触发或失火处理规则的细粒度控制
...那么 Quartz.NET 将是您的要求。
【讨论】：