Why is it recommended we call ConfigureAwait(false) on every Task we await in our handlers? In our established .NET Framework apps, we are using the NServiceBus.Host and in our newer apps in development we are using the generic host with .NET Core. There is no SynchronizationContext while the handlers are running in our Framework endpoints and I am confirming this is the same in our Core endpoints, so what good does the ConfigureAwait(false) do us? I would like to avoid it if it is not adding benefit as otherwise it just adds noise to the code.
Hi Tom,
Short answer: You are free to remove ConfigureAwait(false) from your handler code and the code hierarchy there should you wish to do so.
Longer answer:
At the end of the day it boils down to a very philosophical viewpoint. I prefer to be explicit about my code and I got burned by reusing my code or other people reusing my code. Suddenly, the code that was previously to be known to only execute under an environment with special conditions is now executed in another environment and there those previous assumptions no longer hold up. That’s why I always go with a simple rule:
- Does the code ever need to context capture?
- No →
ConfigureAwait(false) - Yes → just
await
- No →
With that, I have never run into any problems with my async code, and I’ll stick to that. But of course as long as people are aware of the caveats you can stick to whatever approach that works for you. I’m personally so used to write ConfigureAwait(false) that it is not noise anymore to me. In fact, when I don’t see it my spider senses immediately start tingling and I start looking for potential bugs in the code base :). And I have found quite a few over the years even in Microsoft SDKs…
Microsoft has great guidance about ConfigureAwait in case. It is well worth a read
Regards
Daniel
1 Like