Windows Scheduler API with a console application. Vs.net scheduler tools with asp.net mvc to run lengthy processes inside my asp.net mvc

Question

I am working on an asp.net mvc-5 web application deployed under windows 2012 and iis-8. My asp.net mvc has many CRUD operations that are implemented as action methods inside my asp.net mvc. But my asp.net mvc web application will carry out the planned lengthy network scanning process, network scanning will basically do the following steps: -

• Get a list of our servers and vms from our database.
• Get the username and password for scanning for each server and vm from a third-party tool using the Rest API.
• Call several powershell scripts to get the servers and vms information, such as network information, memory, name, etc.
• Update our ERP system with verification information using the Rest API.

Now I have completed a pilot project using the following approach: -

• I am defining the Model method inside my asp.net mvc to complete the above 4 steps.
• Then I install the hangfire tool, which will invoke the scan method on the predefined scheduler.
• I also create a View inside my asp.net mvc, which allows users to set hangfire schedule parameters (for this, IIS reset must be done on the host server for hangfire to get the new settings).

Now I run a test scan for 150 servers, which took about 40 minutes, and it worked fine. The only thing I noticed is that if I set up a schedule for working after hours (if no actions are performed in IIS), then hangfire will not be able to call the task, and as soon as the first request is completed, the missed tasks will start. I overcome this limitation by defining a Windows task that calls IIS every 15 minutes to maintain the application pool in real time, and it worked well ...

Now the other approach that I am reading makes mine higher, as follows: -

• Instead of defining a model method inside asp.net mvc to perform a scan, I can create a separate console application for scanning.
• Then, inside my asp.net mvc, a view is created that allows users to create and schedule a task inside the Windows Task Scheduler. I can do this by integrating with the Windows Task Scheduler API.
• If this Windows task calls a console application.

Now I'm not sure which approach is better and why? now, generally speaking, lengthy work / background jobs should not run under iis. But at the same time, defining these lengthy processes as a console application and invoking these applications inside the Windows Task Scheduler will create additional dependencies on my web application. And it will add extra effort when moving the application from the transition server to another (for example, from a test to live). In addition, I read that tools like hangfire, quartz, and others are designed to run long tasks inside IIS, and they eliminate the need to create console applications and schedule these console applications using the task scheduler. So can anyone advise this?

Answer 1

In my opinion, if you can solve the planning problem on the side of the web application, there is no need to create a scheduler task or a new console application to run. The problem that you may have to deal with when using the scheduling task in a web application is usually a common one, as you can see that: the scheduler works like a charm while debugging a web application, but cannot start after publishing it to IIS , At the moment, the problem is usually related to IIS , and not to Quartz.NET , Hangfire , etc. Hangfire . Although there are many articles or solutions on the Internet, unfortunately, only some of them work properly. In addition to this, most of them require a large number of network configuration settings and machine configurations.

However, there are some solutions for these types of planning tasks, and I believe that it is worth trying Keep Alive Service For IIS 6.0 / 7.5 . Just install it on the server where you publish your application and enjoy. Then your published application will be available after recycling the application pool, restarting IIS / Application, etc. It is also used in our MVC application to send emails weekly and worked for months without any problems. Here is an example of the code that I use in our MVC application. For more information, visit Scheduled Tasks in ASP.NET with Quartz.Net and Quartz.NET CronTrigger .

Global.asax:

 protected void Application_Start() { JobScheduler.Start(); } 

EmailJob.cs:

 using Quartz; public class EmailJob : IJob { public void Execute(IJobExecutionContext context) { SendEmail(); } } 

JobScheduler.cs:

 using Quartz; using Quartz.Impl; public class JobScheduler { public static void Start() { IScheduler scheduler = StdSchedulerFactory.GetDefaultScheduler(); scheduler.Start(); IJobDetail job = JobBuilder.Create<EmailJob>().Build(); ITrigger trigger = TriggerBuilder.Create() .WithIdentity("trigger1", "group1") .StartNow() .WithSchedule(CronScheduleBuilder .WeeklyOnDayAndHourAndMinute(DayOfWeek.Monday, 10, 00) //.WithMisfireHandlingInstructionDoNothing() //Do not fire if the firing is missed .WithMisfireHandlingInstructionFireAndProceed() //MISFIRE_INSTRUCTION_FIRE_NOW .InTimeZone(TimeZoneInfo.FindSystemTimeZoneById("GTB Standard Time")) //(GMT+02:00) ) .Build(); scheduler.ScheduleJob(job, trigger); } } 

Hope this helps ...

Answer 2

• I also create a View inside my asp.net mvc, which allows users to set hangfire schedule parameters (for this, IIS reset must be done on the host server for hangfire to get the new settings).

Are you updating your web server to update your task schedule? This is not great. What you can do is to keep track of what time should be scheduled, and when running, check whether the current time is in a certain range of the scheduled time (or already completed), otherwise stop the task.

The only thing I noticed is that if I set up a schedule for working after hours (if no actions are performed in IIS), then hangfire will not be able to call the task, and as soon as the first request is completed, the missed tasks will work. I overcome this limitation by defining a Windows task that calls IIS every 15 minutes to maintain the application pool in real time, and it worked well ...

The Hangfire documentation has a page on launching pending tasks that mentions what you need to change to post this.

Using Windows Task Scheduler doesn't seem like a good idea; it is not intended to perform special, short-lived tasks. You probably need the height to create tasks, and you probably need to define another scheduled task to clear the mountain of tasks that will exist after several dozen background tasks have been completed.

You are also right that using Windows Task Scheduler will make it difficult to move your application.