Azure CloudStorageAccount namespace conflict in various NuGet packages, and migration to newer Azure SDKs

Question

I know I may be somewhat late to this party, but remain baffled nonetheless.

We have for years been using the NuGet package WindowsAzure.Storage to work with Blobs, Tables, and Queues, in the context of .Net and using the .Net Azure SDKs.

In the lowest level of shared code in many Azure web apps we have developed, we have a pattern of caching the CloudStorageAccount we use to get the various clients needed for those storage entities. We get that storage account with the following C# code:

    CloudStorageAccount storageAccount = CloudStorageAccount.Parse(connectionString);

That "storageAccount" is cached and we use it throughout the app to get access to the various storage clients, namely CloudBlobClient, CloudTableClient, and CloudQueueClient, like this:

    CloudBlobClient blobClient = storageAccount.CreateCloudBlobClient();
    CloudQueueClient queueClient = storageAccount.CreateCloudQueueClient();
    CloudTableClient tableClient = storageAccount.CreateCloudTableClient();

Those clients are also cached, but that may not be relevant to this question.

There seems to be encouragement (although maybe not any deprecation warnings?) from Microsoft to move to the newer SDKs that are instead in the NuGet packages in Microsoft.Azure.Storage.Xxxxxx and/or Azure.Storage.Xxxxxxx, but those NuGet package hierarchies do not support tables, and only support Blobs and Queues (and Files, which I am not currently using).

Tables instead seem to be in a different hierarchy, namely Microsoft.Azure.Cosmos.Table.

But there seems to be a namespace collision on the type CloudStorageAccount between one declared type in Microsoft.Azure.Cosmos.Table and another declared with the same name in Microsoft.Azure.Storage.Common.

And then the even newer Azure.Storage.Xxxxxxxx libraries don't seem to have any support for tables.

Of course I can alias the types or always fully specify them, but this will mean I would have to rewrite my caching code (not the end of the world) but there is part of this whole exercise that makes me wonder if I am missing some key important concept in the nature of these various different storage entities. I'm also hesitant because it seems likely I could break some third-party dependencies. So the whole issue seems really thorny.

I would so appreciate any conceptual understanding, pointers to comprehensive learning documents, code examples, suggestions, or explanations. Tables are key for us, but I doubt we will be moving to the new Cosmos DB tables anytime soon.

Answer 1

This might not be the answer you're looking for, but we have been looking at this package update quite recently - we might have been the lucky ones out here, but ostensibly the new package Microsoft.Azure.Cosmos.Table has the same methods/signatures as the old WindowsAzure.Storage.Table used to have (and I strongly believe they actually just forked all the code as is). All we had to do is uninstall the old nuget package, install the new one, and then replace in all the solution the using Microsoft.WindowsAzure.Storage.Table lines with using Microsoft.Azure.Cosmos.Table, and it just worked like a charm.

You don't have to be using Cosmos DB at all, it's just in the package's name, but it still works/connects up perfectly to regular Storage Accounts.

Some (albeit very vague) information why Microsoft decided to move can be found here: https://azure.microsoft.com/en-us/blog/previewing-azure-sdks-following-new-azure-sdk-api-standards/.