ConfigureAwait(false) relevant in ASP.NET Core?

.net asp.net-core async-await

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?

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.)

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.

@JoeWhite Ok, edited the question. Is it different if my ASP.NET Core app is in IIS?

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.)

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. stackoverflow.com/questions/28221508/…

Paulo Morgado

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

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.

@Morgado, is it true even if the app is hosted in IIS?

An ASP.NET Core app is not hosted in IIS. IIS is acting just as a reverse proxy.

I've updated the answer with a recent post from Stephen Cleary. But, yes, ASP.NET Core is ASP.NET Core.

@NamNgo. Appreciate this is an old post now but Stephen Cleary clarifies this in one of the questions 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)"

ConfigureAwait(false) relevant in ASP.NET Core?

Follow WeChat

Want to stay one step ahead of the latest teleworks?

相似问题

Platform

Support

Contact US