Комментарии 15
Хорошая статья. Можно также упомянуть про более альтернативный подход — это интерфейс IConfigurationSectionHandler, который позволяет парсить секции вручную
ИМХО, писать из кода в app.exe.config я буду только в ну уж очень крайних случаях. Стараюсь пользоваться правилом — не писать в директорию из которой пользователь имеет права на запуск приложений. Лучше создам еще одну директорию в папке программы и там буду хранить свой app.config.xml. Ну а для user-specific параметров — стараюсь использовать user.config. Как-то так…
Правило неоднозначное, можно ведь настроить ACL на запись только на допустимый файл конфигурации, исключая несанкционированный доступ к защищенным объектам. От себя добавлю, держать перезаписываемую конфигурацию удобнее в базе данных по двум причинам: 1 — хорошая расширяемость, 2 — удобство редактирования при достаточно сложной конфигурации (косвенно вытекает из пункта 1). Хотя, если приложение достаточно небольшое и/или не подразумевает расширяемость и/или имеет короткосрочный этап разработки, в некоторых случаях файлы будут проще.
«Правило неоднозначное, можно ведь настроить ACL на запись только на допустимый файл конфигурации, исключая несанкционированный доступ к защищенным объектам.»
Слишком геморройно. А еще при многопользовательской конфигурации не работает.
«От себя добавлю, держать перезаписываемую конфигурацию удобнее в базе данных»
То есть когда мы ставим пользователю локальное приложение, нам ему еще и базу данных надо поставить, даже если оно ее не использует?
Слишком геморройно. А еще при многопользовательской конфигурации не работает.
«От себя добавлю, держать перезаписываемую конфигурацию удобнее в базе данных»
То есть когда мы ставим пользователю локальное приложение, нам ему еще и базу данных надо поставить, даже если оно ее не использует?
Слишком геморройно. А еще при многопользовательской конфигурации не работает.Это настолько же возможно (в том числе при многопользовательской конфигурации) и с теми же затратами, насколько при работе с отдельными папками конфигураций.
То есть когда мы ставим пользователю локальное приложение, нам ему еще и базу данных надо поставить, даже если оно ее не использует?Во-первых, приложение будет использовать БД, так как в ней будет храниться конфигурация. Во-вторых, не обязательно использовать сервер БД, для простого приложения может быть достаточно SQL Server Compact или SQLite — получаем те же удобства конфигурирования на гибких условиях. В-третьих, последним предложением я подчеркнул, что все зависит от случая и использование базы не всегда будет эффективным.
«Это настолько же возможно (в том числе при многопользовательской конфигурации) и с теми же затратами, насколько при работе с отдельными папками конфигураций.»
Отнюдь. Когда в приложении настройки делятся на app-level и user-level, .net автоматически распихивает последние по папкам пользователей, куда у приложения есть права на запись (а в program files, куда оно ставится, по умолчанию прав нет). Так что zero effort.
Отнюдь. Когда в приложении настройки делятся на app-level и user-level, .net автоматически распихивает последние по папкам пользователей, куда у приложения есть права на запись (а в program files, куда оно ставится, по умолчанию прав нет). Так что zero effort.
Интересно, спасибо. Попробовал сам с app.config поиграться, вот только беде при закрытие программы все что было записано app.config сбрасывается в первоначальное состояние.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
App.Config и Custom Configuration Sections