Should we use the Microsoft.Azure.EventHubs.Processor library with .NET framework

Question

Context

We're currently using Microsoft.Azure.ServiceBus.EventProcessorHost for data ingestion from an Azure Event-Hub. We run on .NET framework, not .NET Core.

This Microsoft announcement (published Feb 2, 2017) suggests the newer Microsoft.Azure.EventHubs.Processor is the way to go in the future, regardless of the .NET runtime you use, as they will maintain a single code base.

Meanwhile, the official Microsoft Event-Hub samples updated recently still suggest the older library (Microsoft.Azure.ServiceBus.EventProcessorHost) for the .NET framework.

Both libraries have been updated and evolved since the announcement.

Question

Since we're on .NET framework, which library should we use going forward?

Should we migrate to the newer Microsoft.Azure.EventHubs.Processor, in order to benefit from the latest development, improvements and bug fixes? Or is the old one kept up to speed?

The question is relevant to newcomers as well, which library should they pick to get started with Azure Event-Hubs.

Answer 1

Adding a bit of context to modernize this guidance, since Microsoft has since launched a new initiative around the Azure SDKs, which includes a new Event Hubs client library. For new development, we recommend using the Azure.Messaging.EventHubs family of packages and the Azure.[[ AREA ]].[[ SERVICE ]] packages for working with other Azure services.

Azure.Messaging.EventHubs is the current generation Event Hubs client library and will be the focal point of development, with improvements and new features being released on a regular cadence. It supports the netstandard2.0 platform, allowing it to be used with a wide range of host environments which include .NET 5, .NET Core, and the full .NET Framework. The library retains high-level feature parity with the previous generation, Microsoft.Azure.EventHubs, but with but with a more discrete client hierarchy and improved API.

The Azure.Messaging.EventHubs library is part of the initiative to improve the development experience across Azure services. To this end, it follows a set of uniform design guidelines intended to drive a consistent experience across development languages and employ established API patterns for all Azure services. The library also follows a set of .NET-specific guidelines to ensure that the .NET SDK has a natural and idiomatic feel that mirrors that of the .NET base class libraries.

The Azure.Messaging.EventHubs library also provides the ability to share in some of the cross-service improvements made to the Azure development experience, such as a unified diagnostics pipeline offering a common view of the activities across each of the client libraries. Another key improvement is a streamlined and simplified experience for authentication using the new Azure.Identity library to share credentials between the clients for different Azure services.

While we believe that there is significant benefit to adopting the modern version of the Event Hubs client library, it is important to be aware that the legacy versions have not been officially deprecated. They will continue to be supported with security and bug fixes. However, new features are unlikely to be added and there is no guarantee of feature parity between the modern and legacy versions going forward.

More information on the Azure.Messaging.EventHubs library is available in its README and [Samples)[https://github.com/Azure/azure-sdk-for-net/tree/master/sdk/eventhub/Azure.Messaging.EventHubs/samples). There is also a Migration Guide available to assist with upgrading from the legacy versions.

Answer 2

I may be partial in my answer, but I would prefer the newer Microsoft.Azure.EventHubs library. This is for the following reasons:

• It is open source. You can see the roadmap, current issues, file your own issues, and in case you need it, you have access to the code with an MIT license.
• It uses .NET Standard. In case your solution ever changes to .NET Core, or any of the other .NET runtimes, you can continue to use your Event Hubs code.
• This is the library that Microsoft will be emphasizing in the future. While that is my assumption, here's why I think that:
  • The learn.microsoft.com getting started examples use the new library. https://learn.microsoft.com/azure/event-hubs/event-hubs-dotnet-standard-getstarted-send
  • Microsoft has seen the benefits of open source development, and nearly all of their Azure libraries are being open sourced. i.e. Service Fabric just went open source as well: https://blogs.msdn.microsoft.com/azureservicefabric/2018/03/14/service-fabric-is-going-open-source/
  • The newer library was createdd with the intent to replace the older library. While Microsoft is very good at supporting old / legagcy libraries, the ultimate intent was to replace the older library. https://azure.microsoft.com/blog/event-hubs-dotnet-standard-client-reaches-ga/