Questions about a Windows service that is mostly inactive

Question

I have a windows service designed to run 2 minutes work once a day. The remaining 23:58 days, he just sits around, looking beautiful.

My question is primarily related to downtime: is it better to use Timer.Tick or Timer.Tick ? Is there any difference between the resources they use?

Secondly, during this downtime, if someone disables the Windows service, do I need to interrupt these idle threads so that the program is closed, or is Shutdown processing it for me?

Third, am I barking the wrong tree using the Windows service? It would seem that it would be advisable to put the entry in the Windows task scheduler, but I could not find a way to do this using InstallShield, which we use to deploy our product. Any better ideas?

Answer 1

If you start a background thread using ThreadPool.QueueUserWorkItem, I think you could have Thread.Sleep there, and when you close the service, you won’t have to do anything with it. I think that Timer Tick will automatically create a thread for you when it starts to tick, so you will have to do even less if you used it (out of two timer timers, I think you will agree that you want to achieve better, better choice )

It definitely looks like what would be better done by the planner, as you say. I don’t know if you can do it directly in InstallShield, but perhaps you could create a small console application that you run from the installer, which, based on a command line argument, either talks to the Windows GUI - http: // msdn.microsoft.com/enus/library/windows/desktop/aa383614(v=vs.85).aspx to register yourself or complete the task that you want to achieve (i.e. -install - configure it in the schedule, no arguments don't do what you need to do once a day).

I think this is a C ++ API, so you can do a little p / invoke or, better, just have some managed C ++ in the libaray class and reference it using the C # console application.

Answer 2

FWIW, InstallShield does not have its own capabilities for defining scheduled tasks, but supports VBScript, C ++, and custom InstallScript actions. All of these options support calling COM Automation Interfaces, and Microsoft provides a task scheduler through a series of task scheduler objects.

Task Scheduler Reference

CPU activity aside, a Windows service running all the time also consumes memory. In fact, every version of Windows has fewer services.

Why Windows 8 uses a lot less memory than Windows 7

Answer 3

I would use Timer.Tick . Thread.Sleep blocks the thread, and you cannot terminate the thread nicely when you turn off the service.

Answer 4

I would recommend the Windows service as you simply duplicate its functionality otherwise.

If InstallShield does not support adding to the task scheduler, can you install InstallShield to run a batch script or small .net application after installation to add it to the task scheduler?

Answer 5

While your planning requirements are very simple (as they currently are), I think the service approach is great.

Personally, I don't like the window scheduler because I find it unstable and annoying to support (though I have not tried the new version in Windows 2008).

I would probably go with a scheduling library like Quartz.Net if I were to create an application with more complex schedule requirements.

Answer 6

If you don’t have a scheduling application like autosys, the Windows service should be the best option, also I see no harm in thread.sleep, it is designed to pause the application and use 0% cpu