AsyncFixer

Both rules detect task type mismatches but address different structural problems:

// AsyncFixer05 - nested task: Task<Task>
Task task = Task.Factory.StartNew(() => DelayAsync());

// AsyncFixer06 - result discarded: Task<string> converted to Task
Func<Task> fn = () => GetDataAsync();  // GetDataAsync returns Task<string>

AsyncFixer can work directly in the IDE as an analyzer for every project you open. It also supports batch mode to correct misuses across documents, projects, or solutions.

Download the appropriate version for your IDE from the Visual Studio Marketplace:

• AsyncFixer for Visual Studio 2022-2026
• AsyncFixer for Visual Studio 2019
• AsyncFixer for Visual Studio 2017

To use AsyncFixer as a project-local analyzer that participates in builds and travels with your source control, install it as a NuGet package. This ensures the same rules are applied across your entire team.

Use the .NET CLI:

dotnet add package AsyncFixer

Or use the Package Manager Console in Visual Studio:

Install-Package AsyncFixer

You can control how AsyncFixer rules are reported by setting their severity in your .editorconfig file using the dotnet_diagnostic.<RuleID>.severity key.

Available severity levels:

• none: Disables the rule.
• suggestion: Reports the rule as a suggestion.
• warning: (Default behavior for many analyzers)
• error: Treats the rule violation as a build error.

[*.cs]
# Disable a rule
dotnet_diagnostic.AsyncFixer01.severity = none

# Treat as error
dotnet_diagnostic.AsyncFixer02.severity = error

# Treat as suggestion
dotnet_diagnostic.AsyncFixer03.severity = suggestion

If you need to ignore a specific instance of an AsyncFixer rule, use standard C# #pragma directives to disable and then restore the specific rule ID.

#pragma warning disable AsyncFixer01
async Task<int> Method() => await SomeTaskAsync();
#pragma warning restore AsyncFixer01

Release 2.0.0 introduced several new rules categorized under AsyncUsage. All rules in this release are emitted with a Warning severity by default. Use these Rule IDs to configure your analysis settings (e.g., to treat specific rules as errors or disable them).

| Rule ID | Category | Severity | Notes |
|---------|----------|----------|-------|
| AsyncFixer01 | AsyncUsage | Warning | Detects unnecessary async/await in async methods |
| AsyncFixer02 | AsyncUsage | Warning | Detects blocking calls inside async methods |
| AsyncFixer03 | AsyncUsage | Warning | Detects async void methods and delegates |
| AsyncFixer04 | AsyncUsage | Warning | Detects unawaited async calls in using blocks |
| AsyncFixer05 | AsyncUsage | Warning | Detects Task<Task> nested task issues |
| AsyncFixer06 | AsyncUsage | Warning | Detects Task<T> to Task implicit conversion |

Identifies methods that use the async/await keywords but do not actually require them (e.g., they simply return the result of another task). Removing these reduces the overhead of the async state machine.

Note: Do NOT remove async/await if the method contains:

• Exception handling (try/catch) around the await.
• Multiple await statements.
• Code inside a using or try block that depends on the task completion.

// ❌ Bad: Unnecessary async/await
async Task<int> GetValueAsync()
{
    return await _cache.GetAsync(key);
}

// ✅ Good: Return task directly
Task<int> GetValueAsync()
{
    return _cache.GetAsync(key);
}

Identifies async void methods and delegates that are not event handlers. async void is dangerous because unhandled exceptions will crash the process and they cannot be awaited by the caller. Use async Task instead.

// ❌ Bad: async void - exceptions will crash the process
async void ProcessDataAsync()
{
    await Task.Delay(1000);
    throw new Exception("Oops!"); // Crashes the app!
}

// ✅ Good: async Task - exceptions can be caught
async Task ProcessDataAsync()
{
    await Task.Delay(1000);
    throw new Exception("Oops!"); // Can be caught by caller
}

Detects dangerous downcasting when mixing async/await with older threading APIs like TaskFactory.StartNew. This often results in a Task<Task> where the outer await completes immediately without waiting for the inner task.

Recommended Fixes:

1. Use Task.Run() (Preferred).
2. Use .Unwrap() on the task.
3. Use a double await: await (await Task.Factory.StartNew(...));

// ❌ Bad: StartNew returns Task<Task>, outer await completes immediately
async Task ProcessAsync()
{
    Console.WriteLine("Hello");
    await Task.Factory.StartNew(() => Task.Delay(1000)); // Returns Task<Task>!
    Console.WriteLine("World");  // Prints immediately, doesn't wait 1 second
}

// ✅ Good: Use Task.Run()
async Task ProcessAsync()
{
    Console.WriteLine("Hello");
    await Task.Run(() => Task.Delay(1000));
    Console.WriteLine("World");  // Waits 1 second
}

Detects potentially long-running or blocking operations used inside async methods that have asynchronous equivalents. Using blocking calls in async contexts can lead to deadlocks and thread pool starvation.

Common Replacements:

// ❌ Bad: Blocking call can cause deadlocks
async Task ProcessAsync()
{
    var result = GetDataAsync().Result;  // Blocks!
    Thread.Sleep(1000);                   // Blocks!
}

// ✅ Good: Use async equivalents
async Task ProcessAsync()
{
    var result = await GetDataAsync();
    await Task.Delay(1000);
}