AsyncFixer 1.3.0
AsyncFixer helps developers in finding and correcting common async/await *misuses* (i.e., anti-patterns). AsyncFixer has been tested with thousands of open-source C# apps and successfully handles many corner cases. It currently detects 5 common kinds of async/await misuses and fixes 3 of them via program transformations.
Install-Package AsyncFixer -Version 1.3.0
dotnet add package AsyncFixer --version 1.3.0
<PackageReference Include="AsyncFixer" Version="1.3.0"> <PrivateAssets>all</PrivateAssets> <IncludeAssets>runtime; build; native; contentfiles; analyzers</IncludeAssets> </PackageReference>
paket add AsyncFixer --version 1.3.0
Here are async/await misuses (i.e., anti-patterns) that AsyncFixer can currently detect:
AsyncFixer01: Unnecessary async/await usage
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.
AsyncFixer02: Long-running or blocking operations inside an async method
Developers use some potentially long-running or blocking operations inside async methods even though there are corresponding asynchronous versions of these methods in .NET or third-party libraries. Some examples for such operations: Task.Wait(), Task.Result, StreamReader.ReadToEnd(), Thread.Sleep(), etc.
AsyncFixer automatically replaces those operations with their corresponding asynchronous operations and inserts an await expression. For instance, it converts Thread.Sleep(...) to await Task.Delay(...).
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.
AsyncFixer automatically converts void to Task.
AsyncFixer04: Fire & forget async call inside a using block
Inside a using block, developers insert a fire & forget async call which uses a disposable object as a parameter or target object. It can cause potential exceptions or wrong results. For instance, developers create a Stream in the using statement, pass it to the asynchronous method, and then Stream will be implicitly disposed via a using block. When the asynchronous method comes around to writing to Stream, it is (very likely) already disposed and you will have an exception.
AsyncFixer05: Downcasting from a nested task to an outer task.
Downcasting from a nested task (Task<Task>) to a Task or awaiting a nested task is dangerous. There is no way to wait for and get the result of the child task.
Visual Studio Extension
If you want AsyncFixer to work just in the IDE and to work as an analyzer on every project you open in Visual Studio, please download the VSIX extension instead of this NuGet package from here:
AsyncFixer - Visual Studio plugin
Here are async/await misuses (i.e., anti-patterns) that AsyncFixer can currently detect:
AsyncFixer01: Unnecessary async/await usage
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.
AsyncFixer02: Long-running or blocking operations inside an async method
Developers use some potentially long-running or blocking operations inside async methods even though there are corresponding asynchronous versions of these methods in .NET or third-party libraries. Some examples for such operations: Task.Wait(), Task.Result, StreamReader.ReadToEnd(), Thread.Sleep(), etc.
AsyncFixer automatically replaces those operations with their corresponding asynchronous operations and inserts an await expression. For instance, it converts Thread.Sleep(...) to await Task.Delay(...).
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.
AsyncFixer automatically converts void to Task.
AsyncFixer04: Fire & forget async call inside a using block
Inside a using block, developers insert a fire & forget async call which uses a disposable object as a parameter or target object. It can cause potential exceptions or wrong results. For instance, developers create a Stream in the using statement, pass it to the asynchronous method, and then Stream will be implicitly disposed via a using block. When the asynchronous method comes around to writing to Stream, it is (very likely) already disposed and you will have an exception.
AsyncFixer05: Downcasting from a nested task to an outer task.
Downcasting from a nested task (Task<Task>) to a Task or awaiting a nested task is dangerous. There is no way to wait for and get the result of the child task.
Visual Studio Extension
If you want AsyncFixer to work just in the IDE and to work as an analyzer on every project you open in Visual Studio, please download the VSIX extension instead of this NuGet package from here:
AsyncFixer - Visual Studio plugin
Release Notes
http://www.asyncfixer.com/CHANGELOG.md
Dependencies
This package has no dependencies.
Used By
NuGet packages
This package is not used by any NuGet packages.
GitHub repositories (16)
Showing the top 5 popular GitHub repositories that depend on AsyncFixer:
| Repository | Stars |
|---|---|
|
MvvmCross/MvvmCross
The .NET MVVM framework for cross-platform solutions, including Xamarin.iOS, Xamarin.Android, Windows and Mac.
|
|
|
exceptionless/Exceptionless
Exceptionless server and jobs
|
|
|
FoundatioFx/Foundatio
Pluggable foundation blocks for building distributed apps.
|
|
|
Baseflow/LottieXamarin
Render After Effects animations natively on Android, iOS, MacOS and TvOS for Xamarin
|
|
|
rotorgames/Rg.Plugins.Popup
Xamarin Forms popup plugin
|
