Deprecated dependency: Microsoft.Azure.Storage.Blob

[JFesta]

Recently, the Microsoft.Azure.Storage.Blob package got deprecated. The alternate package should be instead Azure.Storage.Blobs.

Since in our solution we use ServiceBus.AttachmentPlugin in order to send and store messages larger than 256 KB, we can't switch to Azure.Storage.Blobs until this package gets updated.

Obviously, we could just implement a feature in our code to do this, but it would be nice to have it off the shelf nonetheless. Is perhaps a switch to the new package already planned?

[SeanFeldman]

@JFesta, thanks for raising the issue. First, where things are and why I haven't actioned those yet. There are two parts to this plugin:

1. Storage SDK
2. Service Bus SDK

It's not so recently that Microsoft has published Azure.Storage.Blobs. I was looking at it quite a while ago. Unfortunately, it's not a straight conversion, and some of the APIs were broken to the point I cannot achieve what I was able to do before with Microsoft.Azure.Storage.Blob. A point in case - parsing a connection string to determine wherever it is a SAS token or not (Azure/azure-sdk-for-net#12891, related Azure/azure-sdk-for-net#11590).

I could reduce the number of supported configuration options and get past that hurdle, but then there's a bigger one: Service Bus SDK. That one has also been replaced by a newer SDK and has not seen support for pipelines and plugins. See #201 for details. Even if I update to the latest Storage SDK, you still cannot use the latest Service Bus SDK. Also, the premium tier of ASB support 1MB, which is getting bumped to 100MB, making this plugin obsolete in production.

At this point, as someone who would invest his time and support this, I need to ask myself

1. Is it worth the investment?
2. Will it help to be able to use only the new Storage SDK w/o the new Service Bus SDK (think authentication, etc)?

I'm curious to hear your thoughts. Are you willing to mix the new and the old SDKs?

[JFesta]

I didn't know there is a new ServiceBus SDK in development in the first place. I guess the old one is going to be deprecated soon as well.

I think there could be a reason to have a library that mixes the old and new SDKs, and that's for those situations where you need to stick to the old SB SDK (at least temporarily) for some reason, maybe because you're using some other specific plugins or some features that aren't available in the new SDK.

I think that's not the case for my specific situation, since this is the only plugin currently in use in our code. But I have to check first if there are some other missing features on the new SDK. For instance, there's a situation where we need to retrieve the MaxDeliveryCount from a queue in order to do some specific things when the current retry number is less than this parameter.

But still, the required effort to have both SDK might not be worth it.

[SeanFeldman]

I didn't know there is a new ServiceBus SDK in development in the first place. I guess the old one is going to be deprecated soon as well.

It's already GA-ed 🙂
As far as I know, pipelines/plugins support was the only outstanding feature that was missing from v7 ASB SDK that was blocking this project.

Given the information about the premium tier, I'm having a hard time justifying time investment in getting this project updated to the latest Storage SDK and then later updated it to the Service Bus SDK when/if pipelines/plugins support lands. If you feel strongly about using Azure.Storage.Blobs with this plugin and willing to help out on the migration, I'll be happy to support that initiative, review the PR and update docs/the rest of what's needed. But I cannot commit to doing the whole work in my spare time ATM.