Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add analyzer and add bloody .ConfigureAwait() where needed 😅 #130

Closed
oskardudycz opened this issue Mar 17, 2022 · 3 comments · Fixed by #188
Closed

Add analyzer and add bloody .ConfigureAwait() where needed 😅 #130

oskardudycz opened this issue Mar 17, 2022 · 3 comments · Fixed by #188

Comments

@oskardudycz
Copy link
Owner

No description provided.

@devbrsa
Copy link

devbrsa commented Mar 20, 2022

You Don’t Need ConfigureAwait(false), But Still Use It in Libraries
Since there is no context anymore, there’s no need for ConfigureAwait(false). Any code that knows it’s running under ASP.NET Core does not need to explicitly avoid its context. In fact, the ASP.NET Core team themselves have dropped the use of ConfigureAwait(false)

https://blog.stephencleary.com/2017/03/aspnetcore-synchronization-context.html

@oskardudycz
Copy link
Owner Author

@devbrsa thanks for the feedback. Indeed we throw away some time ago .ConfigureAwait(false) in Marten, yet we had to bring it back because of MS Orleans, Blazor etc. having deadlock issues. I created this issue to remind myself of having a decision about that. I may drop this idea (I'd love to, as it's incredibly annoying).

@oskardudycz
Copy link
Owner Author

oskardudycz commented Dec 1, 2022

@devbrsa, I decided to do that in #188, as I already had deadlocks in testing code, plus it's good to set the example, as it's safer to have such code in core libraries. I didn't apply that to the business and API code.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants