Здравствуйте, 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 — ну потрахались бы точно больше.