.NET Core 2.1 highlights: standing on the shoulders of giants

Since two years after the 1.0 version, .NET Core has gained a lot of popularity in the software engineering world. The following chart came from the Stack overflow survey 2018:

Nowadays, .NET Core is in the top 5 of the most popular Frameworks, Libraries, and Tools.

The metaphor of dwarfs standing on the shoulders of giants expresses the meaning of discovering truth by building on previous discoveries and experience. The point is that the .NET team has learnt from their previous experiences and .NET Core is the result of that experiences applied to a new multi-platform framework.

I have already write about .NET Core here: Developing token authentication using ASP.NET Core, Implementing SOLID REST API using ASP.NET Core, Unit testing ASP.NET Core Identity.

The framework is movin’ fast, each new release enhance and sometimes change features of the framework. The following article shows some highlights and new feature which are present in the new version of .NET Core 2.1 and ASP.NET Core 2.1.

.NET Core 2.1

The .NET team have been thinking of .NET Core 2.1 as a feedback-oriented release after the more foundational .NET Core 2.0 release.  Let’s see some highlights on .NET Core 2.1:

• Span<T>, Memory<T> introduction;
• Windows compatibility pack;
• Build-time performance improvement;

Span , Memory introduction

.NET Core comes with a new set of types for using arrays and other types of memory that is much more efficient. Furthermore, Span<T> and Memory<T>  are part of the System.Memory.dll package, the preview of this package is available on NuGet and it is compatibile with .NET Standard 1.1.

Actually, Span<T> and Memory<T> concept goes behind the consumer-use side. Indeed, these new types became useful under the hood of the framework, e.g. for the HttpClient, in order to improve the performance.

If you are looking for more relevant information about the performance improvement and to go in deep on these types,  please take a look to : All About Span: Exploring a New .NET Mainstay

Windows compatibility pack

The Windows compatibility pack package is useful for all the developers who want to port existing .NET Framework code to .NET Core. It increases the APIs surface to an additional 20k APIs. You can download the package at the following link : https://www.nuget.org/packages/Microsoft.Windows.Compatibility  The packages also provides some useful APIs in order to detect the hosting OS, for example:

RuntimeInformation.IsOSPlatform(OSPlatform.Windows)

Since it detects if the current OS platform is Windows, it may be useful in order to execute different code depending on the type of platform.

In addition, Microsoft has also released the following package: API Analyzer.

API Analyzer is a Roslyn analyzer that comes as NuGet package. After referencing it in your project, it automatically provides live feedback on API usage and warns about potential compatibility issues and calls to deprecated APIs.

Build-time performance improvement

The following chart provides some informations about the improvement. It compares the previous version of .NET Core with the new-one:

As you can see, in .NET 2.1 preview the build time for WebSmall project is of 2.7 sec, furthermore for the WebLarge project, the build time is 22.5 sec. The .NET team goal is to improve it with the new .NET Core 2.1 RTM version. Their plan is drop that again to 6.8 sec for WebLarge project.

ASP.NET Core 2.1

Let’s talk about ASP.NET Core 2.1. The new release is targeted for mid-year 2018. It covers some improvements and features on following areas: Razor pages, SignalR, Webhooks, Security, Perfomance, MVC, Kestrel;

Here is some highlights and new stuff from next release.

HttpClientFactory

The HttpClientFactory brings the concept of dependency injection to HttpClient implementation. It provides a central location to manage and instantiate all HttpClient.

The HttpClientFactory integrates Polly.NET. Polly is a .NET resilience and transient-fault-handling library that allows developers to express policies such as Retry, Circuit Breaker, Timeout, Bulkhead Isolation, and Fallback in a fluent and thread-safe manner.

HttpClientFactory has two different approaches: NamedClient, TypedClient;

NamedClient

The NamedClient is the default choice.

The method AddHttpClient defines a new namespace which can be used to refer the client inside your services and controllers:

TypedClient

The other way is by referring directly the typed client. You can define a typed client by injecting the HttpClient inside the constructor of new classes, that approach, very DI oriented, is the one I prefer:

As you can see, it allows you to register and inject directly the typed client:

Kestrel: Socket over libuv

The current implementation of Kestrel uses libuv under the hood. The implementation of the underlying libuv connection semantics has been decoupled from the rest of Kestrel and abstracted away into a new Transport abstraction. By the way, for performance reasons, Microsoft is investing on custom socket implementation inside .NET.  The sockets will replace the libuv async I/O.

Furthermore, it is already possible to configure and try socket transportation, to do that you should configure it on the application Program.cs: