In general, a Windows Service cannot work with UI directly, in particular, it cannot interact with the notification area of the system tray. The reason is apparent: the Windows Service keeps running when the user logs off or nobody is logged on, when the graphical user environment is not available.
The problem is solvable though. You need to write a separate application which should be a windowed interactive application shown in the notification area of the system tray. Your Windows Service should provide communication channels, so your interactive application could connect the service for data exchange and getting notifications.
As both applications are on the same machine, the problem can be solved based on named pipe communication. Your Windows Service can implement named pipe service. For example of such service, please see this code sample:
http://msdn.microsoft.com/en-us/library/aa365603(v=vs.85).aspx[
^].
If you need your Windows Service to send event notifications, you probably need more complex schema with two separate channels to provide inversion of control (
http://en.wikipedia.org/wiki/Inversion_of_control[
^]) and publisher-subscriber service.
Your interactive application can connect to first channel and subscribe for notification; when it is connected, the Windows Service should send notifications to the other channel until your interactive application is disconnected or simply closed. You Service code should be able to handle such non-graceful disconnection by handling exception which should result in discontinued subscription.
I suggest you develop and test this mechanism on prototype using two interactive applications first, before embedding it to your Service. Optionally, you can use TCP sockets to implement the same mechanism if subscription and notification.
—SA