Detecting Sync over Async Code in ASP.NET Core
Tags: dotnet, dotnetcore, aspnetcore, async
Published: 2019-09-11 21:23:41

---
title: Detecting Sync over Async Code in ASP.NET Core
published: true
tags: dotNET,dotNETCore,ASPNETCore, async
canonical_url: https://codeopinion.com/detecting-sync-over-async-code-in-asp-net-core/
---

![Sync over Async](https://codeopinion.com/wp-content/uploads/2019/09/lock-300x300.png)

It’s pretty easy to write some bad async code, especially when you first start using async/await. Async/await is pretty viral in .NET, which means it generally goes all the way through the stack. This can be challenging if you are trying to add async/await to an existing app and you usually end up adding sync over async code.

If you don’t use async/await correctly, and end up writing sync-over-async code, you’ll ultimately end up causing ThreadPool starvation.

## Sync over Async

The term refers to making an async call but not awaiting it. Often time this is caused by calling **.Wait()** or **.Result** on the returned **Task**.

{% gist https://gist.github.com/dcomartin/5ad28acd846cc319baf079032c5f3e08 %}

## Ben.BlockingDetector

Ben Adams wrote a Blocking Detector for ASP.NET Core.

Start by adding the NuGet package **[Ben.BlockingDetector](https://www.nuget.org/packages/Ben.BlockingDetector/)** to your csproj.

{% gist https://gist.github.com/dcomartin/88dcc456bc0cb8ab0ce854e249037372 %}

At the very beginning (or the higher the better) of your **Configure()** method in your Startup, add the **UseBlockingDetection()** extension method to the **IApplicationBuilder**.

{% gist https://gist.github.com/dcomartin/87edfca37d573755eb84c4c2bc5e1674 %}

That’s it. Really. Now when we run our application and hit the /sync-over-async route from the example above, a warning is logged in the console (or however you have logging configured).

[![](https://codeopinion.com/wp-content/uploads/2019/09/benblocking-1024x670.png)](https://codeopinion.com/wp-content/uploads/2019/09/benblocking.png)<figcaption>I’ve added the red arrow to point out our sync-over-async method in the call stack.</figcaption>

## Microsoft.VisualStudio.Threading.Analyzers

Another great tool is the [Microsoft.VisualStudio.Threading.Analyzers](https://www.nuget.org/packages/Microsoft.VisualStudio.Threading.Analyzers/) NuGet Package.

> Static code analyzer to detect common mistakes or potential issues regarding threading and async coding.

Simply add it the PackageReference to your csproj and by default, you will immediately be getting warnings about sync over async calls. Here’s a screenshot in JetBrains Rider (which also can use Roslyn analyzers) that is notifying us of the issue.

[![](https://codeopinion.com/wp-content/uploads/2019/09/analyzer-1024x450.png)](https://codeopinion.com/wp-content/uploads/2019/09/analyzer.png)

Are you using any other analyzers or packages to detect blocking or problematic async code? Let me know in the comments or on Twitter.

Related Posts: I’ve also written a post on [Lazy Async](https://codeopinion.com/lazy-async/) which try’s to solve the issue of deferring doing IO until it’s first needed.

[Follow @codeopinion](https://twitter.com/codeopinion?ref_src=twsrc%5Etfw)

The post [Detecting Sync over Async Code in ASP.NET Core](https://codeopinion.com/detecting-sync-over-async-code-in-asp-net-core/) appeared first on [CodeOpinion](https://codeopinion.com).