Каков наилучший способ сохранить редактируемые пользователем настройки для службы Windows?

Question

Я занимаюсь разработкой приложения, которое будет реализовано как Служба Windows , и мне было интересно, как лучше всего справиться с различными настройками (на пользователя и уровень применения). Дело в том, что я не совсем знаком (пока) со всеми доступными опциями, поэтому в принципе я предпочитаю собственную System.Configuration .NET (ConfigurationManager.RefreshSection ("appSettings") кажется заманчивым) , хотя я все еще не могу обернуть голову вокруг всей картины, а именно, где хранится файл app.config для данной службы, и т. д.

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

Answer 1

Хммм ... «редактируемые пользователем» параметры конфигурации для службы Windows ...

Следует иметь в виду, что служба Windows работает в фоновом режиме, поэтому пользователи не могут напрямую взаимодействовать с ней. Чтобы обойти это, я создал отдельное интерфейсное приложение, которое взаимодействует со службой Windows с помощью WCF. Таким образом, параметры конфигурации, «редактируемые пользователем», сохраняются как часть параметров интерфейсного приложения, а не службы Windows. Настройки просто передаются в службу Windows с помощью серии сообщений WCF по мере их изменения пользователем.

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

EDIT:

В ответ на ваш комментарий WCF - это просто API обмена сообщениями. Сообщения обычно определяются как классы, украшенные атрибутами DataContract и DataMember. Атрибуты ServiceContract и OperationContract определяют интерфейс службы WCF. После того, как они определены, создание и размещение службы WCF внутри службы Windows становится простым. А если у вас Visual Studio 2008, создание прокси на стороне клиента совсем несложно, поскольку VS2008 может автоматизировать его для вас.

Как только все это будет сделано, ваше интерфейсное приложение просто создаст экземпляр экземпляра прокси на стороне клиента и вызовет методы этого прокси. Когда вызывается каждый метод, среда WCF заботится о сериализации и отправке сообщения службе WCF, чтобы она могла действовать. Затем он сериализует любой ответ, включая исключения, обратно в прокси. С точки зрения клиентской стороны, например, вашего клиентского приложения, вы просто вызвали функцию. Это красота WCF! Это очень похоже на программирование сокетов, за исключением того, что вам не нужно управлять соединениями. WCF позаботится обо всем, что вам нужно.

Конечно, все это предполагает, что вы можете по крайней мере использовать .NET 3.0. Если вы используете Visual Studio 2008, вы в хорошей форме. Вот несколько учебных пособий, которые помогут вам начать работу:

• Основы WCF
• Услуги WCF

Как только вы ознакомитесь с основными понятиями, я бы порекомендовал заглянуть на сайт Джувала Лоуи . Есть много бесплатных загрузок, связанных с WCF, которые я считаю очень полезными для просмотра, хотя они немного более продвинутые. Сначала поймите концепции WCF, прежде чем углубляться туда.

Опять же, весь смысл этого в том, чтобы помочь вашим пользователям настроить различные аспекты вашей службы Windows. Если вы не предоставите интерфейсный интерфейс для этого, я не уверен, как они это сделают, если не будут вручную манипулировать файлом app.config.

Надеюсь, это поможет.

Answer 2

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