C#: GUI для отображения сообщений в реальном времени из службы Windows
Я написал службу windows C#, которая может записывать сообщения в пользовательский журнал событий или в любое количество файлов. Все эти сообщения отмечены некоторым приоритетом (так, например, в EventLog сохраняются только ошибки и предупреждения, но при желании в файл можно сохранить гораздо больше).
что я хотел бы сделать сейчас, это создать графический интерфейс, который может прослушивать эти сообщения и отображать их в режиме реального времени. Позволяет пользователю просматривать текущие сообщения (независимо от их желаемого приоритета уровня), без необходимости хранить все в файл. Я предполагаю, что это отдельная программа с какой-то формой подключения к службе, но я не уверен, с чего начать.
Это моя первая настоящая служба windows, поэтому мне кажется, что мне не хватает некоторых ключевых слов для выяснения того, как это сделать... Есть ли примеры кода, учебные пособия, ссылки и т. д. как это сделать?
обновление
Много полезных ответов, я люблю, когда есть много способов решить проблему! Я думаю, что я собираюсь реализовать самостоятельное решение на основе WCF. Я все еще очень мало знаю о деталях, поскольку я пытаюсь узнать о WCF (я считаю, что это будет очень полезно для меня в других проектах)... но до сих пор я нашел видео здесь чтобы быть наиболее полезным в качестве вступления how-to.
7 ответов
то, что вы можете сделать, это иметь службу 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
на самом деле очень здорово, что вы можете иметь несколько приложений, тоже слушал этот путь. Так что вы можете отобразить его на экране, и есть другое приложение, журнал и т. д. без двух внешних приложений, знающих что-либо друг о друге.
Я знаю, что это уже упоминалось, но используйте Windows Communication Foundation (WCF). В частности, используйте Опубликовать-Подписаться Framework разработчик Юваль Лоуи, автор Программирование служб WCF. Подробности описаны в это отличная статья MSDN, а исходный код доступен бесплатно по адресу Лоуи.
аккуратная вещь об этой структуре заключается в том, что она развязывает издатель, например, ваш сервис Windows, от любых подписчиков, например, ваш GUI. Издатель "публикует" события, представляющие интерес для сервиса Pub/Sub, который всегда доступен. С точки зрения издателя, не имеет значения, есть ли подписчики или нет. Служба Pub / Sub заботится о маршрутизации событий всем зарегистрированным абонентам. Таким образом, ваша служба Windows публикует события по мере их возникновения, ваш GUI будет подписываться/отписываться на службу Pub/Sub, когда она нагрузки / выходы, и Служба Pub/Sub уведомит ваш GUI по мере возникновения событий.
Я использовал эту настройку в своем проекте, и она работает очень хорошо.
Я на самом деле используется BitFactory Logger который имеет регистратор сокета, который вы можете использовать для этой цели.
то, что вы описываете,-это межпроцессное общение, которое может стать беспорядочным.
самый простой и элегантный, но, вероятно, наименее реактивный-это запись записей службы в виде небольших текстовых файлов (или добавление в журнал), а также использование GUI FileSystemWatcher для обнаружения новых файлов или обновлений в файле журнала и чтения файла. Вы должны убедиться, что служба открывает файл для добавления "общим" способом, позволяя доступ только для чтения во время записи. Иначе, вы заблокируете тот или иной процесс, вероятно, вызывая потерянные сообщения.
процессы могут взаимодействовать через некоторые встроенные конвейеры. если служба записывает сообщения в канал StandardOutput, GUI может удаленно подключать прослушиватель и получать события при записи сообщений. Это, вероятно, самый элегантный способ сделать то, что вы хотите. Исследуйте класс процесса, особенно событие OutputDataReceived. Вам придется искать процесс из вашего GUI по некоторым уникальным идентификация информации с помощью GetProcess ().
вам нужно искать "синхронизацию"и" межпроцессную связь". В вашем случае служба будет использовать глобальное событие или семафор, чтобы сигнализировать о наличии данных, а процесс GUI будет проверять состояние события/семафора и читать обновления из журнала событий или из файла.
существуют более сложные сценарии, но вышеприведенное является хорошей отправной точкой.
шаблон наблюдатель!
возможно, делегат для всех наблюдаемых моделей, которые вы можете подключить к своей службе?