AsyncFixer helps developers in finding and correcting common async/await misuses (anti-patterns). AsyncFixer was tested with hundreds of open-source C# apps and successfully handles many corner cases. Here are anti-patterns that AsyncFixer can detect:
1) AsyncFixer01: Unnecessary async/await Methods
There are some async methods where there is no need to use async/await keywords. It is important to detect this kind of misuse because adding the async modifier comes at a price. AsyncFixer automatically removes async/await keywords from those methods.
2) AsyncFixer02: Using Long-running Operations under Async Methods
Developers use some potentially long running or blocking operations under async methods even though there are corresponding asynchronous versions of these methods in .NET or third-party libraries. Some example for such operations: Task.Wait(), Task.Result, Task.WaitAll(...), StreamReader.ReadToEnd(...), Thread.Sleep(...), etc.
AsyncFixer automatically replaces these operations with their corresponding asynchronous operations and inserts 'await' expression. For instance, it converts 'Thread.Sleep(...)' to 'await Task.Delay(...)'.
3) AsyncFixer03: Fire & Forget Async Void Methods
Some async methods are 'fire & forget', which return void. Unless a method is only called as an event handler, it must be awaitable. Otherwise, it is a code smell because it complicates control flow and makes error detection & correction difficult.
4) AsyncFixer04: Fire & Forget Async Call In the Using Block
In an using block, developers use a fire & forget async call which uses disposable object as a parameter or target object. It can cause potential exception or wrong result. For instance, developers create a Stream in the using statement, pass it to the asynchronous method, and then stream will be implicitly disposed via using block. When the asynchronous method comes around to writing to the Stream, it is (very likely) already disposed and you will have an exception.
5) AsyncFixer05: Implicit Downcasting from Task<T> to Task
Implicit downcasting from Task<T> to Task is dangerous. There is no efficient way to get the result of the Task<T> after downcasting. It is even more dangerous to downcast from Task<Task> to Task.
The nuget package will work as a project-local analyzer that participates in builds. Attaching an analyzer to a project means that the analyzer travels with the project to source control and so it is easy to apply the same rule for the team. It also means that commandline builds report the issues reported by the analyzer. Download the nuget package from here: nuget.org/packages/AsyncFixer
v1.1.7 @ 04.22.2019: VS2019 support.
v1.1.5 @ 03.27.2017: Added a license. Fixed several bugs in fixing anti-patterns. VS2017 support.
v1.1.3 @ 03.22.2016: Depending on CodeAnalysis 1.0.0 instead of 1.1.1 due to compatibility issues for some users.
v1.1.2 @ 03.21.2016: Fixed false positives for new analyzers.
v1.1.0 @ 03.13.2016: Added 2 new code analyzers and improved accuracy of existing analyzers.
v1.0.0 @ 07.29.2015: 3 code analyzers to detect and fix very common async anti-patterns.