Рекомендации по хранению параметров службы Windows .NET: параметры свойств службы, сериализация,

Question

Я работаю в .NET Windows Service, где я пытаюсь сохранить настройки, которые будут использоваться при запуске службы и во время ее работы.Я просмотрел сообщения на SO и обнаружил, что использование настроек в свойствах проекта отлично подходит для использования с консольными приложениями и приложениями winforms.Однако Google и SO молчат, когда речь идет о сохранении этих настроек с помощью службы Windows.

Кто-нибудь знает, правильно ли использовать эти настройки в службе .NET?Если нет, будет ли Serialization моим следующим лучшим выбором?Кто-нибудь имел практическое применение настроек в сервисе и обнаружил, что лучше всего использовать определенный метод?

Answer 1

У меня были проблемы с использованием Settings.settings.Например, если вам нужно внести изменения во время выполнения, могут быть проблемы с настройками, которые переопределяются теми, которые изначально были сохранены в файле settings.settings, в отличие от того, что показано , следует хранить в соответствии сприложение / web.config.Следовательно, я делаю все параметры прокси-сервера веб-службы «статическими» в свойствах и вручную извлекаю их из app / web.config с помощью вспомогательного метода и устанавливаю их программным способом.Это позволяет обойти любые проблемы.

Пример проблемы, с которой мы столкнулись: я указал моей машине для разработки на веб-сервис на тестовом сервере для тестирования кода, который использовал веб-сервис.Когда код был перенесен на наш тестовый сервер, никаких проблем не возникло - так как тестовый сервер все еще был направлен на тот же веб-сервис на том же тестовом сервере.Однако когда мы переместили приложение на рабочий сервер и перенастроили web.config так, чтобы он указывал на рабочий сервер, мы начали получать странные результаты.Потребовалось немало усилий, чтобы определить, что, хотя мы перенастроили приложение, чтобы оно указывало на реализацию веб-службы на производственном сервере, оно все еще подключалось к веб-службе на тестовом сервере.Только когда мы изменили settings.settings на моей машине для разработки и перекомпилировали приложение, оно работало.В дополнение к этому мы также отметили, что если при подключении к производственному веб-сервису возникли проблемы с DNS, а не произошел сбой, он вернулся к исходным настройкам, которые были указаны в settings.settings с момента создания прокси-сервера веб-службы в нашем приложении- Генератор прокси на самом деле жестко их кодирует.Следовательно, когда происходили сбои в работе сети, вместо того, чтобы легко диагностировать сбои соединения, он просто возвращался к тестовому серверу, и у нас начинались непонятные проблемы с данными.Я не уверен, что это была известная проблема или она была исправлена, но это, безусловно, то, о чем вы должны знать.

Следовательно, с тех пор я всегда устанавливал свойства сервиса на static и usedвспомогательный метод для непосредственного чтения правильных настроек из web.config и их программной записи, поскольку это, кажется, позволяет обойти проблему.

Может показаться, что проблема, с которой я столкнулся, не имеет ничего общего с вашей, потому что я использовалВеб-службы, которые не имеют ничего общего со службами Windows, однако, любая проблема, в которой вам нужно иметь возможность изменять параметры во время выполнения без перекомпиляции, может быть затронута этой проблемой, поэтому вы должны знать, что если вы запускаете всреда разработки / тестирования / производства или даже любая среда, в которой требуется переконфигурировать ваше приложение во время выполнения (т.е. без перекомпиляции), чтобы вы могли получить непредсказуемые результаты при использовании settings.settings.Осторожно.

Answer 2

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

string lsbkey = @"Software\mycompany\adas";

RegistryKey adaskey = Registry.LocalMachine.OpenSubKey(lsbkey, false);

try
{
    object regip = adaskey.GetValue("IP");
    object regport = adaskey.GetValue("PORT");
    localip = regip.ToString();
    localport = int.Parse(regport.ToString());
}
catch (NullReferenceException ne)
{
    localip = null;
    localport = 0;
    writelog(@"Aborting Service, IP or PORT doesn't exist in \local machine\software\mycompany\adas : "+ne.Message);
    status = 0;

}

Answer 3

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

Answer 4

Я не вижу причин не использовать Настройки в свойствах проекта, как если бы вы использовали приложение winFormsМы делаем это, и это прекрасно работает.