App.Config и Custom Configuration Sections

[@andmaz]

Хорошая статья. Можно также упомянуть про более альтернативный подход — это интерфейс IConfigurationSectionHandler, который позволяет парсить секции вручную

[@lair]

… каковой подход MS не рекомендует.

[@andmaz]

… на сама использует (убедился, когда смотрел system.dll)

[@lair]

А вы думаете, что MS должны были переписать весь фреймворк с появление configurationelement? Legacy code такой legacy.

[@serkuzm]

ИМХО, писать из кода в app.exe.config я буду только в ну уж очень крайних случаях. Стараюсь пользоваться правилом — не писать в директорию из которой пользователь имеет права на запуск приложений. Лучше создам еще одну директорию в папке программы и там буду хранить свой app.config.xml. Ну а для user-specific параметров — стараюсь использовать user.config. Как-то так…

[@ap3rus]

Правило неоднозначное, можно ведь настроить ACL на запись только на допустимый файл конфигурации, исключая несанкционированный доступ к защищенным объектам. От себя добавлю, держать перезаписываемую конфигурацию удобнее в базе данных по двум причинам: 1 — хорошая расширяемость, 2 — удобство редактирования при достаточно сложной конфигурации (косвенно вытекает из пункта 1). Хотя, если приложение достаточно небольшое и/или не подразумевает расширяемость и/или имеет короткосрочный этап разработки, в некоторых случаях файлы будут проще.

[@lair]

«Правило неоднозначное, можно ведь настроить ACL на запись только на допустимый файл конфигурации, исключая несанкционированный доступ к защищенным объектам.»
Слишком геморройно. А еще при многопользовательской конфигурации не работает.

«От себя добавлю, держать перезаписываемую конфигурацию удобнее в базе данных»
То есть когда мы ставим пользователю локальное приложение, нам ему еще и базу данных надо поставить, даже если оно ее не использует?

[@ap3rus]

Слишком геморройно. А еще при многопользовательской конфигурации не работает.

Это настолько же возможно (в том числе при многопользовательской конфигурации) и с теми же затратами, насколько при работе с отдельными папками конфигураций.

То есть когда мы ставим пользователю локальное приложение, нам ему еще и базу данных надо поставить, даже если оно ее не использует?

Во-первых, приложение будет использовать БД, так как в ней будет храниться конфигурация. Во-вторых, не обязательно использовать сервер БД, для простого приложения может быть достаточно SQL Server Compact или SQLite — получаем те же удобства конфигурирования на гибких условиях. В-третьих, последним предложением я подчеркнул, что все зависит от случая и использование базы не всегда будет эффективным.

[@lair]

«Это настолько же возможно (в том числе при многопользовательской конфигурации) и с теми же затратами, насколько при работе с отдельными папками конфигураций.»
Отнюдь. Когда в приложении настройки делятся на app-level и user-level, .net автоматически распихивает последние по папкам пользователей, куда у приложения есть права на запись (а в program files, куда оно ставится, по умолчанию прав нет). Так что zero effort.

[@ap3rus]

User-level конфигурацию, разумеется, удобнее и следует держать в папке профиля пользователя, возможно, я внес недопонимание, не упомянув, что говорю о глобальных настройках. Эта фрагментация, к слову, — еще одна причина, по которой использование базы данных является более удобным.

[@Ceiceron]

Сильно! Особенно хорошо дополнение к студии.

[@jonie]

Таки проще сериализацию использовать имхо. Гуглится Xml Serialization configuration Section на два клика — один раз написал\скопипастил и «на всю жизнь».

[@2king2]

Интересно, спасибо. Попробовал сам с app.config поиграться, вот только беде при закрытие программы все что было записано app.config сбрасывается в первоначальное состояние.