Add and chain ConfigureAwait(false) on all awaits to allow blocking on async methods without deadlocking #456
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
… on async calls without deadlocking in .NET Framework applications For general-purpose library code, adding ConfigureAwait(false) for every await allows .NET Framework applications that have a SynchronizationContext to call async code synchronously without deadlocking. The 'false' argument to ConfigureAwait allows the continuation to complete on any available thread in the pool and not just the original one. Since the context of the application is unknown to the library it can't use it anyway. To prevent future changes from reintroducing await's without a ConfigureAwait(false), the .editorconfig has been updated to treat these as errors and EnableNETAnalyzers added to the csproj. Tests are excluded from this rule as they are not expected to have a SynchronizationContext. How does this affect calling applications: * No impact on .NET Core apps. Async or synchronous calling is supported. * No impact on .NET Framework apps that do not rely on a SynchronizationContext. Async or synchronous calling is supported. * .NET Framework apps using SynchronizationContext (ASP.NET, WPF, Winforms) will no longer deadlock on synchronous calls as long as all await'ed async calls include ConfigureAwait(false). Reference: https://devblogs.microsoft.com/dotnet/configureawait-faq/#when-should-i-use-configureawait(false)
dhsu-atlas
changed the title
phnx47
reviewed
Mar 7, 2025
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #456 +/- ##
=======================================
Coverage 64.79% 64.79%
=======================================
Files 59 59
Lines 1909 1909
Branches 376 376
=======================================
Hits 1237 1237
Misses 567 567
Partials 105 105 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
Thank you! |
|
Published v1.28.0 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
For general-purpose library code, adding ConfigureAwait(false) for every await allows .NET Framework applications that have a SynchronizationContext to call async code synchronously without deadlocking. The 'false' argument to ConfigureAwait allows the continuation to complete on any available thread in the pool and not just the original one. Since the context of the application is unknown to the library it can't use it anyway. To prevent future changes from reintroducing await's without a ConfigureAwait(false), the .editorconfig has been updated to treat these as errors and EnableNETAnalyzers added to the csproj. Tests are excluded from this rule as they are not expected to have a SynchronizationContext.
How this affects different applications:
Reference: https://devblogs.microsoft.com/dotnet/configureawait-faq/#when-should-i-use-configureawait(false)