конечно, кто ж спорит

У меня был проект в котором MSMQ в перемешку с самопальной шиной использовались, вот это боль

Всем привет. Хочу уточнить вопрос: Фетиш на все await'ы во всем коде писать ConfigureAwait(false) в ASP.Net Core не есть супер хорошо?

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

в аспнет коре смысла нет

Более того. Я правильно понимаю, что если делаем ConfigureAwait(false) в контроллере, то код после await'a потеряет HttpContext?

нет конечно

HttpContext это не контекст синхронихации

Не должен. AsyncLocal же - он не должен теряться за авейтами

When writing applications, you generally want the default behavior (which is why it is the default behavior). If an app model / environment (e.g. Windows Forms, WPF, ASP.NET Core, etc.) publishes a custom SynchronizationContext, there’s almost certainly a really good reason it does: it’s providing a way for code that cares about synchronization context to interact with the app model / environment appropriately. So if you’re writing an event handler in a Windows Forms app, writing a unit test in xunit, writing code in an ASP.NET MVC controller, whether or not the app model did in fact publish a SynchronizationContext, you want to use that SynchronizationContext if it exists. And that means the default / ConfigureAwait(true). You make simple use of await, and the right things happen with regards to callbacks/continuations being posted back to the original context if one existed. This leads to the general guidance of: if you’re writing app-level code, do not use ConfigureAwait(false). If you think back to the Click event handler code example earlier in this post:

the setting of downloadBtn.Content = text needs to be done back in the original context. If the code had violated this guideline and instead used ConfigureAwait(false) when it shouldn’t have: bad behavior will result. The same would go for code in a classic ASP.NET app reliant on HttpContext.Current; using ConfigureAwait(false) and then trying to use HttpContext.Current is likely going to result in problems.

https://devblogs.microsoft.com/dotnet/configureawait-faq/ это чел из тимы дотнета написал, можно пруфридить. в целом ты прав, если это не код библиотеки то ConfigureAwait(false)  ни в коем случае писать не надо

Это для старого мвц

да я умею читать, там же написано класик

в коре ж убрали контекст синхронизации если не путаю? там по идее вообще ничего не поменяется?

No. It guarantees it won’t be queued back to the original context… but that doesn’t mean the code after an await task.ConfigureAwait(false) won’t still run in the original context. That’s because awaits on already-completed awaitables just keep running past the await synchronously rather than forcing anything to be queued back. So, if you await a task that’s already completed by the time it’s awaited, regardless of whether you used ConfigureAwait(false), the code immediately after this will continue to execute on the current thread in whatever context is still current.

насколько я понимаю

Вот хз убрали ли или нет. Если контекста вообще нет, то зачем оставили ConfigureAwait если ему нечего захватывать?)

А как связано наличие ConfigureAwait с тем, что что-то где-то убрали?

Хттп контекст в коре теперь лежит в асинк локале внутри хттп контекст аксесора