Victor Grigoriu February 2016

ConfigureAwait(false) in WebAPI controller

Should SonarLint fire S3216 in an ASP.NET Web API controller? It seems that this rule is for desktop applications, in ASP.NET the context is totally different, there's no danger of deadlocks. Or am I missing something?

Answers


i3arnon February 2016

You should still use ConfigureAwait(false) in WebAPI when you don't need to capture the context.

ConfigureAwait controls whether to resume on the captured SynchronizationContext or not. It's true that this is a more painful issue in UI apps, but it's relevant everywhere there's a SynchronizationContext which is all UI apps and all asp.net apps.

In UI apps the resource SynchronizationContext manages is the single UI thread so you can deadlock if you block it. In asp.net apps the resource is the request context and you are able to deadlock on it as well.

You can avoid using ConfigureAwait in console applications or windows services, though it's still a good practice to keep using it where appropriate.


Tamas - SonarSource Team February 2016

@VictorGrigoriu, we are only checking if the output kind of a compilation unit is a DLL or not, and we report issues only in DLLs. You are right that we report on cases when in a DLL you still need to switch back to the original context. In general it's a very hard thing to figure out, but we could add a check for top level web app assemblies. We need to come up with a good way to do that or disable the rule by default to not generate false positives.

I've created a ticket to track this problem: https://jira.sonarsource.com/browse/SLVS-790.

Other options until we come up with a permanent solution: you can disable this rule locally on the given project if you feel it's an annoyance. To do that, you'll need to edit the project's ruleset file through "references/analyzers/open active rule set"

Post Status

Asked in February 2016
Viewed 3,962 times
Voted 10
Answered 2 times

Search




Leave an answer