views:

1365

answers:

3

When should I go for a Windows Service and when should I go for a "Background Application" that runs in the notification area?

If I'm not wrong, my design decision would be, any app that needs to be running before the user logins to the computer should be a service. For everything else use a background app. Is my decision right?

Moreover, if I need "admin privileges" for my background app, I would escalate using a manifest. Are there any other specific advantage of running as a service?

+3  A: 

I believe your decision is almost right, however, I would add one more condition. Take for example the mysqld service (you have a choice in this case, but most people run it as a service). It's ran as a service because you want to access the service anytime through potentially multiple applications. It's important that it is responsive to all applications calling upon it, and itself, is not much of anything, other than waiting to serve other applications.

Just something I would consider as well when making my decision.

Sev
+3  A: 

I would design an application as a service if the applcation has a critical purpose and should never (or rarely) be closed. Windows services provide good crash-recovery options, good notifications (see the recovery tab in service property).

Also a good reason to use services is because they can run under any user ( so if you deploy them on a server that you remote to, you can safely log out after starting the service without worring that the application will close too).

I also design services in combination with a desktop application that can interact with the service and can be used to monitor or reconfigure the service while running. This way you can have all the benefits of a tray application, in your service.

However, you should not abuse using services and only use them, as I said, for cirtical applications.

AlexDrenea
+7  A: 

My general rules of thumb are as follows

  • If it needs to always run, it's a service.
  • If it needs to be run under a particular user account, Network Service, Local System, generally it's a service (or a COM+ application)
  • If the user needs some control over it, it's generally a notification area application.
  • If it needs to notify the user of something, it's a notification area application

The fun comes when you have the need to run something as a system account, but also interact with it. IIS is a good example of this, it's a service, but the administration is an application - it needs to be running at the startup, it needs access to particular things a user can't normal access (c:\inetpub), but the user needs to be able to start, stop and configure it.

blowdart
The fun comes when you have the need to run something as a system account, but also interact with it. This is my problem actually... I'm trying to dump log info from my service and parse them on my windows app that notifies the user... not sure whether my design is right...
Mugunth Kumar
Ah well there's a multitude of ways to do that, my own preference, because I use them so much, is to have the service host a WCF endpoint and control it that way.
blowdart
I would like to add to the list:If it needs to run without a user logged in to the computer, it's a service.
Kristoffer L