Blob SaS URL generation using existing connection string "UseDevelopmentStorage=true"

Query/Question Is there any way to create a SaS URL for a Blob using the existing Connection String mechanism?

Environment:

• Azure.Storage.Blobs 12.4.1

Details I am currently wiring all my storage stuff up using a single Connection String passed in to the BlobServiceClient. This is very convenient as I can use the “UseDevelopmentStorage=true” in my development appSettings.json without needing to specify all the details. My ARM deployment can then simply grab the connection string at deployment time for each environment.

However, the new way of generating SaS URLs for temporary Blob access requires me to create a new instance of StorageSharedKeyCredential and there doesn’t appear to be an automatic way of getting this from an existing instance of BlobServiceClient.

This leaves me with the choices of:

• Parse the connection string myself (the StorageConnectionString class is marked internal) including detecting “UseDevelopmentStorage=true” manually and splitting string etc.
• Change everything to use Account Name and Account Key (which means I have to put the development account name and key in explicitly).

Would it not be simpler to have a way of creating a SaS token using a BlobServiceClient - either directly or indirectly - which already has the credentials loaded?

Or at least expose the StorageConnectionString class so I can parse the connection string again. Otherwise I will have to add all this logic again myself.

[stpatrick2016]

As a workaround and instead of parsing manually can use DbConnectionStringBuilder like this:

            var conBuilder = new DbConnectionStringBuilder();
            conBuilder.ConnectionString = MyConnectionString;
            var cred = new StorageSharedKeyCredential(conBuilder["AccountName"] as string, conBuilder["AccountKey"] as string);

[fhurta]

Hello, any progress with this issue? I also found it awkward not to be able to create the StorageSharedKeyCredential from connection string or get it from already authenticated client. Both BlobServiceClient and QueueServiceClient take connection string in the constructor. You can get AccountName but not the AccountKey from them.

It would be really helpful to have some kind of consistency in the library design. I understand it might happen but this issue was reported 4 month ago…