Конфигурация json с параметрами вместе с DI .NET

У меня возникла проблема при конфигурировании приложения с использованием внедрения зависимостей и IOptions<T>. У программы есть конфиг с пользовательскими настройками. Для редактирования настроек пользователь может использовать саму программу, но я допускаю, что любознательный пользователь может хотеть открыть сам файл конфигурации. Для этого я стараюсь поддерживать его в красивом виде. Чтобы это сделать, нужно использовать некоторые опции и атрибуты. К примеру, сериализация перечислений в виде именований, а не значений. Для этого требуется использовать JsonStringEnumConverter, но поставщик конфигурации json видимо это делает за меня. Было бы всё отлично, но с .NET 9 пришла возможность задавать иные имена полям перечисления для сериализации. Для этого был добавлен JsonStringEnumMemberNameAttribute, который поставщик конфигураций json видимо не использует и из-за чего я не могу сделать конфиги еще краше. Мне кажется, что для решения проблемы нужно писать свой поставщик. Может быть я что-то упускаю и у кого-то есть более элегантное решение?

0

Сообщение от KebabGGbab что любознательный пользователь может хотеть открыть сам файл конфигурации

Спрятать его куда-нибудь подальше? В каталоге пользователя (AppData) есть куча мест куда его можно положить
Можно использовать не файл в редактируемом формате, а файл локальной СУБД, к примеру SQLite, в него точно просто так не залезешь...

1

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

Вообще, конфигурации храню в AppData, куда вряд ли залезет пользователь, но хотелось бы совершенства.

0

Сообщение от KebabGGbab Как я указал в тексте вопроса, мне кажется, что можно написать собственный поставщик

Мне в прошлом пришлось писать NuGet-пакеты (абстракцию и реализацию), отвечающие за шифрование/расшифровку секретной информации в любом текстовом файле. В частности, нас интересовал JSON, потому что мы не нашли для .NET 7 и .NET 8 коробочного бесплатного способа шифрования секций в конфигах JSON наподобие тому, как это имеется для конфигурационных файлов XML. Для случаев, когда приложение использует JSON конфиги, Майкрософт везде рекомендует использовать платные решения, вроде Vault для хранения секретов, тем самым вынося их из конфигов.

Поэтому мне пришлось самому написать пакеты, которые анализирует любой текст, находят в нём блоки секретов и в рантайме выполняют затребованную операцию: шифруют, расшифровывают или распаковывают все найденные секреты. Всё это делается через сертификаты хранилища уровня Local Machine или Curent User (смотря что указано в настройках конкретного секрета). Сейчас используем эти пакеты во всех наших проектах.

А по поводу организации конфигов... Обычно я разношу разные настройки по разным конфигурационным JSON-файлам, сохраняемым в подкаталоге .\Configurations. В рантайме, при построении IConfigurationRoot, загружаю те конфиги, которые либо являются общими для любого окружения, либо соответствуют целевому окружению. В процессе загрузки, через написанный мною метод расширения, выполняю расшифровку всех зашифрованных значений. А при считывании инфы из конфигов всегда делаю биндинги на соответствующие классы.

Набор конфигурационных файлов может выглядеть по разному, например:

serilog.json serilog.Development.json serilog.Staging.json serilog.Production.json crm.json crm.Development.json crm.Staging.json crm.Production.json messageBrokers.json messageBrokers.Development.json messageBrokers.Staging.json messageBrokers.Production.json и т.п.

Мне так удобней, чем когда имеется один общий огромный конфиг-файл (или один общий и по дополнительному на каждое окружение).

Саму конфигурацию в DI (Майкрософта или Autofac) я регистрирую просто как синглтон интерфейсов IConfigurationRoot и IConfiguration.

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

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

1

Сообщение от KebabGGbab Мне кажется, что для решения проблемы нужно писать свой поставщик.

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

1

Как я указал в тексте вопроса, мне кажется, что можно написать собственный поставщик. Правильно ли это?

Рано или поздно такие вопросы возникают у каждого разработчика. Судя по ответам в топике, это очевидно. Но в моем случае, было не так, я сначала решил хранить настройки ASP.NET MVC приложения в JSON, а не в WebConfig, и даже сделал свой собственный nuget-пакет (посмотреть можно тут), а потом уже появился ASP.NET Core, где вся конфигурация была реализована при помощи паттерна IOptions. Но моя реализация умела "сохранять" настройки, а не только "читать". Я и сейчас часто использую ее, причем не только на ASP.NET Core. Кстати, код открыт и, возможно, поможет вам начать свой пакет.

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

Так вот к чему я это всё. А к тому, что если вам действительно не хватает существующей реализации, и вы понимаете, что ваша сборка будет вам реально помогать, то ответ "да, почему бы и нет"...

1

Сообщение от KebabGGbab Мне кажется, что для решения проблемы нужно писать свой поставщик.

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

Ты точно решаешь реальную проблему?

1

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

0

Сообщение от KebabGGbab К примеру, сериализация перечислений в виде именований, а не значений. Для этого требуется использовать JsonStringEnumConverter, но поставщик конфигурации json видимо это делает за меня. Было бы всё отлично, но с .NET 9 пришла возможность задавать иные имена полям перечисления для сериализации. Для этого был добавлен JsonStringEnumMemberNameAttribute, который поставщик конфигураций json видимо не использует

Конфиги считываются из разных мест: из файлов настроек (json, xml, ini и т.д.), переменных окружения, аргументов командной строки и пр.
Один и тот же объект конфига может быть разбит на части и считываться кусками из разных мест в разных форматах.
Через это поставщики не занимаются десериализацией настроек в объекты конфига, они только предоставляют словарь строк ключ/значение, потому на стадии считывания файла конфига поставщик понятия не имеет какой на выходе должен быть тип. Следовательно, конвертеры не используются.

Десериализацией этих словарей в объекты уже занимется ConfigurationBinder, который понятия не имеет о формате хранилища откуда они были получены: он работает с ключами вида "Logging:LogLevel:Default" и значениями типа "Information", и использует обычную рефлексию, плюс где может — конвертеры типов (TypeConverter), которые применяет только для конвертации значений терминальных узлов ключа.
В примере выше — только для конвертации значения "Information" для свойства Default. Корневой узел и LogLevel создаст через обычный конструктор типа для соответствующего свойства (с небольшими исключениями для коллекций).

Если нужна кастомная десериализация, то для указанного типа надо писать свой TypeConverter из строки там уже прописывать нужную логику.

В репозитории открыта тема для расширения возможностей настроек этого байндера, но пока как-то вяло: https://github.com/dotnet/runtime/issues/83599

2

Лол, таки "просто указать правила сериализации" не прокатит. Занятно, хотя с точки зрения абстракций наверное это даже хорошо. Всё же JsonStringEnumConverter находится в совершенно другой сборке, нежели Microsoft.Extensions.Configuration.

Сообщение от kolorotur поставщики не занимаются десериализацией настроек в объекты конфига, они только предоставляют словарь строк ключ/значение

Сообщение от kolorotur Следовательно, конвертеры не используются.

Чуть поправлю уточню: конвертор используется на этапе считывания в словарь вида IDictionary<string, string?>, а дальше ноль понимания в какую модель потом эти данные будут пихаться. Если глянуть интерфейс IConfigurationProvider, там тоже ноль завязок на тип данных, только строки.

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

------------------------------

В сетях и всякие AI-chat вообще рекомендуют вводить промежуточную модель, считывать в неё и дальше заниматься мапингом. Не самое изящное решение, но зато железобетонное. Плюс задача не то чтобы рядовая. Обычно фигачать конфиги "как есть" и пофиг как они там выглядят. Я бы даже сказал что различные текстовые значения скорее даже вредят, т.к. усложняют понимание что к чему в процессе сопровождения. Понятное дело что порой источник задаём не мы, а смапить нужно на внутренние модели, то в этом случае я бы тоже разделял т.к. в случае чего поправить мапинг проще, чем ковырять логику с атрибутами.

Вовзращаясь к вопоросу ТСа -- написать свой поставщик отличное решение. Хотя лично я бы просто в лоб делал Read - Deserialize - Registration и забил.

2

Сообщение от Wolfdp конвертор используется на этапе считывания в словарь

Ну да, я имел в виду конвертеры для конечной модели, ака всякие JsonPropertyName-атрибуты.
Конвертация на этапе считывания там вида "как представить иерархию json в виде секция:секция:свойство" и "как int из json перевести в строку". А то что это значение в конце должно быть enum — тут уже, как вы подметили, понимания ноль.

1