{"id":19100930,"url":"https://github.com/semihokur/AsyncFixer","last_synced_at":"2025-04-18T18:31:14.478Z","repository":{"id":37507701,"uuid":"329191891","full_name":"semihokur/AsyncFixer","owner":"semihokur","description":"Advanced async/await Diagnostics and CodeFixes for C#","archived":false,"fork":false,"pushed_at":"2022-12-10T00:10:50.000Z","size":520,"stargazers_count":149,"open_issues_count":12,"forks_count":12,"subscribers_count":9,"default_branch":"main","last_synced_at":"2024-03-27T23:21:18.329Z","etag":null,"topics":["async-await","roslyn-analyzers"],"latest_commit_sha":null,"homepage":"","language":"C#","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/semihokur.png","metadata":{"files":{"readme":"README.md","changelog":"CHANGELOG.md","contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2021-01-13T04:19:22.000Z","updated_at":"2024-03-25T16:21:14.000Z","dependencies_parsed_at":"2023-01-26T00:46:50.010Z","dependency_job_id":null,"html_url":"https://github.com/semihokur/AsyncFixer","commit_stats":null,"previous_names":[],"tags_count":5,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/semihokur%2FAsyncFixer","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/semihokur%2FAsyncFixer/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/semihokur%2FAsyncFixer/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/semihokur%2FAsyncFixer/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/semihokur","download_url":"https://codeload.github.com/semihokur/AsyncFixer/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":223783094,"owners_count":17201905,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["async-await","roslyn-analyzers"],"created_at":"2024-11-09T03:53:04.067Z","updated_at":"2025-04-18T18:31:14.471Z","avatar_url":"https://github.com/semihokur.png","language":"C#","readme":"AsyncFixer helps developers in finding and correcting common `async/await` *misuses* (i.e., anti-patterns). It currently detects 5 common kinds of async/await misuses and fixes 3 of them via program transformations. AsyncFixer has been tested with thousands of open-source C# projects and successfully handles many corner cases. It is also one of the most common analyzers used in C# projects from Microsoft.\r\n\r\nAsyncFixer will work just in the IDE and work as an analyzer on every project you open in Visual Studio. It can also operate in batch mode to correct all misuses in the document, project, or solution. You can download the VSIX from [here](https://visualstudiogallery.msdn.microsoft.com/03448836-db42-46b3-a5c7-5fc5d36a8308).\r\n\r\nIf you want AsyncFixer to deploy as a NuGet package and work as a project-local analyzer that participates in builds, you can use the nuget package. 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. You can download the nuget package from [here](https://www.nuget.org/packages/AsyncFixer).\r\n\r\nHere are `async/await` *misuses* (i.e., anti-patterns) that AsyncFixer can currently detect:\r\n\r\n### AsyncFixer01: Unnecessary async/await usage\r\n\r\nThere 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.\r\n\r\n![asyncfixer-1.gif](https://raw.githubusercontent.com/semihokur/AsyncFixer/main/img/asyncfixer-1.gif)\r\n\r\n### AsyncFixer02: Long-running or blocking operations inside an async method\r\n\r\nDevelopers 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.\r\n\r\nAsyncFixer automatically replaces those operations with their corresponding asynchronous operations and inserts an `await` expression. For instance, it converts `Thread.Sleep(...)` to `await Task.Delay(...)`.\r\n\r\n![asyncfixer-2.gif](https://raw.githubusercontent.com/semihokur/AsyncFixer/main/img/asyncfixer-2.gif)\r\n\r\n### AsyncFixer03: Fire-and-forget *async-void* methods and delegates\r\n\r\nSome async methods and delegates are fire-and-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. Unhandled exceptions in those *async-void* methods and delegates will crash the process as well.\r\n\r\nAsyncFixer automatically converts `void` to `Task`.\r\n\r\n![asyncfixer-3.gif](https://raw.githubusercontent.com/semihokur/AsyncFixer/main/img/asyncfixer-3.gif) \r\n\r\n### AsyncFixer04: Fire-and-forget async call inside an *using* block\r\n\r\nInside a `using` block, developers insert a fire-and-forget async call which uses a disposable object as a parameter or target object. It can cause potential exceptions or wrong results. Here is an example:\r\n\r\n```\r\nstatic void foo()\r\n{\r\n    var newStream = new FileStream(\"file.txt\", FileMode.Create);\r\n    using (var stream = new FileStream(\"newfile.txt\", FileMode.Open))\r\n    {\r\n        newStream.CopyToAsync(stream);\r\n    }\r\n}\r\n```\r\nWe copy the contents of the file to another file above. If the file size is big enough to make `CopyToAsync` take non-trivial duration, we will have `ObjectDisposedException` because `Stream` will be implicitly disposed due to the `using` block before `CopyToAsync` is finished. To fix the issue, we need to await  asynchronous operations involving disposable objects inside `using` blocks:\r\n```\r\n    await newStream.CopyToAsync(stream);\r\n```\r\n\r\n### AsyncFixer05: Downcasting from a nested task to an outer task.\r\n\r\nDowncasting from a nested 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. This usually occurs when mixing `async/await` keywords with the old threading APIs such as `TaskFactory.StartNew`. Here is an example: \r\n\r\n```\r\nasync Task foo()\r\n{\r\n    Console.WriteLine(\"Hello\");\r\n    await Task.Factory.StartNew(() =\u003e Task.Delay(1000)); // StartNew call returns a nested task: Task\u003cTask\u003e\r\n    Console.WriteLine(\"World\");\r\n}\r\n```\r\nA developer might expect one-second latency between \"Hello\" and \"World\" lines. However, those strings will be printed instantaneously without any latency. The reason is that we await a nested task, which is the return type of `StartNew` call. When we await the nested task, the return value is the inner task that is the result of `Task.Delay` call. As we do not await the inner task, we do not see the effect of the delay call. There are three possible fixes: \r\n\r\n1. We can await the inner task as well: \r\n\r\n```\r\nawait (await Task.Factory.StartNew(() =\u003e Task.Delay(1000)));\r\n```\r\n\r\n2. We can use `Unwrap` to expose the inner task to the `await` expression:\r\n\r\n```\r\nawait Task.Factory.StartNew(() =\u003e Task.Delay(1000)).Unwrap();\r\n```\r\n\r\n3. If you do not have reasons to use `TaskFactory.StartNew` such as `TaskCreationOptions` and a custom `TaskScheduler`, we should always use `Task.Run` to automatically unwrap the inner task.\r\n\r\n```\r\nawait Task.Run(() =\u003e Task.Delay(1000));\r\n```\r\n","funding_links":[],"categories":["others","Popular Analyzers"],"sub_categories":["Async/multithreading"],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fsemihokur%2FAsyncFixer","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fsemihokur%2FAsyncFixer","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fsemihokur%2FAsyncFixer/lists"}