CloudStorageAccount ambiguous with Microsoft.Azure.Storage

[SA-Support]

Hello,

I am having issues porting our existing WindowsAzure-based project into using Microsoft.Azure.Storage.* and Microsoft.Azure.Cosmos.Table (1.0.5, .NET Core 2.2). For queues, blob and files the CloudStorageAccount class can be shared. The Microsoft.Azure.Cosmos.Table package is extending the CloudStorageAccount class with CreateCloudTableClient(). It seems impossible now to re-use a CloudStorageAccount that is created using Microsoft.Azure.Storage.*. How should I work with a project referencing both queues and tables sharing the same CloudStorageAccount object? The Microsoft.Azure.Storage.* version also has properties like TableEndpoint, so it does not make any sense to me what I am doing wrong. Also the Microsoft documentation seems to lack information about using these new splitted NuGet packages, and still uses the WindowsAzure.Storage packages. Is this still preview stuff and not suited for production code?

Thank you.

Errors visible: cannot convert from 'Microsoft.Azure.Storage.CloudStorageAccount' to 'Microsoft.Azure.Cosmos.Table.CloudStorageAccount'

[biltongza]

I've done this as a workaround:

using BlobCloudStorageAccount = Microsoft.WindowsAzure.Storage.CloudStorageAccount;
using TableCloudStorageAccount = Microsoft.Azure.Cosmos.Table.CloudStorageAccount;

blobCloudStorageAccount = BlobCloudStorageAccount.Parse(Config.StorageConnectionString);
tableCloudStorageAccount = TableCloudStorageAccount.Parse(Config.StorageConnectionString);
blobClient = blobCloudStorageAccount.CreateCloudBlobClient();
queueClient = blobCloudStorageAccount.CreateCloudQueueClient();
tableClient = tableCloudStorageAccount.CreateCloudTableClient();

[VladimirKhvostov]

I cannot agree more with original poster. Having both Microsoft.Azure.Cosmos.Table.CloudStorageAccount and Microsoft.Azure.Storage.CloudStorageAccount made super challenging to upgrade.

[ghost]

The best way I have found is to use your own "conversion extension class". Use it to exchange the CloudStorageAccount instances between the Microsoft.Azure.Storage & Microsoft.Azure.Cosmos namespaces.

I have tried the Json route (Storage -> Json -> Cosmos & vice versa), but this seems to have some challenges, especially when used with System.Text.Json serializers .

[allxiao]

There is no easy way to convert a Storage.CloudStorageAccount from/to Cosmos.CloudStorageAccount.

• Storage.CloudStorageAccount --> Cosmos.CloudStorageAccount Key field in the source account is marked as internal, so you cannot rebuild the credential for the target account
• Cosmos.CloudStorageAccount --> Storage.CloudStorageAccount Source account doesn't parse or expose Blob/Queue/File endpoints

This is a blocker in our migration from the all-in-one Microsoft.WindowsAzure.Storage package to the split ones.

It seems the only way is to create two instances of storage account from Storage and Cosmos. However, now you need to maintain two copies of the initialization logic, key/SAS rotation logic, etc, because they are different types, just like cosmos package has a lot of duplicated code for the CloudStorageAccount from the Storage.Auth package.

It may be better if we move this to Microsoft.Azure.Storage.Common and implement the extension method CreateCloudTableClient in Cosmos library, to make the migration more smooth.

[ghost]

It may be better if we move this to Microsoft.Azure.Storage.Common and implement the extension method CreateCloudTableClient in Cosmos library, to make the migration more smooth.

That would be one way to go.

[pilou64]

It may be better if we move this to Microsoft.Azure.Storage.Common and implement the extension method CreateCloudTableClient in Cosmos library, to make the migration more smooth.

+1

[CaCTuCaTu4ECKuu]

OMFG I wanted to say that classes in Microsoft.Azure.Cosmos.Table are duplicating ones from Microsoft.Azure.Storage and ask for fixing it but apparently this was not a mistake but someone's genius decision. As I understand from #3 Cosmos DB team are goind crazy and if year later it's still like this I dont see anyone there will do something to fix this stupidity.

[george-zubrienko]

Hi Azure people, I am big fan of your products, but THIS is outrageous. Just consider how convenient it was in the old library to do stuff like

       private CloudBlobClient _blobClient;
        private CloudQueueClient _queueClient;
        private CloudTableClient _tableClient;
        private readonly CloudStorageAccount _storageAccount;

        public StorageContext(string connectionString)
        {
            _storageAccount = CloudStorageAccount.Parse(connectionString);
        }

       public StorageContext AddBlobClient()
        {
            _blobClient = _storageAccount.CreateCloudBlobClient();
            return this;
        }

        public StorageContext AddTableClient()
        {
            _tableClient = _storageAccount.CreateCloudTableClient();
            InitializeEntityResolver();
            return this;
        }
...

Which allows to treat Azure Storage as a monolith and have a single DAL class for working with it. Now CloudStorageAccount exists in two separate packages and methods available for it are completely different. The cost of a rewrite is immense, but the main thing I do not get at all is - WHY?! Why are you guys messing up the table storage libraries and cutting them off Azure Storage? It's a perfect NoSQL storage for small/medium sized projects in terms of:

• API consistency, extensibility and ease of use
• Performance
• Simplicity

Do you really want it to be as bad as DynamoDB API's/pricing which you clearly consider a competitor? Please don't go that way and keep our Table Storage as a cheap alternative. I get the cost of maintaining two API's is huge, but I think you can do better than introducing ambigious naming to authentication classes like CloudStorageAccount.