Is there any things to take care of when running your process or executable as service.Things like silent logging.Critical error reporting scenarios? etc? How do you handle it ?
views:
115answers:
5Don't show any message boxes / dialogs.
Be aware that your app will usually not run under the same account as a logged-in user. So if a user is able to access some file/directory, this does not mean that the service can do as well.
For critical error reporting, you are constrained to using the standard Service settings (in the properties of the installed service), or doing something yourself. This could be as simple a log file that logs unexpected errors (by using AppDomain.UnhandledException to catch and log them), using the Windows event log to log similar info, or having another process watch the service for errors (ie. the service stopping) and alerting someone.
Microsoft has an article entitled "Introduction to Windows Service Applications" that is a good general introduction to making services in .Net.
Some other things about developing Windows services from my experience:
- A Windows service is allowed about 30 seconds to start. After that, Windows will report it as not having started correctly. This means that you need to ensure that your
OnStart
method of the service kicks off a new thread to run the service and then returns. - Don't expect any user interaction (ie. message boxes, confirmations) because the service runs "headless" (ie. without a UI), so you cannot expect a user to interact with it.
- Check the account that the service will run as to ensure that you are not running it as a user with unnecessarily high security privileges.
- Make extensive use of logging (eg. log4net) so that you can see what the service is doing during runtime, as well as being able to diagnose any errors (by logging stack traces).
- Make sure you use the correct version of InstallUtil (ie. 32 or 64 bit) to install the service with. Even better, let the service install itself using the ManagedInstallerClass.InstallHelper.
Make sure you have some form of alert system to inform you if the service falls over e.g. send an email to yourself or some mailbox.
- Be sure to use a tracing/logging API to have diagnostic information. Eventlog, log files, database, whatever... Just have the troubleshooting info somewhere.
- Trace/Log early and often. Nothing is more frustrating then having to make a code change which is just to add diagnostic tracing.
- Be cognizant of memory leaking. When writing an app that will be restarted everyday or runs as a scheduled task, sometimes we get a bit lazy. Remember this service needs to clean up after itself thoroughly. Make proper use of the using clause with all IDisposables.
- Do not forget the volatile keyword on your STOP variable! My God this gets me every time.
If it makes sense, don't forget to implement the Pause event. Handle all exceptions so it fails gracefully when it fails.