Reputation: 3247
I want to make a windows service worker, as described in this walkthrough: https://learn.microsoft.com/en-us/dotnet/core/extensions/windows-service.
I also want the user to see a tray icon to manipulate the service. To do this, I will create a second executable which runs in the user context and communicates with the service.
How should the app communicate with the service to perform things like checking the service status, restarting the service, etc.?
Apparently this could be done with .NET Framework by using a ServiceController in a user-run app to talk to the service (which I guess used to be a ServiceBase instead of a BackgroundService).
What is the equivalent "ServiceController" class, when using the newer BackgroundService/service worker model of .NET Core? Does ServiceController still work?
Upvotes: 2
Views: 3640
Reputation: 1619
A typical pattern is to have two apps. You can't really do this. as services run in a different window station than the logged in user, so you can't have a system tray icon for those users. This is from the Microsoft docs https://learn.microsoft.com/en-us/dotnet/framework/windows-services/introduction-to-windows-service-applications:
Windows Service applications run in a different window station than the interactive station of the logged-on user. A window station is a secure object that contains a Clipboard, a set of global atoms, and a group of desktop objects. Because the station of the Windows service is not an interactive station, dialog boxes raised from within a Windows service application will not be seen and may cause your program to stop responding. Similarly, error messages should be logged in the Windows event log rather than raised in the user interface.
The Windows service classes supported by the .NET Framework do not support interaction with interactive stations, that is, the logged-on user. The .NET Framework also does not include classes that represent stations and desktops. If your Windows service must interact with other stations, you will need to access the unmanaged Windows API. For more information, see the Windows SDK documentation.
The interaction of the Windows service with the user or other stations must be carefully designed to include scenarios such as there being no logged on user, or the user having an unexpected set of desktop objects. In some cases, it may be more appropriate to write a Windows application that runs under the control of the user.
Here are a couple of links about how to write to the system tray I found on internet and other post. You'll need another application to interface with the service, since the service can't directly have an icon in the system tray for windows..
How can I make a .NET Windows Forms application that only runs in the System Tray?
and
http://msdotnetsupport.blogspot.com/2008/02/cnet-application-windows-system-tray.html
Way to communicate with the windows service could be as follows:
-Socket communications (TCP, HTTP, Websocket or other):
-Named pipes: this is a good option for communication between processes running in the same node: https://msdn.microsoft.com/en-us/library/windows/desktop/aa365590(v=vs.85).aspx
-shared memory: this is the fastest
Other higher level, library like SignalR which uses sockets
Upvotes: 2