azure-storage-net: Missing syncronous methods for dotnet core?

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.

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.

Please reconsider this - it’s making our porting over from net4x to netstandard much more difficult. Sync methods also have their uses, particularly with e.g. scripts, where you want instant feedback. Having to continually force results is a pain for us and reduces readability of our code.

The sync is not an option. Very well. But imagine I am a beginner and there’s a few documentation about Azure Storage and the usage of the synchronous methods. How should I guess on the usage of Async methods?

Microsoft release the libraries without properly documenting and explaining it :

There is any MS documentation on how to use Azure Tables with ASP.NET Core.

Look what kind of “documentation” has Microsoft on async methods: looks like some ugly auto-generated text without any example.

I need table api functions now, not sure why they cleaned up Blob, File and Queue and Cosmos but not Table.

It’s a real shame that nearly two years after this issue, it’s not been possible to revert this change. We’re still in the situation that the net framework version of the same version of the SDK has sync methods but the netstandard version does not (as well as various overloads of the Table Query SDK being removed).

Well, after enough discussion, following the lead set by HttpWebRequest we have decided to offer sync methods as sync-over-async. This is a time buffer for our users before we deprecate the sync APIs in future versions of the library.

@copernicus365 , to keep it simpler for people, particularly those who are already using the library, our Netstandard2.0 support which includes the feature parity between desktop and Netcore, will leave the methods as-is, in the same namespace / binary of the split-per-service packages(split packages are in preview at the moment). Naturally, we’ll need to echo guidance in our docs by the .NET team about the benefits of converting to async, and try to make as clear as possible that it’s sync-over-async under the covers.

Many thanks to everyone who took the time to chime in on this thread and give us feedback!

One related note - for existing people who are already using the sync methods on .NET Desktop, these will also be moving to sync-over-async. We’re modifying the codebase to use HttpClient everywhere (both in desktop and in .NET Core), which doesn’t offer any sort of true sync. This is to get away from having separate implementations of everything (one with HttpWebRequest and one with HttpClient), which has led to many bugs and behavior differences between the different implementations.

The big problem is, this is not a new API, and the original Azure storage API did have these synchronous methods. Not only that, we all depended on that original API, and many of us wrote loads of code against that original API with syncrhronous methods, and that was often even before async had even become an official part of the platform. (Remember the Async Targeting Pack anyone?, it wasn’t that long ago).

While I have zealously converted my code-bases to async as far and often as possible, there’s still good parts of many parts of our code pipelines (and that is always the problem with this, conversion causes beginning to end pipeline rewrite) that make synchronous calls. So I would suggest at least a compromise here. I mean it’s noble and all to use this time to strip out the old way of doing things, but it seems to me there could be a compromise that fulfills that goal while still allowing parity with the API as it has existed…

So why not provide an extra netstandard (only) library, named maybe WindowsAzure.Storage.Synchronous, that is made up of extension methods that expose the missing synchronous API calls? This way would unencumber the main library, and make it clear to anyone using the synchronous methods (which may require a using statement that even states something like using … .Synchronous) that this is not the best way going forward. Seems like this could be done fairly quickly, and allow millions of lines of code to upgrade quickly without unreasonably strong-arming them into updating end-to-end pipelines of code when the resources may not be there to do that.

I simply decided to not support Azure storage until the implementation is complete:)

Thanks, but it looks like I’m going to back out of this. I’m starting to find API differences other than just forcing sync, such as not finding an equivalent for CloudTable.CreateQuery.

This is a real shame as it really raises the entry requirements and makes it hard to move to .Net Core. 😦

Please try the latest version of Blob, File and Queue preview packages using Netstandard2.0 target and let us know if you see any issues.

What about Table?

I don’t understand how the mentioned CloudTable.CreateQuery fits into the sync/async discussion. This method seems to be CPU bound to me (not needing async version), why was it removed from Net Core implementation?

Indeed, I found this issue related to CloudTable.CreateQuery method: https://github.com/Azure/azure-storage-net/issues/491.

Hi,

Apologies for the delay in updates. Please try the latest version of Blob, File and Queue preview packages using Netstandard2.0 target and let us know if you see any issues.

Please make sure to review the BreakingChanges lists on the nuget packages before using them.

Thanks, Elham