Menu
I stumbled on an issue (https://github.com/HTBox/allReady/issues/1313) at GitHub where they discussed about taking the ConfigureAwait(false) out of the code, claiming that, in ASP.NET Core
the call to
ConfigureAwait(false)is redundant and does nothing
Best I could find here is a “side note” in an answer (from Stephen Cleary, https://stackoverflow.com/a/40220190/2805831) telling that
ASP.NET Core no longer has a "context"
So, is ConfigureAwait(false) really unnecessary in ASP.NET Core (even if using full .Net Framework)? Does it have any real gain in performance in some cases or difference in the result/semantic?
EDIT: Is it different in this aspect if I am hosting it as a console application or in IIS?
537
NET Core you won't need to spread ConfigureAwait(false) all over your code. Almost! This is almost true, it is still recommended the utilization of ConfigureAwait(false) for libraries as a fallback if those libraries are used within a legacy framework. But for most of the cases yes, in .
False. It's needed when running on . NET Core for exactly the same reasons it's needed when running on . NET Framework.
As a general rule, every piece of code that is not in a view model and/or that does not need to go back on the main thread should use ConfigureAwait false. This is simple, easy and can improve the performance of an application by freeing the UI thread for a little longer.
ConfigureAwait(false) configures the task so that continuation after the await does not have to be run in the caller context, therefore avoiding any possible deadlocks.
ConfigureAwait only has effects on code running in the context of a SynchronizationContext which ASP.NET Core doesn't have (ASP.NET "Legacy" does).
General purpose code should still use it because it might be running with a SynchronizationContext.
ASP.NET Core SynchronizationContext
ConfigureAwait FAQ
167
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
