What is the benefit of developing the application as a windows service?
On the top of my head:
- You can control the user (and the rights associated with this user account) which starts the process
- an Automatically started process means the desktop need to be on, not user logged, for the service to run
- a policy on failure can be defined (try to restart n times run a specific program if fails)
- a dependency can be defined (if you depend on other sevices)
- you can wrap your scrip in an invisible windows
- you can easily start/stop/restart the script (
net start <scriptname>)
Scheduled console app vs Windows service? When is it appropriate to use each
回答1
For any scheduled task, I would usually recommend a Windows Service, for the following reasons:
- A Windows Service will run even if a user is not logged into the PC (will run even if the server is sitting at the login prompt) (***Note - this may depend on the version of Windows you are running).
- A service can run as high-authority accounts such as Network Service or Local System, or a User - they have more configurability in that regard
- A service also comes built in with options for starting, stopping, restarting, and pausing while running (sometimes)
- You can also set up failure conditions for services, like if it fails have it auto-restart
As far as other examples of applications that can be windows services, a lot of times they are useful for applications such as remoting - you can have a service run a remoting server that clients connect to. Obviously very useful for data processing tasks that you want to run in the background as well, or processes where you want to send an email on certain conditions, etc.
In general I‘ve always found scheduled tasks to be much more fragile and unreliable. And unless you have them log properly, often harder to debug.
In reference to the bug with the Timer - if you read the bug report on MS‘s site, you can see that it is caused when you call "Stop" inside the Timer_Elapsed event. The answer to this is simple - don‘t call stop. Instead, wrap the whole thing in a check for a "IsRunning" boolean and only run if IsRunning is false. Even if there wasn‘t an issue with the timer, you need to do this anyway because the timer might re-fire during your execution if your execution takes longer than your timer interval.
Anyway, I still think using scheduled tasks is a weak solution and gives me flashbacks of Windows 95.
回答2
For single or narrow purpose applications run on a schedule, running a console application via the Task Scheduler is almost always the correct design.
For long running or complex tasks that may need interaction such as manual start, stop, pausing, continuing, etc. then, in general, a Windows Service is the better option.
Scheduled tasks can be run under any account and do not need a user logged in just like Services. For single purpose tasks such as those you propose external control of the task is usually irrelevant so you have no need of the controllability of a Service.
A big factor also is the Task Scheduler is a very robust and flexible event based scheduler. It is extremely unlikely that you could write a scheduler that was more robust and could handle the vagaries of time and trigger based scheduling. In fact there are a number of questions about using timers for scheduling tasks in services on this site and it is remarkable the number of answers (including some of the ‘correct‘ answers) that are poor quality or outright incorrect.
EDIT: It‘s also interesting to note that Microsoft policy is shifting away from using services for task based actions. If you check Vista, Win2K8 and Win7 you will notice a growing list of special purpose scheduled tasks that perform system maintenance and many system services.
What is the benefit of developing the application as a windows service?