.Net settings preserve

В среде .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.  

Ссылки по теме:

• Application Settings Architecture - http://msdn.microsoft.com/en-us/library/8eyb2ct1.aspx
• Application Settings Overview - http://msdn.microsoft.com/en-us/library/k4s6c3a0.aspx