Microsoft.ServiceBus.Messaging vs Microsoft.Azure.ServiceBus

Question

MS has recently introduced the Microsoft.Azure.ServiceBus namespace.
https://github.com/Azure/azure-service-bus/blob/master/samples/readme.md

It is geared for the new .net standard framework (as if MS doesn't have enough semi-redundant code bases)

My question is, how much better could it be in terms of performance?

I can say with confidence, that the Microsoft.ServiceBus.Messaging leaves lots to be desired, in particular when it comes to persistent receiving.

A very useful feature of the Microsoft.ServiceBus.Messaging , is the message pump, built on top of OnMessage() method.

The new library, doesn't have this, and needs to rebind event handlers on every receipt to keep pumping. Definitely a step backward .

Looking for feedback from anyone who has had experience with both and can compare..

Ankylosis

Now there seems even something newer, called Azure.Messaging.ServiceBus: github.com/Azure/azure-sdk-for-net/blob/main/sdk/servicebus/… – Surrounding

MS trying to rebrand itself at the expense of the developers – Ankylosis

Answer 1

To address your question, what .netstd library offers that was not in .netframework one:

1. Open Source. The new library is fully open sourced. You can browse, step into (with the next release) without setting up symbols server, contribute, and simply review how things work.
2. The new library is truly async as oppose to what the .netframework library was.
3. Reduced amount of responsibilities and code size. For example, Message vs BrokeredMessage. Your data is no longer serialized by the client.
4. AMQP by default and not SBMP.
5. The new client targets .NET Standard and Full Framework.
6. Certain client aspects redesigned to provide better options (OnMessage API to provide more failure context, plugins and extensibility, interfaces for easier testing).
7. Fully tested.

Performance wise it should be on par with the old client if not better.

A very useful feature of the Microsoft.ServiceBus.Messaging , is the message pump, built on top of OnMessage() method.

You still have OnMessage API, though renamed to RegisterMessageHandler.

Gamesmanship

To add.. Async is awesome but I have a need to send Synchronously and Microsoft.Azure.ServiceBus no longer has client.Send() only client.SendAsync() which is a bummer. Trying to avoid using How would I run an async Task<T> method synchronously? – Circumvolution

@Circumvolution there's a reason why the new client provides no synchronous API anymore. Everything it does has to do with IO. For that, synchronous APIs make no sense. As a user of the library, you can always force synchronous execution, but then you're substantially decreasing the performance. – Gamesmanship

One other difference is the apparent lack of a "send batch" method. There is a SendAsync(IList<Message>) but it's not clear to me that it behaves the same as the old SendBatchAsync() method. See current open issue github.com/Azure/azure-sdk-for-net/issues/8440 (new comments even 5 days ago), old PR on archived repo github.com/Azure/azure-service-bus-dotnet/pull/539, and the original method in Microsoft.ServiceBus.dll learn.microsoft.com/en-us/dotnet/api/… – Benedetta

It's the same thing. Sending a single message or a collection ends up to be the same thing invoking the broker. – Gamesmanship

Batching was never "safe" with the old client. I. That regard, the new client is no different, @gabe. – Gamesmanship