Windows Service Plus GUI/C#

Question

Я видел некоторые приложения, которые запускаются как служба Windows, но все же может предоставить графический интерфейс, который позволяет пользователю видеть, что происходит на самом деле.

Например, у нас есть служба Windows, которая создает отчеты. Есть несколько статистических данных, которые хотели бы видеть администраторы, например, сколько отчетов поставлено в очередь, сколько используется барабан, время сборки и т. Д.

Что мы хотели бы сделать, это обеспечить способ для администратора, чтобы увидеть это - например, приложение, которое может подключиться к службе окна, чтобы собирать и отображать эту информацию ... или, возможно, способ, которым само приложение может предоставить свой собственный графический интерфейс и отображать его по запросу. Прямо сейчас, единственное, что приложение создает, создает файл журнала.

Есть ли способ сделать это?

Answer 1

Несколько.

1. Имейте какой-то компонент, который подключается к вашему сервису Windows и отправляет информацию в другое приложение через удаленный доступ. Если у вас есть контейнер IoC, умное использование декораторов может сделать это
2. Используйте служебную шину, MSMQ, WCF, Growl или что-то в этом роде для передачи интересующей информации. Приложения просто должны знать, как подключиться.
3. Expose конечная точка HTTP или что-то там, где кто-то может подключаться и загружать информацию о службе Windows
4. Или просто создайте одностраничное приложение WinForms, которое каждый раз читает файл журнала часто и показывает интересные результаты.

(Обратите внимание, что последний на сегодняшний день самый простой. - намек намек, что делать)

Answer 2

В идеале услуги полностью отделены от пользовательского интерфейса по многим причинам, в которые я не попаду.

Однако вы можете использовать какой-либо IPC для просмотра такой информации. Моя рекомендация заключалась бы в том, чтобы использовать Remoting для запроса данных, необходимых от службы, и затем создавать любые отчеты или графики по мере необходимости в отдельном приложении.

Answer 3

услуги не могут совершать вызовы интерфейса API (за исключением одной конкретной формы окна сообщения). Таким образом, службы, которые, как представляется, имеют интерфейс wser, фактически являются двумя процессами. Сервисный процесс связывается со стандартным APP Windows, используя какой-то проприетарный backchannel. Может быть именованным каналом, сокетом или куском именованной разделяемой памяти.