（不够方便，不能随时更改计划时间。）
2，window服务，可以在数据库里配置时间，使用计时器Threading.Timer或Timers.Timer，到达时间点就开始任务。
不知道哪种性能好一些，还是有更好的办法？
7 个解决方案
#1
性能应该是在于你执行的计划任务吧，而不是定时执行本身
#2
1.怎么不够方便了？直接登录服务器就可以改了
2. 怎么就方便了？你还不是要登录服务器改时间。如果你用程序改，那程序从哪里来？
2. 怎么就方便了？你还不是要登录服务器改时间。如果你用程序改，那程序从哪里来？
#3
第一种方式操作更加简便。但是作为服务器程序，一般做成服务的方式好些。比如服务器意外重启后，应用程序不一定会起得来，但是服务肯定可以起得来。至于性能，不是说看你启动那一下，而是看你具体执行了什么东西。执行的任务才是耗性能的东西。简单的线程扫描不会有多少的性能消耗，肉眼看不出。
#4
实现功能，无所谓那个都行
#5
个人认为第二种方式比较好，可以根据电脑一起重启，这样省却了很多事。
#6
我觉得看什么样子的任务了吧。
如果一天一次，我会用scheduled task,自动结束，异常发邮件。
如果几分钟一次，我会用windows service.
如果一天一次，我会用scheduled task,自动结束，异常发邮件。
如果几分钟一次，我会用windows service.
#7
撇开任务的性能。
使用第一种，问题就在于不是所有人都有权限登录服务器，那如果一般人员要调整，还要跟有权限的人说，让他去弄，比较麻烦。
但个人觉得好就好在，任务完成后，进程里就注销掉了。
第二种的话，进程一直存在，且一直在比对时间。我可以在网页版后台里增加调整时间的功能。每次任务时都重新获取时间。
个人也是偏向于第二种，就是不知道这个每秒的获取时间比对对性能的影响可以忽略吗？
使用第一种，问题就在于不是所有人都有权限登录服务器，那如果一般人员要调整，还要跟有权限的人说，让他去弄，比较麻烦。
但个人觉得好就好在，任务完成后，进程里就注销掉了。
第二种的话，进程一直存在，且一直在比对时间。我可以在网页版后台里增加调整时间的功能。每次任务时都重新获取时间。
个人也是偏向于第二种，就是不知道这个每秒的获取时间比对对性能的影响可以忽略吗？
#1
性能应该是在于你执行的计划任务吧，而不是定时执行本身
#2
1.怎么不够方便了？直接登录服务器就可以改了
2. 怎么就方便了？你还不是要登录服务器改时间。如果你用程序改，那程序从哪里来？
2. 怎么就方便了？你还不是要登录服务器改时间。如果你用程序改，那程序从哪里来？
#3
第一种方式操作更加简便。但是作为服务器程序，一般做成服务的方式好些。比如服务器意外重启后，应用程序不一定会起得来，但是服务肯定可以起得来。至于性能，不是说看你启动那一下，而是看你具体执行了什么东西。执行的任务才是耗性能的东西。简单的线程扫描不会有多少的性能消耗，肉眼看不出。
#4
实现功能，无所谓那个都行
#5
个人认为第二种方式比较好，可以根据电脑一起重启，这样省却了很多事。
#6
我觉得看什么样子的任务了吧。
如果一天一次，我会用scheduled task,自动结束，异常发邮件。
如果几分钟一次，我会用windows service.
如果一天一次，我会用scheduled task,自动结束，异常发邮件。
如果几分钟一次，我会用windows service.
#7
撇开任务的性能。
使用第一种，问题就在于不是所有人都有权限登录服务器，那如果一般人员要调整，还要跟有权限的人说，让他去弄，比较麻烦。
但个人觉得好就好在，任务完成后，进程里就注销掉了。
第二种的话，进程一直存在，且一直在比对时间。我可以在网页版后台里增加调整时间的功能。每次任务时都重新获取时间。
个人也是偏向于第二种，就是不知道这个每秒的获取时间比对对性能的影响可以忽略吗？
使用第一种，问题就在于不是所有人都有权限登录服务器，那如果一般人员要调整，还要跟有权限的人说，让他去弄，比较麻烦。
但个人觉得好就好在，任务完成后，进程里就注销掉了。
第二种的话，进程一直存在，且一直在比对时间。我可以在网页版后台里增加调整时间的功能。每次任务时都重新获取时间。
个人也是偏向于第二种，就是不知道这个每秒的获取时间比对对性能的影响可以忽略吗？