AsyncFixer 1.1.2

Release notes:
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.

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.

Usage:
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: AsyncFixer

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: https://visualstudiogallery.msdn.microsoft.com/03448836-db42-46b3-a5c7-5fc5d36a8308

Notes:
- The detection and fixing of more concurrency anti-patterns are being implemented.
- Please send your bug report or feedback to semih.okur@gmail.com
- Learn more information about these misuses from our website: LearnAsync.NET