C #: графический интерфейс для отображения сообщений в реальном времени от службы Windows

Question

Я написал службу Windows для C #, которая может записывать сообщения в пользовательский EventLog или в любое количество файлов. Все эти сообщения помечены с некоторым приоритетом (например, в EventLog хранятся только ОШИБКИ и ПРЕДУПРЕЖДЕНИЯ, но при желании в файл можно сохранить гораздо больше).

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

Это мой первый настоящий сервис Windows, поэтому мне кажется, что мне не хватает некоторых ключевых слов, чтобы узнать, как это сделать ... Есть ли примеры кода, учебные пособия, ссылки и т. Д., Как сделать что-то подобное? 1005 *

UPDATE
Много полезных ответов, я люблю, когда есть много способов решить проблему! Я думаю, что я собираюсь реализовать самодостаточное решение на основе WCF. Я все еще очень легок в деталях, поскольку я пытаюсь узнать о WCF (я полагаю, что это окажется весьма полезным для меня в других проектах) ... но пока я нашел видео здесь , чтобы быть наиболее полезным как вводное руководство.

Answer 1

То, что вы можете сделать, это сделать так, чтобы у службы Windows был способ регистрации для события (вы можете сделать это с помощью Windows Communication Foundation). Когда появляется ваша ошибка, она запускает это событие, и ваше приложение winforms будет уведомлено. Это называется дуплексный контракт:

http://social.msdn.microsoft.com/Forums/en-US/wcf/thread/0eb69998-0388-4731-913e-fb205528d374/

http://msdn.microsoft.com/en-us/library/ms731184.aspx

На самом деле действительно круто то, что вы можете прослушивать несколько приложений таким же образом. Таким образом, вы можете отобразить его на экране и сделать так, чтобы другое приложение регистрировало его и т. Д., При этом два внешних приложения ничего не знали друг о друге.

Answer 2

Я знаю, что это уже упоминалось, но используйте Windows Communication Foundation (WCF).В частности, используйте Среду публикации-подписки , разработанную Ювалом Лоуи , автором Программирование служб WCF .Подробности описаны в этой превосходной статье MSDN , а исходный код доступен бесплатно на сайте Лоуи .

Изюминка этого фреймворка в том, что он отделениздатель, например, ваша служба Windows, от любых подписчиков, например, от вашего GUI.Издатель «публикует» события, представляющие интерес для Pub / Sub Service, который всегда доступен.С точки зрения издателя, не имеет значения, есть подписчики или нет.Служба Pub / Sub обслуживает маршрутизацию событий для всех и всех зарегистрированных подписчиков.Таким образом, ваша служба Windows публикует события по мере их возникновения, графический интерфейс подписывается / отменяет подписку на службу публикации / подписки при ее загрузке / выходе, а служба публикации / подписки уведомляет ваш графический интерфейс о событиях.

Я использовал эту настройку в своем проекте, и она работает очень хорошо.

Answer 3

То, что вы описываете, - это межпроцессное взаимодействие, которое может стать беспорядочным.

Самый простой и элегантный, но, вероятно, наименее реактивный метод - это запись службы в виде небольших текстовых файлов (или добавленияв журнал), и пусть ваш графический интерфейс использует FileSystemWatcher для обнаружения новых файлов или обновлений в файле журнала и чтения файла.Вы должны убедиться, что служба открывает файл для добавления «общим» способом, предоставляя доступ только для чтения во время записи.В противном случае вы заблокируете один или другой процесс, что может привести к потере сообщений.

Процессы могут взаимодействовать через некоторые встроенные конвейеры.если ваша служба записывает сообщения в свой канал StandardOutput, графический интерфейс может удаленно подключить прослушиватель и получать события при записи сообщений.Это, вероятно, самый элегантный не файловый способ делать то, что вы хотите.Исследуйте класс Process, особенно событие OutputDataReceived.Вам нужно будет искать процесс в своем графическом интерфейсе с помощью уникальной идентифицирующей информации, используя GetProcess ().

Answer 4

Я на самом деле использовал BitFactory Logger , который имеет регистратор сокетов, который можно использовать для этой цели.

Answer 5

.NET удаленное взаимодействие по каналу IPC.

Answer 6

Шаблон наблюдателя!

Возможно, делегат на все наблюдаемые модели, которые вы можете подключить к своему сервису?

Answer 7

Вам нужно искать «синхронизация» и «межпроцессное взаимодействие».В вашем случае служба будет использовать глобальное событие или семафор, чтобы сигнализировать о наличии данных, а процесс GUI будет проверять состояние события / семафора и считывать обновления из журнала событий или из файла.

Существуют более сложные сценарии, но вышесказанное является хорошей отправной точкой.