Support for .NET Core 3.1 is here!

Supporting NServiceBus on .NET Core 3.1 has been a focus for us here at Particular in 2020. Well, the day is finally here. We’re happy to announce that with the latest version of NServiceBus, you can build and deploy your NServiceBus endpoints on .NET Core 3.1, taking advantage of great features like built-in hosting, logging, and dependency injection.

🔗Support for .NET Core 3.1

Microsoft has been investing in .NET Core as their next major framework, going as far as announcing that .NET Framework 4.8 will be the last major version of the .NET Framework. All of their efforts have been focused on the .NET Core space, and they are heading towards .NET 5 as we speak.

Our last major release of NServiceBus, introduced support for .NET Core 2.1. In the meantime, Microsoft has brought us another LTS (long term support) version of .NET Core, version 3.1.

Even though you could technically run NServiceBus on .NET Core 3.1, as it’s backwards compatible with .NET Core 2, we weren’t comfortable recommending doing so to our customers until we had tested it for ourselves. In order for us to add .NET Core 3.1 to our list of supported platforms, there were a lot of boxes we wanted to tick off to make sure we continue to offer our users the best experience possible. So we went on a journey of updating our build infrastructure and running our extensive test suite targeting .NET Core 3.1. This exposed a handful of edge cases, which were then tackled and fixed.

To further improve the user experience, we collected more than a hundred samples available on our documentation website, and made them available as downloads specifically targeting .NET Core 3.1 as shown here.

If you were holding back on upgrading, now is the time. If you need help upgrading from another version of the .NET Core framework, this article might be useful to you. To upgrade to the latest version of NServiceBus, there are upgrade guides available here.

🔗But wait, there’s more!

NServiceBus has provided abstractions for Hosting, Logging, and Dependency Injection for over a decade. Over the last years, Microsoft has invested heavily in these areas, bringing us brand new built-in APIs under the Microsoft.Extensions namespaces and packages. Now that the Microsoft’s Extensions APIs are quickly becoming industry standards, we’re more than happy to retire our implementations and rely on theirs. Don’t panic, we haven’t retired anything yet. When we actually do, you will have up to five years to upgrade.

One of those APIs is their built-in implementation of dependency injection in ASP.NET Core. This API reduces the need to reference an external package and covers the dependency injection needs of most projects.

With this new version, your handlers can take dependencies on services registered in ASP.NET Core services:

class SomeHandler : IHandleMessages<SomeMessage>
{
    ICalculateStuff stuffCalculator;

    public SomeHandler(ICalculateStuff stuffCalculator)
    {
        this.stuffCalculator = stuffCalculator;
    }

    public async Task Handle(SomeMessage message, IMessageHandlerContext context)
    {
        await stuffCalculator.Calculate(message.Input);

        // Do some more stuff if needed
    }
}

We are continuing our efforts to integrate with the Microsoft.Extensions packages in order to streamline our usage of these APIs. In retiring our own implementation of these concerns, we can evolve more quickly down the line, and increase our focus on the essence of our platform: messaging.

If you’re interesting in how all of these parts function together, check out this sample, or take our latest release for a spin.