You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Treat missing .ConfigureAwait(false) as errors (and fix) (#633)
I enabled the new .NET Analyzer for the project and then used an Editor
Config rule to treat CA2007 as an error. This diagnostic is for any
awaited task that does not have an explicit trailing
`.ConfigureAwait(false)` call, an annoying but very necessary
configuration for asynchronous .NET library code (such as OmniSharp).
The bugs caused by these missing calls are strange. In the case of
PowerShell Editor Services, an LSP server using OmniSharp and powering
the PowerShell Extension for VS Code, it showed up as a hang when the
server executed user code that used objects from `System.Windows.Forms`.
This is because that .NET library sets its own synchronization context,
which is exactly where `ConfigureAwait(continueOnCapturedContext:
false)` comes into play. The default value is `true` which roughly means
that the awaited tasks will only run on their own context. So when the
context is changed (because of `System.Windows.Forms` or other code
introducing a new synchronization context) the task will never be
continued, resulting in this hang. By configuring this to `false` we
allow the tasks to continue regardless of the new context.
See this .NET blog post for more details: https://devblogs.microsoft.com/dotnet/configureawait-faq/
Note that elsewhere in the codebase we've been very careful to set it to
false, but we've not been perfect. Treating this diagnostic as an error
will allow us to be as perfect as possible about it.
0 commit comments