The .Net Core 2.2 framework roadmap and some of my views

Kristoffer Eckhoff
Jun 27, 2018 · 4 min read

.NET Core is a cross-platform, high-performance, open-source framework for building modern, cloud-based, Internet-connected applications. I have been working with .NET Core since the first 1.0 release, and have seen it maturing since. There have been some ups and downs from a software developer point of view, such as the project.json to csproj migration, poor support among related libraries you would want to use with .NET Core and some API changes along the way. But whilst not forgetting that all along the way there was some pretty awesome performance, always clean uses of the API, pretty neat and clean middleware piping and built in dependency injection possibilities.

.NET Core 2.1 is already out and provides the following features:

According to this roadmap .Net Core 2.2 will further expand on the 2.1 release.

  • APIs & Services
  • Server improvements
  • SignalR

API Controller conventions

It looks like there will be further improvements and an even more convention based scheme when building web APIs: “In 2.1 we added controller specific conventions that make Web API development more convenient with the ApiController attribute. In 2.2 we want to expand on this concept to provide metadata for API Explorer and provide a better end-to-end API documentation experience”.

This is nice since currently the controllers I write are quite decorated, so I hope to see less decoration and a litte bit more convention. And I like the idea of analyzing code with conventions over attribute declaration, it is pretty much just boilerplate anyways. With these conventions the roadmap also announce that a feature where code will generate Open API documents is planned. And that these will be better by default, since the code will either follow the conventions or have attributes allowing generators to create better documents.(And tooling will be better)

API client generation (C# & TypeScript)

In many projects I have been doing this: “Once you have an API with rich metadata and done exploring and testing it, then you need to go and write some client code to call and make use of your API. We are going to build an experience for generating this code based on the same data and documentation described above.”. From the conventions the .Net core teams envisions that they could also generate API clients from CLI or tooling

Routing system(Dispatcher)

A new routing system will be introduced. And we can expect improvements to the performance of routing and dispatching for MVC and other scenarios. And a more integrated way of configuring CORS it seems, instead of writing a custom pipeline middleware.

Authorization Server

We can expect a simple to use OpenID Connect based authorization server integrated into .Net core it seems. With support for a range of different and broad covering scenarios: web site to API, SPA to API, native application to an API or, for distributed applications API to API. The roadmap also points out that a lot of this should be “simple to use”, “make the code you need to plumb in trivial”, “getting as close to zero configuration as you can”. Which all sounds nice. This has been a little bit of a hassle, and I hope to see some well documented and modern use cases for SPAs for instance using the oidc-client library. This feature will be directly competing with IdentityServer 4 and this has spun up some discussion which has spun up some discussions in recent days.

Server Improvements

A health check feature is planned. HTTP/2 is announced to be added in Kestrel & HttpClient. And a plan to run ASP.NET Core applications in-process in IIS seems to be set, giving a significant performance boost.

SignalR

Expands on the previous release it seems, now allowing customers using Java or C++ to connect to SignalR servers, and the Azure SignalR Service.

And as always bug fixes.

We can expect the release to be done, alongside a small release of EF Core 2.2, by the end of the year.

If you have been sitting on the bench waiting for the library to mature I would say that there is no more waiting. Now with .Net Standard support since 2.0 there should also be a wide range of library support.

Did I miss something? Hit me up on twitter at Doff3n. I am always eager to discuss and learn.

Kristoffer Eckhoff

Written by

Web developer. C#/.Net fan! Problem solver. Senior Consultant. Gentleman and a scholar.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade