В среде .Net существует рекомендованный механизм сохранения параметров приложения для восстановления их при следующих запусках приложения. Другими словами конфигурационные файлы теперь можно без труда прочитать средствами .Net работая с ними по единой схеме. Вся радужная картина омрачается одним моментом, вы без труда можете прочитать или сохранить любое значение если вы знаете какой именно интерфейс нужно использовать в данный момент. В среде .Net их образовалось неприличное множество. Без предварительной подготовки данный материал не воспринимается на одном дыхании и требует дополнительной проработки для выбора оптимального механизма работы. Поэтому я привожу краткий обзор всех средств работы для желающих лучше ее использовать.
Последовательное повествование начинается с документации, которую студия подсовывает независимо от желания разработчику, и далее по тексту все возможные методы работы с настройками:
VB
Начав работу с настройками через дизайнер настроек проекта вы первым делом, по не понятным на то причинам, попадаете в разделы документации посвященные языку VisualBasic. Данный раздел предстает перед вами не зависимо от того, в каком языке вы ведете разработку и какие проекты в включены в текущий солюшин. На этот упор в демонстрации технологии можно сделать скидку с учетом того, что технология работы с настройками приложений является меж языковой, однако это не так. Получая первые сведения о механизмах загрузки и получения значений, а так же их сохранение из приложения весьма различна.
http://msdn.microsoft.com/en-us/library/bc6ws923.aspx
Из данных разделов документации образуется общая архитектура и механизмы работы с настройками присущие всем интерфейсам. Становиться понятно, что механизм работы с настройками из VB является стандартным и, видимо,был разработан специально для этой среды. Убирая тем самым все хитрые методы работы с конфигурационными файлами, которые было необходимо использовать до этого. Именно из бейсика удобно добавить настройки и удалить их из проекта используя дизайнер, как никогда прежде. Кроме того, доступ из среды исполнения к параметрам сводиться к простому обращению объекта My.Settings без каких-либо дополнительных заворотов. Сохранение и перезагрузка параметров так же достигается путем вызова My.Settings.Save(), My.Settings.Reload(). В общем никаких проблем. А вот полная картина работы с параметрами становиться действительно подробной если вы обратитесь к документации по C# раздела Настройки.
C#
http://msdn.microsoft.com/en-us/library/aa730869(VS.80).aspx
Необходимо помнить о том, что настройки разделяются на две области: пользователя и приложения. Каждая область имеет свои специфичные особенности отражающие механизмы работы с ними. Кроме этого, настройки попавшие в приложение из конфигурационных файлов не считываются напрямую из app.config располагаемого в директории с программой, а проходят дополнительное объединение с конфигурационными файлами пользователя. Эти специфичные для пользователя файлы хранятся в %APPDATA%\[company]\[product]\[version]\user.config, а так же в Local Settings\Application Data\[company]\[product]\[version]\user.config.
Доступ к переменным из C# осуществляется через namespace Properties. Чтение и установка переменной производиться путем обращения к Properties.Settings.Default.myName значению. Запись измененных настроек вызовом метода Save() у объекта Properties.Settings.Default.Save().
WebServices
Вся неразбериха начинается тогда, когда вы создаете проект ВебСервиса и пытаетесь задать параметры привычным для вас способом. Работая через дизайнер настроек, созданные вами изменения попадают в файлы Settings.settings проекта, вместо положенного Web.config. Но и это не такая большая проблема по сравнению с большим выбором и запутанными схемами работы с настройками предлагаемые для работы. Вот краткие замечания:
Во-первых, используя веб сервис студия всеми силами желает предложить вам работать по старой схеме и у нее это хорошо получается. Вы без труда сохраняете настройки там, где они не должны быть, а так же без труда получаете их значения. Кроме того можете создать простое приложение работающее по правилам локальных форм и подключить его к основному веб приложению. Тем самым добившись плохих результатов.
Во-вторых, понимая что настройки должны быть сохранены в файле web.config вы первым делом просматриваете его содержимое и мгновенно теряетесь среди множества настроечных секций.
Ну и наконец, в-третьих: в документации представлены различные методы работы с настройками веб сервисов, некоторые из которых уже рекомендуется не использовать.
http://msdn.microsoft.com/en-us/library/ms180994.aspx
Другие же разделы по данному вопросу просто помечены как не безопасные и лишь подходят для ознакомления с технологией.
http://msdn.microsoft.com/en-us/library/system.configuration.configurationsettings(VS.71).aspx
Web.config
Настройки файла web.config описаны в документе о ASP.NET Configuration Settings.
http://msdn.microsoft.com/en-us/library/b5ysx397(VS.80).aspx
http://msdn.microsoft.com/en-us/library/6hy1xzbw(VS.80).aspx
Важной особенностью работы конфигурационных файлов для веба является продвинутый, по сравнению со стандартными приложениями, механизм наследования настроек. Основной файл настроек содержится в папке systemroot\Microsoft.NET\Framework\versionNumber\CONFIG\Web.config. Все значения этого файла могут быть перезаписаны новыми конфигурационным файлом находящимся в рабочей папке. В тоже время все файлы находящиеся в рабочих папках так же могут быть перезаписаны конфигурационными файлами находящимся по уровню ниже в дочерних папках.
По умолчанию созданный конфигурационный файл в проекте нового ВебСервиса содержит мало информации. Документации по этому разделу у меня не получилось найти, однако если вам необходимо узнать все возможные параметры настройки и назначение каждой секции вам понадобится просмотреть основной файл конфигураций. Он находиться в папке systemroot\Microsoft.NET\Framework\versionNumber\CONFIG\*. К примеру для того чтобы узнать что же представляет из себя загадочная секция . Необходимо открыть machine.config, узнать тип одноименной секции в атрибуте type="System.Configuration.AppSettingsSection" после чего можно открыть раздел документации по конкретному разделу. Таким образом пробежавшись по всем значимым полям мы получаем представление о правилах работы с настройками приложения под веб.
http://msdn.microsoft.com/en-us/library/system.configuration.appsettingssection.aspx
WebConfigurationManager
Что же касается работы с ВебСервисами, то скажу лишь что необходимо использовать класс WebConfigurationManager. Последующей ссылке можно посмотреть пример работы. Там же указано что это преимущественный способ работы с настройками для веб приложений, однако для клиентских программ общающихся с данным сервисом необходимо выбрать класс ConfigurationManager.
http://msdn.microsoft.com/en-us/library/system.web.configuration.webconfigurationmanager(VS.80).aspx
WinAPI
Еще один метод работы с конфигурационными файлами, появился здесь заодно. Не используйте его при работе под .Net
http://msdn.microsoft.com/en-us/library/ms725501(VS.85).aspx
Registry
Сохранение настроек в реестр еще один способ сохранить параметры приложения между перезапусками. Однако данный метод лешен механизма наследования.
Application.UserAppDataRegistry.SetValue Application.UserAppDataRegistry.CommonAppDataRegistry
http://msdn.microsoft.com/en-us/library/system.windows.forms.application.userappdataregistry.aspx
File store
Сохранение данных на диске с последующим использованием, рекомендуется делать по этому пути:
Application.CommonAppDataPath Application.UserAppDataPath
http://msdn.microsoft.com/en-us/library/system.windows.forms.application.userappdatapath.aspx
Team Work
Один вопрос, который я оставил на последок - это совместная работа в проекте. Как бы не показалось на первый взгляд это сильно связано с рассматриваемой темой и в первую очередь затрагивает использование общих персонализация настроек для каждой машины разработчика.
Мы используем различные системы контроля версий обеспечивающих синхронизацию кода между разработчиками. В результате чего мы имеем абсолютно идентичные копии проекта на всех машинах. Одновременно нам нужно обеспечить индивидуальные настройки и строчки соединения с базой данных, для конкретной среды в которой работает программист с его аутентификационными данными. Делать это можно по старинке - меняя содержимое проектных файлов для конкретных нужд. Однако лучше воспользоваться конфигурациями управляемые через ConfiguarationManager (или его веб версию).
Для этого создадим общий шаблон настроек и поместим его под систему контроля версий. После чего создадим вторую рабочую копию, которая будет распространятся мимо центрального проектного хранилища через электронную почту.
http://msdn.microsoft.com/en-us/library/ms178685.aspx
Для прозрачного подключения данного файла к проекту воспользуемся механизмом наследования предлагаемого по умолчанию. Так как К ASP не предлагает гибкой схемы наследования нам придется исключить файл Web.config из репозитория файлов переименовав его в Web.default.