Сервис и взаимодействие с программой

Question

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

Поскольку служба и программа будут работать в разных процессах, обработанных разными пользователями, как сообщить службе, что параметры изменились?

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

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

В то время как первый вариант легче написать второй, кажется, лучше.

Любые предложения или любые другие альтернативы?

Спасибо.

Answer 1

У меня был небольшой проект, который вроде бы сделал оба. Используя IPC, он передал настройки клиенту, где клиент изменил настройки и отправил их обратно. Когда служба получила новые настройки, она сохранила настройки с помощью ConfigurationManager и соответствующим образом обновила их. Мы прилагали огромные усилия, чтобы разрешить перенастройку службы без необходимости перезапуска.

Update Чтобы выполнить запрос Джорджи для получения дополнительной информации:

Мы использовали Remoting, но вы могли бы и, вероятно, следует использовать WCF. Положительным побочным эффектом является то, что вы можете изменить привязку к маршрутизируемому IP-адресу и позволить удаленным пользователям настраивать службу, если хотите. Это добавляет соображения безопасности, но вы можете справиться с этим в WCF и удаляться по своему усмотрению.

Я считаю, что мы не могли просто отправить ConfigurationElements или разделы по сервису, поэтому вместо этого мы просто создали простой класс Settings и передали его туда и обратно. На стороне обслуживания мы имели службу, переводим класс Settings в обновленный ConfigurationElement и сохраняем конфигурацию с помощью ConfigurationManager. Работала хорошо для нас, но я мог видеть, что это огромная боль, если у вас много настраиваемых элементов или сложная схема конфигурации. Если он начинает усложняться, вы можете просто использовать свой собственный API конфигурации, чтобы иметь полный контроль над типами и жизненным циклом.

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

Answer 2

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

Но ExecuteCommand довольно чистый и хорошо.

Answer 3

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

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