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?
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.
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.
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.
Related
I'm trying to get started with an application that definitely requires some GUI for configuration management and the application has to poll a web service about every hour (to check for updates/messages) or so. Also, the application is expected to run constantly in the background/system tray.
I'm looking for some guidance on the overall architecture for this application design. Can this be a straight up WPF app or would it be better it is a windows service because of the polling and because it is expected for the application to be running all the time? Do you guys have any suggestions?
Firstly, services tend not to have a GUI. They can, but it's not advised.
What I would do, is have two applications. The service itself which performs the monitoring in question, and a user-interface application (that runs on startup), and provides an interface to the service. Communication between the two can be handled in a variety of ways.
The advantage to this is, your service will run even if there isn't a user logged on, and the UI part is present only when a user is on.
To allow for your GUI to communicate with the Windows Service you can expose WCF services on the Windows Service to provide the operations you need (e.g. Start, Stop, GetStatus, etc.).
See this article on MSDN for a starting point: http://msdn.microsoft.com/en-us/library/ms733069.aspx
I have a WCF service hosted in a Windows service.
This service the WCF have one metohd and in this method I have one important line :
Process Browser = Process.Start("iexplore.exe", hostUrl);
I install Windows service as local system, but when I'm trying to invoke that method, everything seems to execute, except that one important line... and IE didn't open.
I would like to add that the method itself is not in the service itself but in one of the service dll reference
Any idea why?
http://social.msdn.microsoft.com/forums/en-US/netfxbcl/thread/63a7d1ec-7077-489a-a250-f7422f04317b
" in order to get the service to actually show the UI, you'd have to set the service in Computer Management to allow it to interact with the desktop. In the services window in computer management, go to the properties of your service, and on the Log On tab, check "Allow service to interact with desktop" "
Since Windows Vista MS has been adding lots of security-related changed esp. in the area what Windows Services can/can't do. Anything "desktop-like" (printing, accessing network shares, using Office Interop etc.) is harder and harder to get working.
You should rethink your design since IMHO any "server-like process" (for example a WCF service) can be accessed in parallel by multiple requests and thus should NOT use processes which are NOT designed for this type of interaction... what happens if your webservice starts multiple IE instances that way ? Will IE behave as you need/expect it ?
IF you really really MUST do it this way you should have
a normal desktop process hosting the WCF service
OR
two processes, one your Windows Service and one running as a normal desktop process dealing with IE... these two process communicate via IPC
Under what user is the service running? Try running it under the currently logged in user, with privileges to interact with the desktop and see if that helps.
In general, its not a great idea to have services launching GUI processes. For example, what if no one is logged on. What if many people are logged on? Should it open in all sessions... etc. Have you considered exposing a simple (e.g. Net.NamedPipes) endpoint on your service, and writing a small client UI to interact with it?
I want to load a form in OnStart() method in my windows service; here is my code. It is not working. Can you please provide any help ?
protected override void OnStart(string[] args)
{
Form1 fr = new Form1();
fr.Show();
}
You can't use services that way. Services can't interact with desktop directly, because they run in another WindowsStation from the logged in users session. You need to create another application that will communicate with your service.
How to make communication you can read on MSDN and in this example. Some ideas also described already on StackOverflow.
Services run in a different window station and desktop to any interactive user. Even if the form is loaded successfully nobody will be able to see it.
You can set the "Allow service to interact with desktop" service option which allows a service to share the console's window station. However, this is a really bad idea. It opens up security holes and a host of other problems. E.g. what happens if there is more than one user logged in? Or if you're running terminal services?
A more conventional design is to have a client application handling the UI and talking to the service running in the background.
GUI requires Single-Threaded Apartment threading model. Forms require a message pump (like the one started by Application.Run).
A service is definitely not designed to show GUI (even interactive services are considered bad practice), it can be controlled from a GUI, though.
For a service to display a window it has to be marked as "Allow interaction with desktop". This can be done by the service installer or on the property page for that service.
That's not enough to get the window to display reliably, though. In practice you will have to determine if there is a user currently logged in and get their desktop. This is not a trivial undertaking and can be a source of security issues. If there is no one currently logged in, you are out of luck.
The best solution is to have a separate GUI app which talks to the service via some IPC mechanism.
I have created an SMS application in .NET.
I wanted that the application should run when the computer starts, even before the user logs in.
Just like the SQL Server.
You need to create your application as a Windows Service. The linked MSDN page will provide full details.
Microsoft Windows services, formerly known as NT services, enable you to create long-running executable applications that run in their own Windows sessions. These services can be automatically started when the computer boots, can be paused and restarted, and do not show any user interface. These features make services ideal for use on a server or whenever you need long-running functionality that does not interfere with other users who are working on the same computer. You can also run services in the security context of a specific user account that is different from the logged-on user or the default computer account. For more information about services and Windows sessions, see the About Services section in the Platform SDK documentation in the MSDN Library.
You could consider making it a Windows Service.
You'll have to write a service. Start here...
Wrap your application in a Windows Service, using the .NET System.ServiceProcess namespace.
The System.ServiceProcess namespace provides classes that allow you to implement, install, and control Windows service applications. Services are long-running executables that run without a user interface. Implementing a service involves inheriting from the ServiceBase class and defining specific behavior to process when start, stop, pause, and continue commands are passed in, as well as custom behavior and actions to take when the system shuts down.
Use ServiceEx to make a service from your executable: http://serviceex.com/ , just write one INI file, you can choose if application's window is hidden or showed etc.
At my company we have a product which pretty much interacts with everything you can imagine... registry, databases, devices, etc... it is composed of many parts but the entire application is launched by a single executable (start.exe) which is responsbile for launching everything else - this is all legacy code and run under a USER account.
Currently this is launched as a STARTUP item (or by double-clicking on the desktop icon) in Windows, meaning when the user logins into the USER account the application (start.exe) automatically kicks off, under this account it has all the permissions it needs to run and everything has been fine for years...
Now comes the change - I have written a service (Serv.exe) that is running as LocalSystem - this service is responsible for updating the various software components of our product and works as follows:
- when the product detects an update it signals the LocalSystem service (Serv.exe) and then terminates itself
- Serv.exe will then perform all the updating
Now, after everything is done, the product (via start.exe) needs to be launched again automatically ... and this is where I need some advice ... what is the best way to restart the product (start.exe)?
Right now I use the LocalSystem Service (Serv.exe) and impersonate the USER account as follows:
- CreateEnvironmentBlock for the USER
- CreateProcessAsUser(start.exe) as the USER with the corresponding EnvBlock
- DestroyEnvironmentBlock
But is this really 100% equivalent to double-clicking on the icon in the USER account context? I need to ensure that everything is identical when it is either launched on STARTUP of USER or by Impersonation from Serv.exe (LocalSystem) - is there a risk involved? Will I still have the same rights/abilities with all databases? registry? device interaction? etc..
By loading the EnvBlock I seem to get everything I need but ... is this not a good way to do it...?
Kind of hoping for some guidance and advice from the pro's out there ...
Any help or hints would be much appreciated.
Thanks,
Update: Here is a post named: Launching an interactive process from Windows Service in Windows Vista and later. Which is exactly what you are looking for. It starts with:
The first thing you should do about it is that; don't do it. There are many limitations and bad implications and restrictions involved.
So first test if your current solution works. That depend on what the process is doing. If it is not involving user interaction. Or manipulating the current user session. Then you don't need this complex solution. If you need it, than good luck!
Before update: Its not 100% equivalent. Except authorization there are, in windows, sessions and, in each session, there are desktops. The process that is lunched from the service will run on the service session and desktop ( if the service has it). Depending on what the start.exe does, it may be important or not.
Look at the SetTokenInformation function.
Instead of launching the application directly as a "startup item" you could start a "launcher.exe" that then would launch your application. The service could then signal "launcher.exe" that another instance of the application should start after an update. Using this method you can't use the service to update "launcher.exe", but this executable should be very simple and hopefully not require any updates. Using this method would avoid all the pitfalls of trying to start an interactive application from a service.