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..
To address your question, what .netstd library offers that was not in .netframework one:
- 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.
- The new library is truly async as oppose to what the .netframework library was.
- Reduced amount of responsibilities and code size. For example,
MessagevsBrokeredMessage. Your data is no longer serialized by the client. - AMQP by default and not SBMP.
- The new client targets .NET Standard and Full Framework.
- Certain client aspects redesigned to provide better options (OnMessage API to provide more failure context, plugins and extensibility, interfaces for easier testing).
- 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.
来源：https://stackoverflow.com/questions/45873327/microsoft-servicebus-messaging-vs-microsoft-azure-servicebus