Как стать автором
Обновить

Комментарии 10

Честно признаюсь - меня немного удивляет как .net разрабы умудрились проигнорировать фичу, которая в документации по ASP.NET находится в разделе fundamentals.

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

Да уж, я тут бесился, что из кастомного конфиг провайдера не то, что ServiceProvider, так даже другие, ранее по цепочке объявленные конфиг-провайдеры недоступны, а автор просто молча сделал лишний .Build(), и даже не упомянул об этом.

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

Для вас этой строчки не существует?

Как ни прискорбно, но о базовых фичах .NET знают не многие. И городят огород.

Все хорошо, но почему биндинг? Прям как по стеклу гвоздем.

То есть у вас не было ни одного хотя бы мидл разработчика, который бы вам сказал, что вы все не правильно делаете?

В одном продукте мы вынесли всю конфигурацию в Azure Blob, где храним json файлы в иерархии с возвратом по url. Этот url прописываем в appsettings проекта. Разные url для разных env и проектов. Написали провайдер и встроили в систему Configuration. Также написали UI где можно редактировать эти файлы. Основное преимущество - быстрая правка конфигурацияи без деплоймента. Если пойти дальше, можно на основе этого запилить feature flags, чтобы возвращалась конфигурация не только по url, но и по контексту.

Это уже сделано в Spring Cloud Config, и даже упоминалось на хабре.

Сначала добавим файл:
builder.Configuration.AddJsonFile("appsettings.json");
Затем переменные окружения с нашим префиксом:
builder.Configuration.AddEnvironmentVariables("MY_");

Зачем добвлять файлы вручную, если сам ASP.NET Core добавляет их по-умолчанию?

Зарегистрируйтесь на Хабре, чтобы оставить комментарий