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.

Moe

May I ask you to delete confidential information and business code. Do you upload the basic framework of the project to Github, or you upload a new demo, the handling of NuGet packages is sometimes very troublesome, and sometimes it is also related to the language you use. – Eustashe

Can you tell us how you're using Blobs and Queues in your solution? You may be better off using SDK version 9.x which has all of the services in a single package. – Vickivickie

I think @GauravMantri-AIS and JasonPan are essentially asking the same question - how is this used. I have an entire ecosystem of approximately 40 different Azure web applications that use the same underlying framework which I myself provide as a NuGet package internally in our company. That NuGet package (.Net library written in C#) injects a logging capability using Azure tables, a mechanism for storing uploaded and dlownloaded files using Azure blobs, and a mechanism for handling multiple instances using Azure queues for IPC. – Moe

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/.

Radu

Thanks @Radu - I had suspected this, although I hadn't tried it. But what I am still baffled about is the namespace collision on the type CloudStorageAccount. My code uses the same (cached) CloudStorageAccount for tables, blobs, and files. But now it seems I need to generate one in the new table package and a different one in the new "all-the-other-storage" package. Which seems like an odd choice. Are you simultaneously using tables and one of the other storage types? And if so, how do you manage this collision? (other than through ugly aliasing?) – Moe