Ответ 1
У меня были проблемы с использованием Settings.settings. Например, если вам нужно внести изменения во время выполнения, могут возникнуть проблемы с переопределением параметров теми, которые изначально были сохранены в файле settings.settings, в отличие от того, что показано, должно быть сохранено в приложении /web.config, Следовательно, я делаю все настройки прокси-сервера веб-службы "статичными" в свойствах и вытаскиваю их вручную из приложения /web.config с помощью вспомогательного метода и программно устанавливаю их. Это предотвращает любые проблемы.
Пример проблемы, которую мы имели: я указал машину разработки на веб-службу на тестовом сервере, чтобы протестировать код, который использовал веб-службу. Когда код был перенесен на наш тестовый сервер, никаких проблем не проявилось - поскольку тестовый сервер все еще указывался на одну и ту же веб-службу на том же тестовом сервере. Однако, когда мы перенесли приложение на производственный сервер и перенастроили web.config, чтобы указать на производственный сервер, мы начали получать неожиданные результаты. Потребовалось немало усилий, чтобы определить, что, хотя мы переконфигурировали приложение, чтобы указать на реализацию серверного веб-сервиса на производственном сервере, он все еще подключался к веб-службе на тестовом сервере. Это произошло только после того, как мы изменили параметры settings.settings на моей машине разработки и перекомпилировали приложение, в котором оно работало. В дополнение к этому мы также отметили, что если возникли проблемы с DNS, связанные с производственной веб-службой, а не сбой, он вернулся к исходным настройкам, которые были указаны в параметрах settings.settings, когда мы создали прокси-сервер веб-службы в нашем приложении - прокси-генератор на самом деле жестко кодирует их. Следовательно, когда произошли сбои в сети, вместо того, чтобы легко диагностировать сбои подключения, он просто отступил на тестовый сервер, и мы начали получать непонятные данные. Я не уверен, что это была известная проблема или она исправлена, но это, безусловно, то, о чем вы должны знать.
Следовательно, с тех пор я всегда ставил свойства сервиса в static и использовал вспомогательный метод для непосредственного считывания правильных параметров из web.config и их программного программирования, поскольку это, похоже, обходит проблему.
Может показаться, что проблема, которую я имел, не имеет ничего общего с вашей, потому что я использовал веб-службы, которые не имеют ничего общего с Windows Services, однако в любой среде, где вам нужно иметь возможность изменять настройки во время выполнения без необходимости повторной компиляции, может быть затронута эта проблема, поэтому вы должны знать, что если вы запустите в среде Dev/Test/Production или в любой среде, где вам нужно, чтобы ваше приложение было перенастроено во время выполнения (т.е. без необходимости перекомпилировать), что вы можете получить непредсказуемые результаты при использовании settings.settings. Осторожно.