165

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?

Community
  • 1
  • 1
Pedro Lorentz
  • 2,146
  • 2
  • 13
  • 19
  • 9
    This depends on where you were planing to use it. If you wanted to use it directly in your ASP.NET Core application, then no you don't have to call it (you didn't had to call it in ASP.NET legacy neither iirc). But if you write a library, then you should always use `ConfigureAwait(false)`, as the library can be consumed by different applications (ASP.NET Core, WPF, UWP, Console etc.) – Tseng Feb 06 '17 at 00:08
  • 1
    ASP.NET Core runs as a console application by default, and AFAIK console applications don't have a SynchronizationContext, so yes, this sounds reasonable for a default ASP.NET Core application, even with the full Framework. – Joe White Feb 06 '17 at 00:13
  • @JoeWhite Ok, edited the question. Is it different if my ASP.NET Core app is in IIS? – Pedro Lorentz Feb 06 '17 at 10:20
  • 3
    An ASP.NET Core app running in IIS still runs as a console application -- the only difference is that IIS is starting up and shutting down instances of your app (the same way it would have managed instances of the ASP.NET worker process in classic ASP.NET). It wouldn't change any thread-related behavior inside your ASP.NET app. (The only reason I specified "by default" is that you could, for example, host ASP.NET Core inside a GUI app, and in that case you *would* have to think about the synchronization context.) – Joe White Feb 06 '17 at 14:04
  • Note `ConfigureAwait(false)`, while *relevant* in ASP.NET classic, is by no means *necessary*. It's a tradeoff: it kinda mitigates some sync-over-async deadlocks (which are design flaws anyway--they don't exist unless someone does something dumb) and occasionally has a ~microsecond performance boost by not reloading context. At the cost of not being able to depend on context, and having `ConfigureAwait` all through your code. https://stackoverflow.com/questions/28221508/asynchrony-and-thread-culture/28227165#28227165 – Dax Fohl Mar 20 '18 at 17:17
  • Is there any official link that says that there is no synchronization context in net core? Msdn? – Royi Namir Jul 16 '19 at 19:53

1 Answers1

180

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

Paulo Morgado
  • 14,111
  • 3
  • 31
  • 59
  • 23
    Just want to put a slight clarification, ASP.NET in a non core environment does have a sync context, but ASP.NET core does not. – Scott Chamberlain Feb 05 '17 at 23:48
  • @Morgado, is it true even if the app is hosted in IIS? – Pedro Lorentz Feb 06 '17 at 10:22
  • 15
    An ASP.NET Core app is not hosted in IIS. IIS is acting just as a reverse proxy. – Paulo Morgado Feb 06 '17 at 15:48
  • @PauloMorgado How about asp.net core targeting .net461? Does it still have SynchronizationContext? – Nam Ngo Apr 05 '17 at 00:32
  • 3
    I've updated the answer with a recent post from Stephen Cleary. But, yes, ASP.NET Core is ASP.NET Core. – Paulo Morgado Apr 05 '17 at 06:15
  • 18
    @NamNgo. Appreciate this is an old post now but Stephen Cleary clarifies this in one of the [questions](http://blog.stephencleary.com/2017/03/aspnetcore-synchronization-context.html#comment-3582687662) on the post that Paulo linked above. _"it's the framework (ASP.NET Core as opposed to ASP.NET Classic) that determines the SynchronizationContext, not the runtime (.NET Core as opposed to .NET 4.6.2)"_ – Gavin Sutherland Oct 25 '17 at 09:41
  • 1
    The question is clearly about ASP.NET Core, but I would add that even the app using the framework may theoretically create and configure its own SynchronizationContext, or a weird library may do so. If you are the app's developer, you should know about any such things, and likely, no such craziness is in the app. If you are a library developer, you should use ConfigureAwait even if the library is meant to be used with ASP.NET Core, or document that its use with a synchronization context is not supported. – Palec Dec 21 '22 at 10:39