У меня был небольшой проект, который вроде как сделал и то, и другое. Используя IPC, он передал настройки клиенту, где клиент изменил настройки и отправил их обратно. Когда служба получила новые настройки, она сохранила настройки с помощью ConfigurationManager и обновила себя соответствующим образом. Мы приложили огромные усилия, чтобы переконфигурировать сервис без перезапуска.
Обновление Чтобы выполнить запрос Giorgi для получения дополнительной информации:
Мы использовали Remoting, но вы могли и, вероятно, должны использовать WCF. Положительным побочным эффектом является то, что вы можете изменить привязку к маршрутизируемому IP-адресу и позволить удаленным пользователям настраивать службу, если хотите. Это добавляет соображения безопасности, но вы можете справиться с этим в WCF и удаленном взаимодействии по своему усмотрению.
Я считаю, что мы не могли просто отправить ConfigurationElements или разделы через службу, поэтому вместо этого мы просто создали простой класс настроек и передавали его туда и обратно. Что касается службы, то нам пришлось перевести класс Settings в обновленный элемент ConfigurationElement и сохранить конфигурацию, используя ConfigurationManager. У нас это хорошо работало, но я мог видеть, что это очень тяжело, если у вас много настраиваемых элементов или сложной схемы конфигурации. Если это становится все сложнее, вы можете просто использовать свой собственный API конфигурации, чтобы иметь полный контроль над типами и жизненным циклом.
Наконец, вам нужно убедиться, что часть службы, которая выполняет реальную работу, проверяет изменения конфигурации через регулярные промежутки времени, когда ее можно безопасно перенастроить, и что на обработку, которая уже выполнялась при запуске конфигурации, изменения не повлияют. Простой способ сделать это - остановить обработку службы, когда он получает сигнал от клиента, и возобновить работу, когда клиент говорит, что это сделано.