Windows 事件调度程序自定义服务

发布于 2024-07-10 08:09:35 字数 584 浏览 8 评论 0原文

我需要创建一个像任务计划程序一样工作的 Windows 服务,因为我可以配置它的运行时间,并且它基本上只是在该计划时间(重复)调用 .NET 类。 推荐的方法是什么? 此外,任何有关安装/删除该服务的信息将不胜感激!

更新:使用任务计划程序不是一个选项(客户要求,与他们的 IT 标准有关)。 这也是我向他们提出的建议,但行不通。

解决方案:感谢大家的回答,Quartz.Net 解决方案看起来特别好,但是我发现以下内容正是我所需要的:

http://www.c-sharpcorner.com/UploadFile/ajifocus/AppScheduler05262006074807AM/AppSchedu ler.aspx?文章ID= b52f76da-943f-4807-9675-869f135ef2cd

I need to create a Windows service that works just like the task scheduler in that I can configure what time it runs and it basically just calls a .NET class at that scheduled time (recurring). What is the recommended way to do this? Also, any information on installing/removing that service would be appreciated!

Update: Using the task scheduler in not an option (customer requirement, something to do with their IT standards). That was my suggestion to them as well, but it's not going to work.

Solution: Thanks to everyone for your answers, the Quartz.Net solution especially looks good, however I found the following which has exactly what I need:

http://www.c-sharpcorner.com/UploadFile/ajifocus/AppScheduler05262006074807AM/AppScheduler.aspx?ArticleID=b52f76da-943f-4807-9675-869f135ef2cd

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(8

別甾虛僞 2024-07-17 08:09:35

您可以在服务中嵌入 Quartz.Net 调度程序

You could embed the Quartz.Net scheduler in a service.

篱下浅笙歌 2024-07-17 08:09:35

如果您有权访问该框,为什么不直接使用 Windows 任务计划程序并从控制台 exe 调用功能。 比重新发明轮子容易得多。

If you have access to the box, why not just use the windows task scheduler and call functionality from an console exe. Way more easier than re-inventing the wheel.

鹊巢 2024-07-17 08:09:35

您可以尝试 .NET 任务计划程序 http://TaskService.Codeplex.com。 该项目提供了安排 .NET 程序集在一天中的任何时间运行的能力,并具有不同类型的重复运行,例如每天、每小时、每周、每 5 小时或每三天。

You could try the .NET Task Scheduler http://TaskService.Codeplex.com. This project provides the ability to schedule .NET assemblies to run at anytime of the day with different kinds of recurrences like daily, hourly, weekly, every 5 hour or every third day.

迷鸟归林 2024-07-17 08:09:35

我以前也遇到过同样的问题,任务调度程序本身有点问题。 它永远不可能成为 Linux cron 的可靠替代品。 有一次我必须编写一个服务来做到这一点。 我有一个以 1 秒循环运行的 System.Threading.Timer。 然后它根据我存储在 xml 文件中的配置检查需要触发的事件(外部 exe)。

I had the same problem before, task scheduler has a bit problem by itself. It can never be a reliable replace to linux's cron. Once I had to write a service to do just that. I had a System.Threading.Timer running in a 1 second loop. Then it checks for events that needed to be fired (external exe) according to the configuration I stored in an xml file.

jJeQQOZ5 2024-07-17 08:09:35

如果您正在创建一个调度系统,那么最好编写一个 Windows 服务。 尽管它们很难调试,但如果将所有功能从服务中移出并移至帮助程序和服务代理类中,则可以轻松测试功能,而无需费心服务。

然后,您可以通过 WCF 服务向前端公开需要提供的任何信息。 它们现在可以托管在任何可执行文件中,因此 Windows 服务工作得很好。 Windows 服务策略的优点是您不需要桌面。 计划任务旨在(或应该)在后台运行。 Windows 服务是执行后台任务的好方法。

我研究过售后市场的第三方调度系统、开源调度程序和quartz.net。 我们选择了后者。 如果您的预算足够,请考虑一下 JAMS 等调度系统。

If you are creating a scheduling system, you are much better off writing a windows service. Even though they are hard to debug, if you move all the functionality out of the service and into helper and service agent classes, you can easily test the functionality without needing to bother with the service.

You can then expose whatever information you need to provide to a front end via WCF services. They can be hosted in any executable now, so windows service works just fine. The advantage to the windows service tactic is that you don't need a desktop. Scheduled tasks are (or should be) intended to run in the background. Windows services are a good approach to background tasks.

I've looked at after-market 3rd party scheduling systems, open souce schedulers and quartz.net. We have chosen the latter. If you budget can foot the bill, look at scheduling systems like JAMS or others.

野却迷人 2024-07-17 08:09:35

哦,有这么多。

我将从 .Net 中的标准 Windows 服务开始,并使用 Properties\Settings 功能来存储我的预定时间(这实际上只适用于一次 - 多次需要更复杂的配置)。

我还将包含一个字符串来定义我想要在该配置中运行的程序集/类,并确保该程序集具有一个从基类继承或实现接口的类,以便我可以将其加载为已知类型并执行一个名为 Execute() 的已知方法。

或者,您也可以在配置文件中定义要调用的方法,并使用反射来调用该方法。

Oh there are so many.

I'd start with a standard windows service in .Net and use the Properties\Settings feature to store my scheduled time (this really only works with a single time - a more sophisticated config would be required for more than one time).

I would also include a string to define the assembly/class I wanted to run in that configuration as well and make sure that assembly had a class that either inherited from a base class or implemnented an interface so I could load it up as a known type and Execute a known method called something like Execute().

Or you could defint the method you want to call in the configuration file as well and use reflection to call that method.

弃爱 2024-07-17 08:09:35

抱歉,我的回复没有告诉您如何实现这一点。

为什么您的客户会禁止使用某些内置操作系统功能,同时允许运行其自行开发的克隆版本?

我认为,与将 Windows 调度程序重新创建为稳定的服务相比,尝试让客户相信这是一个胡扯的要求要容易得多。 除了通过使用现有的解决方案来节省时间之外,您最终可能会得到更好的解决方案。 对每个人来说都是双赢:)

I'm sorry, my response doesn't tell you how to implement this.

Why would your customer forbid using some built-in OS feature, while allowing a home-grown clone of it to be run?

I think it's going to be less work to try to convince your customer that it's a bullshit requirement than it is to recreate the windows scheduler as a stable service. Besides saving time by just using the existing one, you'll probably end up with a better solution. A win-win for everyone :)

甜尕妞 2024-07-17 08:09:35

最重要的是要认识到创建 Windows 服务是相当复杂的。 对于版本 6 及更高版本的产品尤其如此,因为服务与桌面隔离。 以下是一些评论

  • 服务比基本用户模式程序更难调试。
  • 在 V6 及更高版本的操作系统上,服务无法与用户交互。 所以你不能给他们一个控制台或者让他们直接弹出消息框。
  • 与服务的通信通常通过远程过程调用或进程外 COM 完成。 即使对于看似相互竞争的事物,两者也可能很复杂。
  • 服务运行至关重要,因此它们必须比其他可执行文件更加可靠和高效。
  • 根据安全上下文,可能很难让服务导致系统中发生其他事情。

我会推荐“守护者”而不是服务。 这将是一个具有隐藏用户界面的小程序 - 只需在启动时运行它,就像任何其他应用程序一样。 它将在用户的上下文中运行,并且可以执行用户可以执行的任何操作(这可能是您想要的)。 如果需要,您可以给它一个托盘图标,或者使用来自其他应用程序之一的信号来让它显示其简单的 UI。

Its most important to realize that creating a windows service is quite complicated to get right. This is especially true on Version 6 and later products because services are isolated form the desktop. Here are a few comments

  • Services are harder to debug than basic user mode program.
  • Services cannot interact with the user on V6 and later operating systems. So you cannot give them a console or have them pop up message boxes directly.
  • Communicating with a services is usually done via Remote Procedure Call or out of process COM. Both can be complicated even for seemingly rival things.
  • Services run essential fervor so they must be significantly more reliable and efficient than other executable.
  • Depending on the security context, it can be difficult to get a service to cause other things to happen in the system.

Instead of service, I would recommend a "deamon". This would be a small program that has a hidden user interface - just run it at startup just like any other app. It will run in the user's context and can do any thing the user can do (which is probably what you want). You could give it a tray icon if you needed, or use a signal from one of your other apps to have it reveal its simple UI.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文