MSDN:
"
a.. 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.
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.
"
So:
1. Why a service? The service is supposed to be a completely automatic piece
of code that services clients. It wrotes events in event log and is
started/stopped via service manager. If you need user interaction why didn't
you design a simple Windows application?
2. Anyhow, if you want to manage the service locally/remotely via a
customised UI, and to issue more than start/stop functionality you have to
find a common repository (message queues, files or whatever) for the
messages send by a Windows app (the UI) that produces requests for the
service, and the service that consumes them.
