C# Пропускание через IPC

Question

Хорошо, короткая короткая история У меня есть служба Windows, которая обрабатывает Win32_VolumeChangeEvent и регистрирует поступления USB-дисков в журнал событий и в базу данных SQL. Дополнительным компонентом этого является скрытый пользовательский интерфейс (WinForms), который загружается в сеансе пользователя при входе в систему - это всплывающее окно с напоминанием пользователям политики компании о USB-ключах и т. Д. AFAIK, это был лучший способ, поскольку услуги не могут более продолжительный запуск в интерактивном режиме.

Anywho ... архитектурно, v1 этой маленькой вещи работал с компонентом пользовательского интерфейса, обрабатывающим сообщения WndProc для вставки устройства, затем передавал идентификатор устройства через IPC (именованные каналы) службе, которая обрабатывала бы методы WMI/запись в журнале событий (поскольку не все пользователи имеют права локального администратора). Это имело недостаток элемента интерфейса, который был убит процессом и больше не обнаруживал вставки устройства.

Итак, текущая версия заключается в том, что служба обрабатывает Win32_VolumeChangeEvents и получает необходимые данные с устройства, а затем записывается в EventLog и SQL. Все отлично и отлично работает. Кроме того, сейчас мне интересно, как лучше всего запустить интерфейс для отображения всплывающего окна.

Я исследовал Google и здесь, ища идеи о событиях по IPC, поэтому я могу просто подписаться на событие из компонента пользовательского интерфейса и запустить его внутри службы, но я не нахожу много, что выпрыгивает как полезный. Я также ограничен .net2, поэтому WCF не работает (хотя я не боюсь p/invoke, если вы хотите пойти таким образом).

So. Как бы вы это сделали? Ссылки, мысли, промахи, псевдокод, фактический код ... все оценили. Я пытаюсь придерживаться того, что, по моему мнению, является лучшей практикой, хотя я также думаю, что программирование - это немного форма искусства, и моя лучшая практика может быть чужой ужасной историей.

Так что, что бы вы сделали? Дайте мне знать, если мне нужно уточнить :)

Answer 1

В старые добрые времена программирования Windows API мы иногда использовали RegisterWindowMessage для регистрации уникального идентификатора сообщения, которое (предположительно) только в нашем окне знало, как обращаться. Мы могли бы затем запустить это окно из другого приложения, вызвав PostMessage с дескриптором окна HWND_BROADCAST, а параметр msg - это уникальное значение сообщения. Это отлично работает, если все, что вы хотите разделить между процессами, может вписываться в два значения DWORD (wparam и lparam). Совместное использование большего количества данных может быть выполнено, если вы выделяете глобальную память и передаете ссылку в качестве одного из параметров.

Это должно быть возможно с помощью .NET. Конечно, нет проблем с вызовом PostMessage. Что касается обработки сообщения в коде пользовательского интерфейса, вам необходимо переопределить форму WndProc. См. Пример How do I send/receive windows messages between VB6 and c#?.

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

Вы можете пойти по названному маршруту событий и использовать разделяемую память (файл с отображением памяти) для совместного использования состояния.

Или вы можете настроить розетки, названные трубы, TcpListener/TcpClient или даже UdpClient. Все должны работать с разной степенью сложности и/или надежностью.

Answer 2

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

Обновление: после повторного чтения вопроса, я думаю, что, возможно, ваш пользовательский интерфейс не получает сообщений Windows, поэтому вам нужен другой механизм. Почему бы не создать объект синхронизации Semaphore в службе и ждать его в процессе пользовательского интерфейса (в отдельном потоке)?