The timers you want to avoid are System.Web.UI.Timer and System.Windows.Forms.Timer. which are respectively for ASP applications and WinForms. Using those will cause the service to load an additional assembly which is not really needed for the type of application you are building.

Use System.Timers.Timer like the following example (also, make sure that you use a class level variable to prevent garbage collection, as stated in Tim Robinson’s answer):

If you choose System.Threading.Timer. you can use as follows:

Both examples comes from the MSDN pages.

Don’t use a service for this. Create a normal application and create a scheduled task to run it.

This is the commonly held best practice. Jon Galloway agrees with me. Or maybe its the other way around. Either way, the fact is that it is not best practices to create a windows service to perform an intermittent task run off a timer.

“If you’re writing a Windows Service that runs a timer, you should re-evaluate your solution.”

–Jon Galloway, ASP MVC community program manager, author, part time superhero

If your service is intended to run all day, then perhaps a service makes sense rather than a scheduled task. Or, having a service might simplify admin and logging for an infrastructure group that is not as savvy as the application team. However, questioning the assumption that a service is required is entirely valid, and these negatively ratings are undeserved. +1 to both. sfuqua Jul 30 ’10 at 14:22

@m.r. Nonsense. Scheduled tasks are a core part of the OS. Please keep your FUD to yourself. Will Dec 9 ’12 at 15:35

@M.R. I’;m not an evangelist, I’;m a realist. And reality has taught me that scheduled tasks aren’;t extremely buggy. It is, in fact, up to you as the person who made that claim to support it.

Otherwise, all you are doing is spreading fear, uncertainty and doubt. Will Dec 10 ’12 at 17:00

Either one should work OK. In fact, System.Threading.Timer uses System.Timers.Timer internally.

Having said that, it’s easy to misuse System.Timers.Timer. If you don’t store the Timer object in a variable somewhere, then it is liable to be garbage collected. If that happens, your timer will no longer fire. Call the Dispose method to stop the timer, or use the System.Threading.Timer class, which is a slightly nicer wrapper.

What problems have you seen so far?

I agree with previous comment that might be best to consider a different approach. My suggest would be write a console application and use the windows scheduler:

• Reduce plumbing code that replicates scheduler behaviour
• Provide greater flexibility in terms of scheduling behaviour (e.g. only run on weekends) with all scheduling logic abstracted from application code
• Utilise the command line arguments for parameters without having to setup configuration values in config files etc
• Far easier to debug/test during development
• Allow a support user to execute by invoking the console application directly (e.g. useful during support situations)

answered Oct 29 ’08 at 14:27

As already stated both System.Threading.Timer and System.Timers.Timer will work. The big difference between the two is that System.Threading.Timer is a wrapper arround the other one.

System.Threading.Timer will have more exception handling while System.Timers.Timer will swallow all the exceptions.

This gave me big problems in the past so I would always use ‘System.Threading.Timer’ and still handle your exceptions very well.

I know this thread is a little old but it came in handy for a specific scenario I had and I thought it worth while to note that there is another reason why System.Threading.Timer might be a good approach. When you have to periodically execute a Job that might take a long time and you want to ensure that the entire waiting period is used between jobs or if you don’t want the job to run again before the previous job has finished in the case where the job takes longer than the timer period. You could use the following:

answered Jun 26 ’15 at 10:57