Missing syncronous methods for dotnet core?

This might be a stupid question, but after adding version 7.2.1 to my dotnet core 1.1 netstandard 1.6.1 project there are only async methods available even though all “getting started” guides clearly contains syncronous versions of the methods.

Am I missing here or have they not been implemented yet for dotnet core?

Best regards

Håkan

[pemari-msft]

Hi @TechInceptions , @tidyui Can you clarify for us what your need is for the synchronous methods? Overall, sync is much less resource efficient than async and is not something that we recommend to our customers. You can always use .GetAwaiter.GetResult() if you need to block on the async calls.

We have had some conversations with the CLR team, who provided this guidance:

If you expose an asynchronous endpoint from your library, avoid exposing a synchronous method that just wraps the asynchronous implementation. Doing so hides from the consumer the true nature of the implementation, and it should be left up to the consumer how they want to consume the implementation. If the consumer chooses to block waiting for the asynchronous implementation to complete, that’s up to the caller, and they can do so with their eyes wide open. This is even more important for the “sync over async” case than it is for the “async over sync” case, because for “sync over async,” it can lead to significant problems with the application, such as hangs.

.NET Core team has chosen to not support a true sync api for the reasons listed above (resource consumption, etc.) Even if we implement a true sync, it would end up being sync over async at some level. For this reason, we believe that adding fake sync apis would be a hindrance and not a help to our customers. Please let us know if you have any feedback regarding this.

[TechInceptions]

You should support true sync because millions of operations, as coded in people’s libraries, ARE synchronous (for all kinds of reasons).

Regarding synchronicity, Ideally, APIs should have two paths: True Sync, and True Async.

In the .NET world, “sync over async” is filled with anxiety - one never knows how it’s going to turnout. Taking your library as an example, when you yanked the sync methods from the API surface, the 1st “patch” implementations will most likely be “sync over async”.

Regarding the “.GetAwaiter.GetResult()” work around, is it more reliable that “Task.Run (()=> … )” ?

I suspect “.GetAwaiter.GetResult()” will lead to deadlocks in UI chained scenarios.

If the consumer chooses to block waiting for the asynchronous implementation to complete, that’s up to the caller, and they can do so with their eyes wide open.

I have heard that argument before and I don’t buy it. Isn’t it better that the people with a better understanding of their own codebase do the tricky work of ensuring that something like “sync over async” works?

Mark my words, as we try to create a “better .NET” by forcing async, we are actually creating a “worse .NET” by generating “sync over async” as a direct consequence.