Лучшая практика для хранения настроек для службы Windows.NET: Настройки Свойства службы, Сериализация,
Я работаю над службой Windows.NET, где я пытаюсь сохранить настройки, которые будут использоваться, когда сервис будет запущен и в то время как он работает. Я перерыл сообщения на ТАК и нашел, что использование Настроек в свойствах проекта является большим для использования с приложениями winforms и консолью. Однако Google и ТАК тих, когда он принадлежит хранению этих настроек с сервисом окон.
Кто-либо каждый знает, следует ли использовать эти настройки в сервисе.NET? В противном случае является Сериализация моим следующим лучшим выбором? Кто-либо имел практические применения для настроек в сервисе и нашел, что это лучше использовать определенный метод?
3 ответа
У меня возникли проблемы с использованием Settings.settings. Например, если вам нужно внести изменения во время выполнения, могут возникнуть проблемы с настройками, переопределенными теми, которые изначально были сохранены в файле settings.settings, в отличие от того, что показано , если должно быть сохранено для каждого приложение / web.config. Следовательно, я делаю все настройки прокси-сервера своей веб-службы «статическими» в свойствах и извлекаю их вручную из app / web.config с помощью вспомогательного метода и устанавливаю их программно. Это позволяет избежать любых проблем.
Пример возникшей у нас проблемы: я направил свою машину разработки на веб-службу на тестовом сервере, чтобы протестировать код, который использовал веб-службу. Когда код был перемещен на наш тестовый сервер, никаких проблем не возникло - поскольку тестовый сервер по-прежнему указывал на ту же веб-службу на том же тестовом сервере. Однако, когда мы переместили приложение на рабочий сервер и перенастроили файл web.config так, чтобы он указывал на рабочий сервер, мы начали получать неприятные результаты.Потребовалось довольно много усилий, чтобы точно определить, что, хотя мы перенастроили приложение, чтобы указать на реализацию веб-службы на производственном сервере, оно все еще подключается к веб-службе на тестовом сервере. Только когда мы изменили settings.settings на моей машине разработки и перекомпилировали приложение, оно заработало. В дополнение к этому мы также отметили, что если возникли проблемы с DNS при подключении к производственной веб-службе, вместо сбоя, она вернулась к исходным настройкам, которые были указаны в settings.settings с того момента, когда мы создавали прокси веб-службы в нашем приложении. - генератор прокси на самом деле жестко их кодирует. Следовательно, когда происходили сбои в сети, вместо того, чтобы получать легко диагностируемые сбои подключения, они просто возвращались к тестовым серверам, и мы начинали получать непонятные проблемы с данными. Я не уверен, была ли это известная проблема или она была исправлена, но вам, безусловно, следует знать об этом.
Следовательно, с тех пор я всегда устанавливал свойства службы как статические и использовал вспомогательный метод для чтения правильных настроек напрямую из web.config и записывал их программно, поскольку это, кажется, позволяет обойти проблему.
Может показаться, что проблема, которая у меня возникла, не имеет ничего общего с вашей, потому что я использовал веб-службы, которые не имеют ничего общего со службами Windows, однако любая среда, в которой вам нужно иметь возможность изменять настройки во время выполнения без перекомпиляции может быть затронута эта проблема, поэтому вы должны знать, что если вы работаете в среде Dev / Test / Production или действительно в любой среде, где вам нужно, чтобы ваше приложение было перенастроено во время выполнения (то есть без необходимости перекомпилировать ), что вы можете получить непредсказуемые результаты при использовании settings.settings. Остерегаться.
Я не вижу причин не использовать Settings в свойствах проекта, как это делается для winForms приложения. Мы так и делаем, и все работает нормально.
Я использую материал Settings.settings для хранения конфигурации для моих служб, и у меня не было никаких проблем. Как правило, измененные пользовательские настройки будут храниться в обычном непонятном месте, которое вам придется искать, если вы хотите отредактировать их вручную.