Is an application with "system tray" icon OK for a continually running scheduler, or should I create a Windows service?

Question

Requirement - I have a periodic task I want to run in a Windows environment for my application. It will have a simple interface that allow some basic configuration (for example, URLs and how often to run it). I want it to run every X hours (configurable) when the machine is running.

Question - Do I just create an application with a system tray presence for this? Or should I be creating a service that has a separate UI that hooks into it.

BY THE WAY - I'm a beginner C# developing using Visual Studio Express, keep in mind. Also if you could give a quick overview of the design of what you recommend that would be great for someone new to this (for example, if you suggest a service, does this mean you really need one application for the service, and another application that has a UI that does the configuration for the service?)

Answer 1

Building a service with UI hooks sounds overcomplicated for what you are trying to achieve. A system tray application sounds right for this, I would definately go that way.

Answer 2

It depends on the size of the application. If it's quite small leave it in the tray if you allready did't wrote this solution

Answer 3

If you are looking for something simple, consider using windows scheduler to schedule the jobs, a shim to run the jobs after scheduler starts it and a config utility that allows for setup. But I would have to reccomend that you evaluate how flexible and how reliable the jobs need to be. If it is ok if the jobs don't run consistently, then a user application in the notification area would be sufficient. But if the job is crucial to a function of business or some other operation, I would go with scheduler or the service. If you do a service, you would have a config utility and a service that would communicate via some means. You could have the config utility write to a file (perhaps an XML config file) to update config, then just restart the service to update the configuration.

Answer 4

If you need it to run ever X hours the machine is running, even if no-one is logged on, then either a scheduled task or a service might be right.

What will the service be doing in the "dead time" between downloads? If the answer is nothing, then scheduled task is almost certainly right. You'd want to create a console application to run as the scheduled task.

It would help if we knew more about what, if any, User Interface is being employed.

Answer 5

If it needs to run when no user is logged on, you need a service. If it's a user application that doesn't need to be running when all users are logged off, then a system tray application would be OK.

Answer 6

I would create the main processing as a Windows Service, otherwise if you machine reboots and you dont log on, you wont have the process started to sit in the tray (and therefore your process wont run). Alternativly create a dummy console app or silar and run that through the windows scheduler. Also with a windows service, if it crashes you can configure it to automatically restart which you cant (easily) do with a windows applicaition sitting in the tray.

I would then have a second application with a GUI that writes the configuration to a common configuration file that is used by both applications.

Answer 7

I developed such an application last year. A simple windows forms application that has just a tray icon. The user is able to configure the application through a context menu (shown when the user right-clicks the tray icon). I used a timer that fires the Elapsed event...

If this application will be the only doing some tasks on timely basis then go just with a windows forms app with a tray icon. But if there will be several possible application that can send input and trigger some activity then you should consider moving the common functionality in a windows service. You should also consider using a windows service if the application will be running on a machine with Terminal services (multiple users -> multiple instances of your app).

I wouldn't use a Scheduled Task! It's less user friendly...

-Pavel Nikolov