Рекомендуется вызывать ConfigureAwait для всего кода на стороне сервера

краткий ответ на ваш вопрос: нет. Вы не должны звонить ConfigureAwait(false) на уровне приложения, как это.

TL;DR версия длинного ответа: Если вы пишете библиотеку, где вы не знаете своего потребителя и не нуждаетесь в контексте синхронизации (который вы не должны в библиотеке, я считаю), вы всегда должны использовать ConfigureAwait(false). В противном случае потребители вашей библиотеки могут столкнуться с блокировками, используя асинхронные методы блокирующим способом. Это зависит от ситуация.

вот немного более подробное объяснение важности ConfigureAwait метод (цитата из моего блога):

когда вы ожидаете метода с ключевым словом await, компилятор генерирует кучу кода от вашего имени. Одна из целей этого действие заключается в обработке синхронизации с потоком UI (или main). Ключ компонентом этой функции является SynchronizationContext.Current что возвращает контекст синхронизации для текущего потока. SynchronizationContext.Current is заполняется в зависимости от среда в которой вы находитесь. The GetAwaiter метод задачи ищет SynchronizationContext.Current. Если текущий контекст синхронизации не null, продолжение, которое передается этому ожидающему, получит отправлено обратно в контекст синхронизации.

при использовании метода, который использует новый асинхронный язык особенности, в блокировке моды, вы в конечном итоге с тупиком, если у вас есть доступный SynchronizationContext. Когда вы потребляете такие методы в блокирующем режиме (ожидание задачи с Wait метод или принимать результат сразу от свойства результата Задача), вы будете блокировать основной поток одновременно. Когда в конце концов задача завершается внутри этого метода в threadpool, это собирается вызвать продолжение для публикации обратно в основной поток потому что SynchronizationContext.Current доступен и захвачен. Но здесь есть проблема: поток пользовательского интерфейса будет заблокирован и у вас тупик!

кроме того, вот две большие статьи для вас, которые именно для вашего вопроса:

• идеальный рецепт, чтобы стрелять себе в ногу-в конечном итоге с тупиком с помощью асинхронных функций языка C# 5.0
• асинхронные клиентские библиотеки .NET для вашего HTTP API и осознание плохих эффектов async/await

наконец, есть большое короткое видео от От Lucian Wischik именно на эту тему: методы асинхронной библиотеки должны рассмотреть возможность использования задачи.ConfigureAwait (false).

надеюсь, что это помогает.

самый большой недостаток, который я нашел с помощью ConfigureAwait (false), заключается в том, что культура потока возвращается к системному умолчанию. Если вы настроили культуру e.г...

<system.web>
    <globalization culture="en-AU" uiCulture="en-AU" />    
    ...

и вы размещаете на сервере, культура которого установлена в en-US, то вы найдете перед ConfigureAwait (false) называется CultureInfo.CurrentCulture вернется en-AU и после того, как вы получите en-US. т. е.

// CultureInfo.CurrentCulture ~ {en-AU}
await xxxx.ConfigureAwait(false);
// CultureInfo.CurrentCulture ~ {en-US}

Если ваше приложение делает что-либо, что требует культуры конкретное форматирование данных, тогда вам нужно будет помнить об этом при использовании ConfigureAwait(false).

у меня есть некоторые общие мысли о реализации Task:

1. задача одноразовая, но мы не должен использовать using.
2. ConfigureAwait был введен в 4.5. Task был введен в 4.0.
3. .NET Threads всегда используется для потока контекста (см. C# через CLR book), но в реализации по умолчанию Task.ContinueWith они не b/c было осуществлено что переключатель контекста дорог и он повернут мимо по умолчанию.
4. проблема заключается в том, что разработчик библиотеки не должен заботиться о том, нужен ли его клиентам поток контекста или нет, поэтому он не должен решать, течет ли контекст или нет.
5. [добавлено позже] тот факт, что нет авторитетного ответа и надлежащей ссылки, и мы продолжаем бороться с этим, означает, что кто-то не сделал свою работу правильно.

у меня есть несколько посты на эту тему, но мое мнение - в дополнение к хороший ответ Tugberk - это это вы должны включить все API асинхронно и в идеале поток контекста . поскольку вы выполняете асинхронность, вы можете просто использовать продолжения вместо ожидания, поэтому взаимоблокировка не будет вызвана, поскольку ожидание не выполняется в библиотеке, и вы сохраняете поток, поэтому контекст сохраняется (например, HttpContext).

проблема в том, что библиотека предоставляет синхронный API, но использует другой асинхронный API-следовательно, вам нужно использовать Wait()/Result в коде.