+, для первого я как раз писал свой IServiceProvider, все интерфейсы обернув в моки и дав им какую-то тестовую логику

Но это трудно делается

Я ревьювил пару проектов и видел, что некоторые имплементят механизм, который ходит по транзитивным референсам и собирает в одну общую кучу классы, которые содержат bindings. Этот механизм просто в тестах подключали в OneTimeSetUp в базовом классе и всё. Он был гибким и переиспользовался во всех микросервисах.

Грубо говоря у тебя в солюшине 5 модулей, у каждого есть класс, который в ServiceCollection добавляет bindings. Механизм их находил и подгружал

грустное сообщение

Почему ConfigureAwait(false) идет не по умолчанию, если его рекомендуют использовать при вызове асинхронных методов ?

Это отличный вопрос

Видимо потому что раньше была другая мода на поведение по умолчанию, другие фреймворки и требования к ним

А потом из-за совместимости так пошло

Обратная совместимость

Все так привыкли, смысл менять

Та дело не в привыкли

А чтобы после миграции на новую версию ничего не ебнулось

Из статьи: Отсюда можно сформулировать общее правило: если вы пишете код уровня приложения, не используйте ConfigureAwait(false).

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

Это не отвечает на изначальный вопрос автора вопроса

Из той же статьи
Когда использовать ConfigureAwait(false)?

Это зависит от того, реализуете ли вы код уровня приложения или код библиотеки общего назначения.

При написании приложений обычно требуется некоторое поведение по умолчанию. Если модель приложения/среда (например, Windows Forms, WPF, ASP.NET Core) публикует специальный SynchronizationContext, почти наверняка этому есть веская причина: значит, код позволяет заботиться о контексте синхронизации для правильного взаимодействия с моделью приложения/средой. Например, если вы пишете, обработчик событий в приложении Windows Forms, тест в xUnit, или код в контроллере ASP.NET MVC, независимо от того, опубликовала ли модель приложения SynchronizationContext, вам нужно использовать SynchronizationContext при его наличии. Это значит, если используются ConfigureAwait(true) и await, обратные вызовы/продолжения отправляются обратно в исходный контекст — все идет как нужно. Отсюда можно сформулировать общее правило: если вы пишете код уровня приложения, не используйте ConfigureAwait(false)

Этим и отличаются библиотеки общего назначения. Они являются универсальными отчасти потому, что их не волнует среда, в которой они используются. Вы можете использовать их из веб-приложения, из клиентского приложения или из теста — это не имеет значения, так как код библиотеки является агностическим для модели приложения, в которой он может быть использован. Агностический также означает, что библиотека не будет делать что-либо для взаимодействия с моделью приложения, например, она не будет получать доступ к элементам управления пользовательского интерфейса, потому что библиотека общего назначения ничего о них не знает. Так как нет необходимости запускать код в какой-либо конкретной среде, мы можем избежать принудительного вызова продолжений/обратных вызовов к исходному контексту, и мы делаем это, используя ConfigureAwait(false), что дает нам преимущества в производительности и повышает надежность. Это приводит нас к следующему: если вы пишете код библиотеки общего назначения, используйте ConfigureAwait(false). Вот почему каждый (или почти каждый) await в библиотеках среды выполнения .NET Core использует ConfigureAwait(false); За несколькими исключениями, которые скорее всего являются багами, и будут исправлены. Например, этот PR исправил отсутствующий вызов ConfigureAwait(false) в HttpClient.

Конечно это не везде имеет смысл. Например, одним из больших исключений (или, по крайней мере, случаев, где нужно подумать) в библиотеках общего назначения является случай, когда эти библиотеки имеют API, которые принимают делегаты на вызов. В таких случаях, библиотека принимает потенциальный код уровня приложения от вызывающей стороны, что делает эти допущения для библиотеки ”общего назначения" весьма спорными. Представьте, например, асинхронную версию метода Where LINQ: public static async IAsyncEnumerable<T> WhereAsync(this IAsyncEnumerable<T> source, Func<T, bool> predicate). Должен ли predicate вызываться в исходном SynchronizationContext вызывающего кода? Это зависит от реализации WhereAsync, и это причина, по которой он может решить не использовать ConfigureAwait(false).

Даже в особых случаях придерживайтесь общей рекомендации: используйте ConfigureAwait(false) если вы пишете библиотеку общего назначения/app-model-agnostic код

Если коротко, то зависит от ситуации

В пятом дотнете кстати интересно