Last week #MsBuild was underway in Seattle. I have already made some notes on the keynote last Monday and the following days I tried to keep track with different novelties announced for ASP.Net Core 2.1. And I think for some members of the community it might be useful to have them written down, so in this article I’ll try to summarize all the information. Please note, that I was not present at the #MsBuild conference. I just tried to follow the sessions streamed on Channel 9 and some key Twitter accounts.
One of the novelties I am most exciting about is the new HttpClientFactory feature. If you worked with the HttpClient in production software, there is a good chance that you noticed a lot of challenges and head aches. In a services oriented architecture where we might need to have several different connections, the only way to go is to use several HttpClient instances (sure not for every call a new client 🙂 but still a bunch of them). One of the problems is that each HttpClient would maintain its own connection pool to the remote server, so it’s highly inefficient. The second, and most stringent problem, is that in scenarios where an application needs to make a lot of calls to remote servers, you could exhaust all the available sockets from time to time. And this is really not cool at all.
Sure, the more experienced ASP.Net developers will know that there are some common patterns and practices to avoid such problems, like registering an HttpClient as singleton with a dependency injection mechanism, but this could lead, on the other side, with problems like not fully respecting DNS time to live (TTL) settings and so on.
HttpClientFactory is designed to help exactly in this type of scenarios by allowing us to create and register HttpClient instances that are properly managed behind the scenes by ASP.Net Core 2.1. With HttpClientFactory you can simply add the HttpClient as a service and then use it via the IHttpClientFactory interface in your controllers. As this very simple approach might not be very useful in larger applications, one can also register a named or typed instance of the HttpClient. This means that we could easily configure different HttpClients in ConfigureServices() in the StartUp.cs class and then use each of them where it is needed. We could even encapsulate the HttpClient in own types and expose for consumption only methods that simply return a result for clients, without knowing the implementation details.
For a more practical approach, I have also created a video that you can watch on YouTube.
SignalR by default in ASP.Net Core 2.1
Another very interesting new feature is the support for SignalR. SignalR makes developing real-time web functionality easy. It allows bi-directional communication between server and client. Servers can push content to connected clients instantly as it becomes available. SignalR supports Web Sockets, and falls back to other compatible techniques for older browsers. It includes APIs for connection management (for instance, connect and disconnect events), grouping connections, and authorization.
And not only supports ASP.Net Core 2.1 SignalR, but it is build in by default, as you can see in the following screenshot:
What does this mean? Well, it means that you could build something like a basic chat application in a matter of minutes. I will try to play around a little bit with SignalR in ASP.Net Core 2.1 the coming days, so I might come back with some new insights about how everything works.
Razor UI class libraries
One frequently requested scenario that ASP.NET Core 2.1 improves is building UI in reusable class libraries. With ASP.NET Core 2.1 you can package your Razor views and pages (.cshtml files) along with your controllers, page models, and data models in reusable class libraries that can be packaged and shared. Apps can then include pre-built UI components by referencing these packages and customize the UI by overriding specific views and pages. This allows us to create reusable UI “components” similar like we can do in Angular. Alongside Blazor this features bring ASP.Net Core development to a whole new level and a whole new future, I dare to say.
Scaffolding identity into existing projects
Have you worked on any ASP.Net Core project that didn’t implement Identity right from the start and then, at a certain point and with the web application already in production, somebody came with the bright idea to implement it? If yes, then you most probably know what a nightmare this was. In one way or another, one would have to re-write a big part of the application to achieve this.
The good news is that starting with ASP.Net Core 2.1 you can scaffold Identity into existing ASP.Net Core projects. To achieve this we can simply right-click on the project, then “Add” and “New scaffolded item”. Then select the Identity scaffolder and just select the ASP.Net Core Identity components that you want to add to the application. I’m not saying that doing this in production applications is as easy as one, two, three, but this is however a great way to start.
As a side note, when you scaffold and ASP.Net Core Identity component a read me file will open in Visual Studio with a step by step guidance on what you need to check, add, modify in order to get everything working. This way we can make sure that we don’t miss adding the middleware for instance, or a service and so on.
HTTPS by default…
HTTPS is enabled by default in ASP.NET Core 2.1 and the out of the box templates include support for handling HTTPS redirects and HSTS. But in some backend services where HTTPS is being handled externally at the edge using HTTPS at each node is not needed. Normally, when you install the ASP.Net Core 2.1 SDK a certificate should be installed and you should get prompted if you want to add it to the trusted certificate root on your development machine. This is how HTTPS will then work when you debug locally.
That’s mostly it. Please note that these described features aren’t necessarily something brand new that nobody expected. Microsoft was working on them for some time and there were some alpha previews already available. With Microsoft Build 2018 Microsoft just released all these features in a public and official Preview. And as per Microsoft’s support guidelines for ASP.Net Core the official announced public previews can also be used for production apps and developers get full support for it, even if it was not globally released yet.
To get started, make sure that you install the ASP.Net Core 2.1 SDK and update Visual Studio 2017 to the latest available updates. Afterwards you should be able to play around 🙂
How useful was this post?
Click on a star to rate it!
Average rating / 5. Vote count:
Latest posts by Dan Patrascu-Baba (see all)
- Configuration and environments in ASP.NET Core - 25/11/2019
- GraphQL in the .NET ecosystem - 19/11/2019
- A common use case of delegating handlers in ASP.NET API - 12/11/2019