Здравствуйте,
Как известно большой минус хранить настройки в приложении
в xml: файл с настройками получается плохо читаемым, нет возможности писать комментарии.
в json: нет возможности писать комментарии, надо постоянно то вставлять, то удалять запятую что бы разделить поля.
Пробовал для конфигов использовать s-expression формат(несколько приложений/несколько лет уже работают с таким конфигом оК): https://github.com/ichensky/S.NET
удобно, можно писать комментарии, конфиг получается компактным, легко читаемым/редактируемым.

;;; This app ...
(app (name "Cool app")
     (connectionString "db=;user=;pass;") ;; Connection string to db
     (oneMoreProp "..."))

Но, что если вместо конфигов сразу использовать C# код? Просто обычный C# класс

public class Config {
    public const string Name = "Cool app";
    public const string ConnectionString = "db=;user=;pass;";
}

Из плюсов: можно писать комментарии, удобная навигация по коду, при рефакторинге конфига меньше шансов получить ошибку с неправильным мапингом свойств в коде. Если надо этот конфиг расшарить с каким-то другим приложением, всегда можно так же как и раньше сериализовать объект с нужными полями в json напр. и передать другому приложению.
Какие минусы по сравнению с тем же json/xml?

Здравствуйте, #John, Вы писали:

J>в xml: файл с настройками получается плохо читаемым, нет возможности писать комментарии.

Комментарии есть.

J>в json: нет возможности писать комментарии, надо постоянно то вставлять, то удалять запятую что бы разделить поля.

Верно. Но есть в .net парсер настроек из "json" который понимает не вполне нормальный json, а именно — поддерживает комментарии!

J>Из плюсов: можно писать комментарии, удобная навигация по коду, при рефакторинге конфига меньше шансов получить ошибку с неправильным мапингом свойств в коде. Если надо этот конфиг расшарить с каким-то другим приложением, всегда можно так же как и раньше сериализовать объект с нужными полями в json напр. и передать другому приложению.
J>Какие минусы по сравнению с тем же json/xml?

Я не понял. Файл компилируется сразу в проекте или динамически добавляется при старте приложения?
Если первое, то нет возможности сменить настройки после старта, что наиболее важно для файла настроек
Если второе, то нет навигации по коду и рефакторинга, зато синтаксис не особо удобный для настроек.

Здравствуйте, #John, Вы писали:

J>в xml: файл с настройками получается плохо читаемым, нет возможности писать комментарии.
В XML как раз писать комментариев можно сколько угодно. Так же плюс — конфиг может быть структурным.


J>в json: нет возможности писать комментарии, надо постоянно то вставлять, то удалять запятую что бы разделить поля.
Можно использовать парсер который позволяет и комментарии и висячую запятую, тот же ньютонсофт.

J>Пробовал для конфигов использовать s-expression формат(несколько приложений/несколько лет уже работают с таким конфигом оК)
Это лиспоидный ужас. Обилие скобок только усложняет. По сути те же трудности, что и в XML, только в ином синтаксисе. Ужас тут, не в как таковом решении, а в его крайней не популярности.

J>Из плюсов: можно писать комментарии, удобная навигация по коду, при рефакторинге конфига меньше шансов получить ошибку с неправильным мапингом свойств в коде. Если надо этот конфиг расшарить с каким-то другим приложением, всегда можно так же как и раньше сериализовать объект с нужными полями в json напр. и передать другому приложению.
J>Какие минусы по сравнению с тем же json/xml?
Этот параграф абсолютно применим к любому формату файла. Нюансы будут только в конечных инструментах, но нет ничего, что бы не делалось.
Кроме того, маппинг как таковой и валидация настроек вещи разные. Если связь идет банально по названием ключей — то отсутствующие опции должны быть замечены именно валидацией, и выявлены в непродолжительное время. Есть подозрение, что это вообще не является проблемой, т.к. опций не так и много. Если их много — тогда XML со схемой или json со схемой могут быть лучшими решениями, т.к. поддерживаются редакторами, валидируются в какой-то мере.

Так же есть старые добрые ini-файлы на любой вкус. Максимально просто формат, в него укладываются довольно много вещей и он так же всем понятен и легко читается как пользователями так и машиной.

Здравствуйте, #John, Вы писали:

J>Здравствуйте,
J>Как известно большой минус хранить настройки в приложении
J>в xml: файл с настройками получается плохо читаемым, нет возможности писать комментарии.
J>в json: нет возможности писать комментарии, надо постоянно то вставлять, то удалять запятую что бы разделить поля.

Это почему в JSON нельзя вставлять коментарии? Json.NET прекрасно читает JSON с многострочными и однострочныси коментариями.

/*
   "Prop1": "Value",
   "Prop2": "Value"
*/

// "Prop1": "Value",
   "Prop2": "Value"

Здравствуйте, Danchik, Вы писали:

D>Это почему в JSON нельзя вставлять коментарии?

Потому что. Json — это стандарт. И комментариев в нем нет. Json.NET умеет читать файлы с комментариями, но строго говоря такие файлы — это НЕ json.
Douglas Crockford написал пост, почему он решил не добавлять коменты в json, но все ссылки ведут на google++ который сдох.

Здравствуйте, fmiracle, Вы писали:

F>Здравствуйте, #John, Вы писали:

J>>в xml: файл с настройками получается плохо читаемым, нет возможности писать комментарии.
F>Комментарии есть.
Есть, но они сильно ограничены, потому что напр. нельзя закомментировать любой аттирибут в средине тега,
нельзя написать комментарий возле аттрибута в теге.

F>Я не понял. Файл компилируется сразу в проекте или динамически добавляется при старте приложения?
F>Если первое, то нет возможности сменить настройки после старта, что наиболее важно для файла настроек
Выше в комментарии там поля должны быть обычными, а не `const`, так что можно будет после старта приложение переопределить их.

А если нам надо загружать разные настройки для разных envitorments(пароли/приватные ключи), то можно такие настройки вынести в под конфиг
напр. структуру проекта:

.
├── build.sh
├── env
│   ├── dev
│   │   └── etc
│   │       └── my_app
│   │           └── keys_config.cs
│   ├── local
│   │   └── etc
│   │       └── my_app
│   │           └── keys_config.cs
│   └── prd
│       └── etc
│           ├── my_app
│           │   └── keys_config.cs
│           └── nginx
└── etc
    ├── my_app
    │   └── keys_config.cs
    └── nginx
└── src
    └── my_app
        ├── config.cs
        ├── Program.cs
        └── my_app.proj

Теперь если мы запускаем `./build.sh dev` (с ключем `dev` напр.),
и скрипт сделает билд проекта `src/my_app` в дерикторию `./package/usr/bin/my_app` ,
скопирует `./etc/` в `./package/`
а потом скопирует(с оверайдом) все файлы из дериктории `/env/dev/`
и успешно перезапишет `./package/etc/my_app/keys_config.cs`

После установки пакета, приложение после запуска прочитает сначала конфиг `/etc/my_app/config.cs`, а потом динамический из `/etc/my_app/keys_config.cs`

Здравствуйте, #John, Вы писали:

Я наверное упустил про C#. Конфиг предполагается вкомпиливать в код? Ну, это может зачем-то и надо, только это уже не конфиг, а набор предопределенных значений.

Я иногда завожу класс с константами, в которых спрятаны или флажки для вкл/выкл экспериментальных фич, функционала, которые потом и в конфиг уехать могут, или просто констант по потребностям. Но это и не совсем конфиг.

Иногда ставлю настройки в отдельном .cs файле, в каких-нибудь враперах которые нужны во время разработки и не более того.

Здравствуйте, #John, Вы писали:
J>Из плюсов: можно писать комментарии, удобная навигация по коду, при рефакторинге конфига меньше шансов получить ошибку с неправильным мапингом свойств в коде. Если надо этот конфиг расшарить с каким-то другим приложением, всегда можно так же как и раньше сериализовать объект с нужными полями в json напр. и передать другому приложению.
J>Какие минусы по сравнению с тем же json/xml?

Самое простое — использовать один или несколько ini-файлов

Еше есть json для людей (для конфигов) — https://hjson.org/
В нем и комментарии есть, запятые висячие можно и т.п.
Есть парсеры для кучи языков, том числе C#

Есть еще YAML, но он сложноват, т.к. в нем куча нюансов, не все захотят разбираться.

config.cs стоит рассматривать только если он предназначен для правки программистами.
Для пользователей не подходит.

Здравствуйте, Mystic Artifact, Вы писали:

MA> Так же есть старые добрые ini-файлы на любой вкус. Максимально просто формат, в него укладываются довольно много вещей и он так же всем понятен и легко читается как пользователями так и машиной.

Со всем согласен, кроме INI — слишком уж он плоский. Чуть шаг в сторону — становится гирей на ноге. Давайте дадим ему умереть

Здравствуйте, #John, Вы писали:

J>Здравствуйте,

Здорова, не рассматривал вариант с IOptions<T>? Как мне кажется — это такой своеобразный микс, используешь json как хранилище конфигов, и C# код с возможностью комментов и документации.
https://docs.microsoft.com/en-us/aspnet/core/fundamentals/configuration/options?view=aspnetcore-2.2

Здравствуйте, Mr.Delphist, Вы писали:

Ну, нюансов много может быть. Скажем пробелы в конце строки легко записать в форматах, где строки можно/нужно заключить в кавычки, в тоже время с ini файлами никогда не знаешь умеет ли конкретный софт это, поддерживает ли многострочные значения и т.п. Отсутствие внятного стандарта в свое время, тут, пожалуй навредило.

С js/json/python подробными объектами, на мой взгляд, работать просто не удобно, т.к. повышается уровень шума из-за очевидно ненужных кавычек вокруг имен ключей, иногда и значений. Так же, нет возможности задавать последовательные пары ключ=значения с гарантированным порядком, пока не позовешь парсер в ручную. Ну понятно, что можно в массив завернуть, добавив изрядное число новых скобок.

Я бы лично, предпочел XML, особенно, если он не автогенерен, а человеколюбиво оформлен, что в принципе возможно.

Но, опять же — если 5 значений — любой формат будет работать. Если это конфиг сложного продукта, на подобии фичастого веб-сервера, — то тут так сразу и не скажешь.

Безусловно, самый плохой выбор, на мой взгляд, json который без комментариев, потому как невозможно ни шаблон сформировать с описанием опций/значений, ни самому че-то временно подправить.

Поэтому: если xml кажется слишком сложным или неудобным, ini — все еще себе игрок.

Здравствуйте, Буравчик, Вы писали:

Б>Еше есть json для людей (для конфигов) — https://hjson.org/
Б>В нем и комментарии есть, запятые висячие можно и т.п.
Б>Есть парсеры для кучи языков, том числе C#

А, забыл. Еще и кавычки не нужны! Можно их опускать как для ключей, так и для значений

Здравствуйте, Jack128, Вы писали:

J>Здравствуйте, Danchik, Вы писали:

D>>Это почему в JSON нельзя вставлять коментарии?

J>Потому что. Json — это стандарт. И комментариев в нем нет. Json.NET умеет читать файлы с комментариями, но строго говоря такие файлы — это НЕ json.
J>Douglas Crockford написал пост, почему он решил не добавлять коменты в json, но все ссылки ведут на google++ который сдох.

Вам шашечки или ехать?

Здравствуйте, #John, Вы писали:

J>в xml: файл с настройками получается плохо читаемым,

Почему?

J> нет возможности писать комментарии.

Ну здрасте. Кто украл комментарии из xml?

J>в json: нет возможности писать комментарии

В некоторых реализациях комменты есть.

J>Но, что если вместо конфигов сразу использовать C# код? Просто обычный C# класс
J>Какие минусы по сравнению с тем же json/xml?

Десериализовать конфиг как? Запускать компилятор шарпа? Или парсить шарп самому?

Здравствуйте, #John, Вы писали:

J>Есть, но они сильно ограничены, потому что напр. нельзя закомментировать любой аттирибут в средине тега,
J>нельзя написать комментарий возле аттрибута в теге.

Можно сконвертировать атрибут в тег.

J>Теперь если мы запускаем `./build.sh dev` (с ключем `dev` напр.),
J>и скрипт сделает билд проекта `src/my_app` в дерикторию `./package/usr/bin/my_app` ,
J>скопирует `./etc/` в `./package/`
J>а потом скопирует(с оверайдом) все файлы из дериктории `/env/dev/`
J>и успешно перезапишет `./package/etc/my_app/keys_config.cs`

J>После установки пакета, приложение после запуска прочитает сначала конфиг `/etc/my_app/config.cs`, а потом динамический из `/etc/my_app/keys_config.cs`

Т.е., к примеру, чтобы поменять секрет к какому нибудь внешнему сервису нужно пересобирать и передеплоивать весь проект? Офигеть как удобно.

Здравствуйте, Jack128, Вы писали:

J>Потому что. Json — это стандарт. И комментариев в нем нет. Json.NET умеет читать файлы с комментариями, но строго говоря такие файлы — это НЕ json.

Да, не JSON. Но JSON и не предназначен для конфигов, только для сериализации. А для конфигов используется похожий на JSON формат, но с комментариями. Потому что формат конфигов, не допускающий комментариев это полный и тотальный бред.

Здравствуйте, Буравчик, Вы писали:

Б>Есть еще YAML, но он сложноват, т.к. в нем куча нюансов, не все захотят разбираться.

Зато он более хипста. Поэтому самые хипста хипста уже не используют json, только yaml. Вон OpenAPI последней версии уже yaml, хотя раньше был json.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, Jack128, Вы писали:

J>>Потому что. Json — это стандарт. И комментариев в нем нет. Json.NET умеет читать файлы с комментариями, но строго говоря такие файлы — это НЕ json.

НС>Да, не JSON. Но JSON и не предназначен для конфигов, только для сериализации. А для конфигов используется похожий на JSON формат, но с комментариями. Потому что формат конфигов, не допускающий комментариев это полный и тотальный бред.

Я даже видел, расширение .jsonc — JSON With Comments, который по умолчанию поддерживается VS Code.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Т.е., к примеру, чтобы поменять секрет к какому нибудь внешнему сервису нужно пересобирать и передеплоивать весь проект? Офигеть как удобно.

Если просто что бы подебажить, то напр. в локальном конфиге,можно просто закомментить нужное поле:

class Config{
//public string Url = "https://stg.env"
//public string Url = "https://live.env"
public string Url = "https://localhost"
}

А так C# конфиги один в один такие же как xml или json . Если для разных окружений много разных значений, а не одно, которое можно закомментить как выше, то вполне логично что удобнее было бы создать скрипт(или таску как в msbuild), который будет заменять значения в базовом конфиге на специфичные окружению. А что бы динамически не генерить config.cs файл после запуска такого скрипта, то проще просто вынести части специфические для окружения в отдельный файл и просто заменять этот файл на нужный в зависимости от `env`.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Десериализовать конфиг как? Запускать компилятор шарпа? Или парсить шарп самому?
C# конфиг не надо десериализовать. Это просто config.cs файл, в котором несколько классов. После запуска проекта Progrma.proj этими классами можно пользоваться как обычными.

Здравствуйте, Mystic Artifact, Вы писали:

MA>Иногда ставлю настройки в отдельном .cs файле, в каких-нибудь враперах которые нужны во время разработки и не более того.

Много gnu программ имеет конфиги написанные, (не считая ini,json,xml,yaml)
сразу на языках: lua , sh , lisp, просто на своем DSL или даже
"поменяйте значения в config.h и пересоберите проект".
Но чего тогда в мире .net не пишут конфиги на C#, а используют для этого
левые форматы данных, созданные вовсе не для написания конфигов.

Здравствуйте, #John, Вы писали:

J>Много gnu программ имеет конфиги написанные, (не считая ini,json,xml,yaml)
J>сразу на языках: lua , sh , lisp, просто на своем DSL или даже
J>"поменяйте значения в config.h и пересоберите проект".
J>Но чего тогда в мире .net не пишут конфиги на C#, а используют для этого
J>левые форматы данных, созданные вовсе не для написания конфигов.

Ты все замешал в кашу и оперируешь одному тебе известными понятиями: левые форматы данных, созданные вовсе не для написания конфигов. Еще и пишешь, что этим страдают в дотнете, но с самого начала ты осведомлен и про гнутых, что само по себе входит в противоречие.

Хотелось бы понять, что за такие форматы созданы для конфигов?

Каким образом конфиги на lua, sh, lisp, python, js, whatever лучше? Ты не задумывался, например, что такие конфиги могут содержать скрипты, что, в сущности является дополнительными точками потенциальной инъекции непонятных (зловредных) скриптов.

Какую задачу хочется решить?

Здравствуйте, #John, Вы писали:

НС>>Т.е., к примеру, чтобы поменять секрет к какому нибудь внешнему сервису нужно пересобирать и передеплоивать весь проект? Офигеть как удобно.
J>Если просто что бы подебажить

Нет, не чтобы подебажить. У тебя на проде сервис развернут и, к примеру, случился key roll up. Чего, будешь каждый раз новый билд собирать и деплоить?

J>А так C# конфиги один в один такие же как xml или json .

Только вот парсеры xml и json есть в составе платформы, не говоря уж о Microsoft.Extensions.Configuration, а вот с парсингом C# прсложнее выходит.

J> Если для разных окружений много разных значений, а не одно, которое можно закомментить как выше, то вполне логично что удобнее было бы создать скрипт(или таску как в msbuild), который будет заменять значения в базовом конфиге на специфичные окружению.

А если эти значения вообще на этапе сборки не доступны? Секреты обычно в репозиторий не кладут.

J> А что бы динамически не генерить config.cs файл после запуска такого скрипта, то проще просто вынести части специфические для окружения в отдельный файл и просто заменять этот файл на нужный в зависимости от `env`.

И что? У тебя для каждого деплоя своя сборка? Тоже офигеть как удобно, особенно если on premise присутствует.

Здравствуйте, Mystic Artifact, Вы писали:

MA> Ты все замешал в кашу и оперируешь одному тебе известными понятиями: левые форматы данных, созданные вовсе не для написания конфигов.
Имелось ввиду что xml,json больше подходят для сериализации данных и их хранения или передачи по сети, а не для написания с их помощью конфигов, которые бы потом было удобно человеку изменять/читать. Но да, многие gnu программы тоже используют xml/json для конфигов.

MA> Каким образом конфиги на lua, sh, lisp, python, js, whatever лучше?
Если программа и конфиг пишутся на одном и том же языке, будет более просто считывать/обрабатывать этот конфиг в программе,
а у пользователя появляется больше возможностей более гибко настраивать программу, напр. у нас есть программа и у нее такой конфиг:

class Config {

        // Service url
    public string ServiceUrl = "https://live.env"; 
    public string ConnectionString = "db=xxx.db;user=Bob;pass=***"; 

    public Config(){
        if (Enviroment.SomeValue){
            ServiceUrl = "https://dev.env"
        }
    }
}

В таком конфиге пользователь может в конструктор класса дописать любую логику, если ему вдруг понадобится.


MA> Ты не задумывался, например, что такие конфиги могут содержать скрипты, что, в сущности является дополнительными точками потенциальной инъекции непонятных (зловредных) скриптов.

Обычно делают, так что бы изменять конфиги приложения мог только пользователь с админскими правами или запускают приложение под другим пользователем, у которого есть доступ только к положенным ему ресурсам.

MA> Какую задачу хочется решить?

Да просто размышляю какой формат для конфигов лучше всего подходит, и ищу какие подводные камни будут если писать конфиги для .net приложений на самом C# .

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Нет, не чтобы подебажить. У тебя на проде сервис развернут и, к примеру, случился key roll up. Чего, будешь каждый раз новый билд собирать и деплоить?
НС>А если эти значения вообще на этапе сборки не доступны? Секреты обычно в репозиторий не кладут.

Хм, да есть такая проблема. Так как C# компилируемый язык придется при перезапуске приложения
считывать файл config.cs и перекомпилировать его, надо подумать как лучше всего этот вопрос решить.

Здравствуйте, #John, Вы писали:

J>Так как C# компилируемый язык придется при перезапуске приложения
J>считывать файл config.cs и перекомпилировать его, надо подумать как лучше всего этот вопрос решить.

Вот я и говорю — офигенно удобно.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, #John, Вы писали:

J>>Так как C# компилируемый язык придется при перезапуске приложения
J>>считывать файл config.cs и перекомпилировать его, надо подумать как лучше всего этот вопрос решить.

НС>Вот я и говорю — офигенно удобно.

Вот накидал пример.
https://github.com/ichensky/ExampleOfCSConfig
Использовать такой конфиг удобно, из минусов пока вижу только что в проект придется добавлять либы `Microsoft.CodeAnalysis.*dll` весом почти в 10мб. Но зато вместо какого-то json или простого DSL
для конфига будет использоваться норм. язык программирования.

Здравствуйте, #John, Вы писали:

J>Имелось ввиду что xml,json больше подходят для сериализации данных и их хранения или передачи по сети, а не для написания с их помощью конфигов, которые бы потом было удобно человеку изменять/читать. Но да, многие gnu программы тоже используют xml/json для конфигов.
Их преимущество как раз в том, что они универсальны и стандартиризированы. XML в частности вообще годится почти для чего угодно, и на его основе легко создаются иерархические документы, на подобии xhtml, svg и прочее. XML конечно, не панацея, но на нем достаточно легко описать хоть конфиги, хоть императивный набор команд, хоть набор правил.

MA>> Каким образом конфиги на lua, sh, lisp, python, js, whatever лучше?
J>Если программа и конфиг пишутся на одном и том же языке, будет более просто считывать/обрабатывать этот конфиг в программе,
Сейчас любая платформа достойная внимания умеет парсить XML и/или JSON из коробки. Да, такое практикуют в инфраструктурных скриптах, потому что лень возиться. Или же если у платформы нет возможности или нет смысла городить что-то более сложное, например в sh/cmd скриптах проще позвать отдельный скрипт-конфиг. Но это, опять, таки, чисто инфраструктурные скрипты.

J>а у пользователя появляется больше возможностей более гибко настраивать программу, напр. у нас есть программа и у нее такой конфиг:
J>В таком конфиге пользователь может в конструктор класса дописать любую логику, если ему вдруг понадобится.
Возможность динамического конфигурирования, установку значений по умолчанию, всегда доступна вне зависимости от используемого формата.

J>Обычно делают, так что бы изменять конфиги приложения мог только пользователь с админскими правами или запускают приложение под другим пользователем, у которого есть доступ только к положенным ему ресурсам.
Во-первых, это не связанные вещи, т.е. одно другое не исключает.
Во-вторых, существует масса приложений которые работают исключительно под пользовательскими правами, их даже можно установить без админ прав. Кроме того, считается, что пользователь может менять настройки, не прибегая к услугам администратора. Стоит ли звать админа, если пользователь решил изменить шрифт?

MA>> Какую задачу хочется решить?
J>Да просто размышляю какой формат для конфигов лучше всего подходит, и ищу какие подводные камни будут если писать конфиги для .net приложений на самом C# .
Ну, минусов уже насыпали в избытке.

Здравствуйте, #John, Вы писали:

Еще минус — время старта приложения возрастает. Пока оно заведется, некоторые утилиты должны были уже давно результат отдать.

Здравствуйте, #John, Вы писали:

J> а у пользователя появляется больше возможностей более гибко настраивать программу

Только вот такому пользователю надо иметь компилятор и уметь им пользоваться, и пользователю ты вынужден отдать исходники.

>Какие минусы по сравнению с тем же json/xml?

— ну наверно то что если завтра решишь эти конфиги на клиента гонять, где нету .net (веб например) то уже все, приехали
— более высокий порог входа. хотя тетю Клаву и xml хер заставишь выучить
— более богатый набор структур, хотя может это и плюс.

На одном проекте заказчик тоже захотел метаданные пописывать на своем языке. Предложил ему c#, научил писать интерфейсы (interface Blabla). Вроде доволен, и затрат минимум.
Я взяли бы даже json — ну потрахались бы точно больше.