Upgrade to Azure.Messaging.ServiceBus

[SeanFeldman]

Update 2023-02-11 Azure.Messaging.ServiceBus SDK's approach to plugins has been refreshed. Details in the comment.

Update 2020-06-26: blocked by the Azure SDK team's decision to introduce plugins post GA.

Azure Service Bus track 2 SDK is in preview and doesn't support pipelines and plugins yet.

Requires Preview 4 / Azure/azure-sdk-for-net#11986 to be completed first.

[SeanFeldman]

Blocked by the Azure SDK team's decision to introduce plugins post GA. The API is internalized and won't be available.

[basilfx]

Just for your information: at work, we have updated to Azure Functions V4. I have upgraded most of this package to work with the new SDK: https://github.com/basilfx/ServiceBus.AttachmentPlugin/tree/feature/azure_messaging_servicebus

Yes, this branch does not include the plugin capability, but we were not using it anyway (because of Azure Functions).

[SeanFeldman]

@basilfx I'm no longer actively maintaining this project given the large message support provided officially by Microsoft.
I also haven't seen any issues raised about it. A new major version could be released with a smaller API surface if you'd like to create a PR. API documentation would need to be updated to reflect the change.

[SeanFeldman]

Azure.Messaging.ServiceBus SDK's approach to plugins has been refreshed. The new approach achieves extensibility via inheritance, requiring plugin implementors to extend every ASB SDK type that would require the plugin to work (ServiceBusSender, ServiceBusSenderReceiver, ServiceBusProcessor, ServiceBusSessionReceiver, and ServiceBusSessionProcessor.

Here's a sample that demonstrates what an end-user experience would look like. cc @valdisiljuconoks

[ankitvijay]

Hi @SeanFeldman, we would love to have this feature available as an Azure Service Bus plugin. We use NSB over an ASB. Here's why we are looking for this feature for my team:

• Only a couple of messages among several have a big payload. So, we do not want to increase the message size of our Premium Plan in ASB. Besides, our QA environment is a "Basic" plan, which does not support large payload sizes.
• Currently, we have implemented a custom "Claim Check" pattern. We save the payload in the blob storage and put a link to the blob in the message. While it works, a plugin to give us the same functionality makes it easier for our developers without worrying about the payload size and we can get rid of custom code.

I hope the plugin would allow us to set the retention policy of external storage (I'm assuming it will be blob) and the naming convention of the blob name.

This issue ](Particular/NServiceBus#6675) is stopping us from the NSB DataBus feature. So if the issue is fixed, perhaps we would not need this plugin anymore? (Not sure if the plugin would provide any additional features)