return success ? new JsonResult($"Update successful {document.Id}") : new JsonResult("Update was not successful")
Т.е результат вроде бы 200 ОК, а вроде и нет.
Иногда сталкиваюсь с преимущественно старыми системами, которые возвращают ошибки с 200-м кодом ответа Http. Столько "радости" с ними интегрироваться.
В этом случае правильнее использовать наследников StatusCodeResult, например BadRequestResult,OkResult.
Как по мне, так использование опций с DataAnnotation-атрибутами это самое лучшее решение. За некоторыми нюансами, что ошибка валидации будет происходит где-то в рантайме, только при запросе опций через DI. Но это обещают исправить в .NET Core 3.0
Если нет желания использовать опции, можно реализовать что-то типа IStartupFilter и там проверять конфигурацию. Но мне кажется это то еще извращение.
Получается, что при сборке бинарников приложения там будут файлы конфигураций для всех environment и нужно как-то вручную удалять лишние?
Да, действительно при публикации приложения, все файлы .json попадают в выходную папку, не смотря на то, что в их свойствах стоит опция Do not copy. Чтобы решить эту проблему можно добавить в .csproj MSBuild conditional constructs с , но это не выглядит прямым решением проблемы.
Есть ли способы комбинирования настроек через переменные окружения и через файлы?
Есть. Вспомним пример:
{
"Settings": {
"Key": "I am options"
}
}
Будет приведен к плоскому виду:
Settings:Key = I am options
Если создать переменную окружения с ключом Settings__Key, она заменит настройку из файла. Подробнее здесь.
К сожалению не могу ответить за разработчиков ASP.NET Core. Мне помнится в .NET Framework не было удобных инструментов для работы с переменными окружения. Или писать свою реализацию сервиса для получения настроек из переменной окружения. Или делать наследника ConfigurationBuilder, и делать чтение переменных там. Поправьте если ошибаюсь.
Вы как-то лихо смешиваете ASP.NET Core и .NET Core в статье.
Действительно лихо. Причина в том, что как вы уже писали пакет Microsoft.Extensions не зависит от ASP.NET Core. Но проблемы, которые я описывал касаются использования конфигурации в ASP.NET Core. В приложениях .NET Core и .NET Framework они могут и не возникнуть, потому что у нас нет волшебного метода CreateDefaultBuilder, который скрывает за кулисами всю рутинную работу.
Да там без лицензий все хорошо. Раннер для .http файлов можно запускать из докера (jetbrains/intellij-http-client)
Почему был выбран
JsonResult?Т.е результат вроде бы 200 ОК, а вроде и нет.
Иногда сталкиваюсь с преимущественно старыми системами, которые возвращают ошибки с 200-м кодом ответа Http. Столько "радости" с ними интегрироваться.
В этом случае правильнее использовать наследников
StatusCodeResult, напримерBadRequestResult,OkResult.Это легко проверить.
К примеру при чтении массива из appsettings.json получим такой плоский вид:
При чтении из appsettings.Development.json:
В итоге в конфигурации будет:
Как по мне, так использование опций с DataAnnotation-атрибутами это самое лучшее решение. За некоторыми нюансами, что ошибка валидации будет происходит где-то в рантайме, только при запросе опций через DI. Но это обещают исправить в .NET Core 3.0
Если нет желания использовать опции, можно реализовать что-то типа IStartupFilter и там проверять конфигурацию. Но мне кажется это то еще извращение.
Да, вы отчасти правы. Для массивов, элементы с одинаковыми индексами будут заменены, с уникальными индексами будут добавлены. Добавлю в статью.
Да, действительно при публикации приложения, все файлы .json попадают в выходную папку, не смотря на то, что в их свойствах стоит опция Do not copy. Чтобы решить эту проблему можно добавить в .csproj MSBuild conditional constructs с , но это не выглядит прямым решением проблемы.
Есть. Вспомним пример:
Будет приведен к плоскому виду:
Если создать переменную окружения с ключом Settings__Key, она заменит настройку из файла. Подробнее здесь.
Действительно лихо. Причина в том, что как вы уже писали пакет Microsoft.Extensions не зависит от ASP.NET Core. Но проблемы, которые я описывал касаются использования конфигурации в ASP.NET Core. В приложениях .NET Core и .NET Framework они могут и не возникнуть, потому что у нас нет волшебного метода CreateDefaultBuilder, который скрывает за кулисами всю рутинную работу.