Comments 22
Организация объекта Properties.Settings — это обычный xml файл, который можно найти в папке пользователя:
С:\ Users \ [user name] \ AppData \ Local \ [ (Project Name) or (AssemblyCompany) ] \ [name project_cashBuild] \ [AssemblyVersion] \ user.config
Вы про app.config/web.config ничего не слышали?
С ini-файлами все на оборот, они лежат в папке рядом с программой, что позволяет пользователю изменить настройки вне-программы. Данный способ хорош, если настройки программы заносятся вручную. Например, эмулятор для запуска игры без лицензии (тотже revLoader).
А зачем это надо, когда есть app.config?
Теперь перейдем к нашей теме. Для работы с таким типом файлов, нам нужно создать класс по работе с ним. Создаем класс, например «IniFile», подключаем пространство имен (библиотеки), которых нет:
Пространства имен — это не библиотеки.
Вы про app.config/web.config ничего не слышали?
Нет, не слышал.
А зачем это надо, когда есть app.config?
Хм… Интересно, упустил его. Спасибо за информацию.
Пространства имен — это не библиотеки.
Косяк, согласен. Исправил.
Нет, не слышал.
Ну так может стоит сначала разобраться в теме, о которой вы пришли писать статью на хабр? app/web.config — это первичное место для настроек программы на протяжении нескольких версий .net, а вы его «упустили».
Ну, начнем с того, что об этому уже писали на хабре, именно об app.config (статья). Так же я тут не затронул xml, в котором, тоже многие хранят настройки и не только.
В ini-файле удобней описывать конфигурацию, чем в xml. Особенно для программ, которые не имеют пользовательского интерфейса.
Так же можно разбить настройки в две категории:
А я, тем временем, буду продолжать учиться и набивать шишки на своих ошибках.
В ini-файле удобней описывать конфигурацию, чем в xml. Особенно для программ, которые не имеют пользовательского интерфейса.
Так же можно разбить настройки в две категории:
- Программные — задаются разработчиком и находятся в app/web.config
- Пользовательские — задаются пользователем и живут в ini
А я, тем временем, буду продолжать учиться и набивать шишки на своих ошибках.
Ну, начнем с того, что об этому уже писали на хабре, именно об app.config
И что? Если посыл вашей статьи в том, чтобы собрать вместе все способы хранения настроек, то пропускать app.config нельзя. Особенно когда вы первым пунктом пишете про .Settings-файл, настройки из которого тоже хранятся там же.
В ini-файле удобней описывать конфигурацию, чем в xml.
Кому удобнее?
Так же можно разбить настройки в две категории:
Программные — задаются разработчиком и находятся в app/web.config
Пользовательские — задаются пользователем и живут в ini
Если речь о десктопе, то зачем делать два механизма хранения настроек, когда есть один? Если речь о вебе, то как вы себе представляете хранение настроек в ini?
собрать вместе все способы хранения настроек
Да это есть цель. Буду пополнять, постепенно. Или же вторую сделаю. Посмотрю еще, как лучше.
Кому удобнее?
Пользователю. Юзверю проще разобраться с секцией и ключем, чем в xml файле.
(не знаю, как у других, но до изучения xml, было проще работаться с ini или похожими настройками)
Если речь о вебе, то как вы себе представляете хранение настроек в ini?Но! Я не вел речи о вебе.
Пользователю. Юзверю проще разобраться с секцией и ключем, чем в xml файле.
А зачем неквалифицированному пользователю лезть в конфигурацию? А для квалифицированного xml не представляет проблем (особенно учитывая его поддержку современными редакторами).
Но! Я не вел речи о вебе.
В вебе настройки хранить не надо? Или для веба на C# не пишут?
В вебе настройки хранить не надо? Или для веба на C# не пишут?
Я разве сказал, что ему не нужна конфигурация? Я разве сказал, что не пишут? Что-то не припомню.
Веб тоже в них нуждается, но я не вел о нем речь. Затронута была тема десктопных приложений.
Да косяков много, но я буду их исправлять и набираться опыта в написании статей. Благодарю за критику.
UFO just landed and posted this here
Эцсамое. Берём JSON.NET, делаем иерархию классов настроек любой вложенности. Из сохранение сводится к
Получаем строго типизированный конфиг с производной древовидной структурой и простотой задания умолчаний (они задаются прямо в коде как дефолтные значения свойств) в две строчки кода. Совместимо с coreclr/corefx, мобилками, да вообще со всем кроме разве что .NET Micro. Не вижу смысла пользоваться чем-то ещё.
File.WriteAllText("settings.json", JObject.FromObject(settings).ToString())
Object.Parse(File.ReadAllText("settings.json")).ToObject<Settings>()
Получаем строго типизированный конфиг с производной древовидной структурой и простотой задания умолчаний (они задаются прямо в коде как дефолтные значения свойств) в две строчки кода. Совместимо с coreclr/corefx, мобилками, да вообще со всем кроме разве что .NET Micro. Не вижу смысла пользоваться чем-то ещё.
Чем JObject.Parse лучше, чем JsonConvert.DeserializeObject<T>?
Или это два варианта одной операции?
Или это два варианта одной операции?
Если настроек очень много, то можно еще использовать и Automapper.
но все они как-то разбросаны, поэтому я решил их собрать вместе и разбросать теперь по хабру.списать
Как-будто в 2010 вернулся
В реальных проектах кто-то app.config использует? Лично я в своих проектах использую синглтон в виде Dictionary (на самом деле там переписанный на C# xml-движок для QSettings из Qt).
UFO just landed and posted this here
Для начинающих шарпистов статья вполне себе полезная
Sign up to leave a comment.
C#, способы хранения настроек программы