DNN网站能否对接Worker Service执行定时后台任务？有哪些替代方案

现有Worker Service绑定DNN的可行性结论 #

你现有的独立Worker Service无法直接绑定DNN网站自动运行。DNN作为IIS托管的Web应用，进程生命周期受IIS应用池管控，同解决方案下的Worker Service属于独立进程，不会随DNN网站启动自动拉起，就是你目前遇到的必须手动启动才生效的根本原因。

推荐解决方案（按优先级排序） #

方案1：独立部署Worker Service（最适配你的现有实现） #

• 直接将已写完的Worker Service编译为Windows服务（Windows服务器）或systemd守护进程（Linux服务器）单独部署，和DNN网站完全解耦
• 优势：现有业务逻辑零修改，不受IIS应用池回收、DNN网站运行状态影响，完全满足无用户触发也能稳定运行的要求，不会对前端用户体验产生任何影响

方案2：使用DNN原生定时任务机制 #

如果不想维护独立服务，可以用DNN内置的计划任务功能实现：

• 开发步骤：将你的MSSQL查询、写入Redis的逻辑封装为类，继承DotNetNuke.Services.Scheduling.SchedulerClient，重写DoWork()方法实现业务逻辑
• 部署配置：将编译后的dll放到DNN站点的bin目录，登录DNN后台进入「主机 > 计划程序」，新增计划任务指定你写的类的完整限定名，设置执行间隔为2分钟即可
• 注意：需要提前修改IIS对应应用池的配置，将「闲置超时」设为0、开启「应用池自动启动」，避免IIS回收后任务中断

不建议采用的方案 #

• 不要用前端Ajax定时调用的方案：该方案依赖用户打开页面才能触发，无访问时任务会停止，多用户同时访问还会触发重复查询增加数据库压力，完全不符合你的需求
• 不要尝试将Worker Service逻辑嵌入DNN Web进程运行：Web进程的不定时回收机制会中断后台线程，任务稳定性极差

内容的提问来源于stack exchange，提问作者jmath412