Azure @ Enterprise - Dilemma of choosing .Net SDK for ServiceBus Queue

If you want to skip all my stories and want to understand what is the .Net SDK to use with Azure ServiceBus, please use the Azure.Messaging.ServiceBus nuget package. No more suspense.

Others welcome to the story. 

All we wanted was to dequeue Azure ServiceBus Queue messages in the synchronous fashion inside the .Net 4.6.1 application. 

WindowsAzure.ServiceBus Library and Microsoft.ServiceBus.Messaging namespace

The first nuget library we got was WindowsAzure.ServiceBus which has Microsoft.ServiceBus.Messaging. This library has a class called QueueClient. That has a synchronous dequeue mechanism using ReceiveBatchAsync() method. Unfortunately, this library needs .Net 4.6.2. If it is not an enterprise, upgrading the .Net framework version would not be a big deal. But upgrading an application having half a million lines of code in the enterprise that too working in regulated industry is a thing. So had to say bye to this technique.

Another reason to say bye is the new library named Microsoft.Azure.ServiceBus and the migration instructions from WindowsAzure.ServiceBus.

Microsoft.Azure.ServiceBus Library and Microsoft.Azure.ServiceBus namespace

This library has migration guidelines from the community at least. It appeared to be the way to go. It supports .Net 4.6.1. This also has a QueueClient class. But this QueueClient doesn't have a mechanism to synchronously dequeue messages. It accepts a callback via RegisterMessageHandler() and suitable for daemon apps. Our app is not a daemon.

We got stuck here and since we had a channel to MSFT we decided to activate it. They suggested a third library which comes next.

Later we figured out there is a way in Microsoft.Azure.ServiceBus library to dequeue messages in sync way. This link explains the same using MessageReceiver class. But we are planning to use the below one which Microsoft confirms the way forward.

Azure.Messaging.ServiceBus

As per Microsoft, this library is the way to go. They are making all SDK names starting with Azure prefix now. The good thing we are seeing is that now Microsoft is preparing the migration guide from older SDKs.

Migration into Azure.Messaging.ServiceBus

From Microsoft.Azure.ServiceBus to Azure.Messaging.ServiceBus migration guide.

From WindowsAzure.ServiceBus to Azure.Messaging.ServiceBus migration guide issue. Note that this is not yet available. At least there is an issue to track it.

Samples

The below link will take us to the code to dequeue messages in sync using Azure.Messaging.ServiceBus library.

https://github.com/joymon/azure-demos/blob/master/intergation/service-bus/service-bus-queue-basic/AzureMessagingServiceBusDequeuer.cs

It also has the code snippets we tested using other libraries. Get the full project to run it.

Conclusion

Those libraries are still in development. That is the interesting thing. 

Library	Last release
WindowsAzure.Messaging	v6.0.3 - 5 months ago
Microsoft.Azure.ServiceBus	v5.1.1 - 24 days ago
Azure.Messaging.ServiceBus	v7.0.1 - 25 days ago

The above table shows the recent releases as of writing this blog post.

Due to NDA, I am not supposed to disclose the names. But big thanks MSFT guy(s) for your support. Innovation and changes are always welcome from Microsoft. But one humble request is to slow down innovation a little bit and consider stability. That helps people like us who develop apps for the regulated enterprises.

Happy coding...