My favorite framework, dotnet has a new version released every year. Before the final release is out, I went through each preview version and selected the 5 New ASP net core features in dotnet 8 You’ll Love this Year in no particular order. The next version will be released in a few months and several preview versions have been made available by Microsoft already. Microsoft engineers have been working hard to make ASPnet core the best web framework ever. They actively listen to us (The community) and ameliorate the framework relentlessly.
The dotnet team treats developers as first-class customers and I love that. I guess I’m not the only one to love it, since the Stack Overflow survey (https://survey.stackoverflow.co/2023/) has ranked dotnet very high, at the first spot in several categories during the last years.
I’ve been watching every preview release of ASPnet core updates in dotnet 8, and at the time of writing this article, we’re at preview 6. I love the new upcoming features and in this article, I present you my 5 favorite upcoming ASPnet core updates in dotnet 8. If you want to know more about the roadmap for ASPnet core in dotnet 8, and upcoming features, the roadmap could be found here
1 – Global Exception Handling
If you’re an old-time ASP.net core dev, you surely have already implemented something to catch every exception, log it, send appropriate responses to clients, and ensure that no critical information is leaked in production. Over the years, several blog posts and nugget packages were released to automate this process. Now we can add it with minimal effort in ASPnet core on dotnet 8.
This is possible thanks to the “IExceptionHandler” type that was added in dotnet 8. ASPnet core already had an Exception handler middleware that was added in previous dotnet versions. But this interface makes it possible to inject some custom exception-handling logic behind the scenes.
You first need to implement this interface, for your exception-handling logic, you can implement as many as you can, and they will be executed by order of registration.
1 2 3 4 | public interface IExceptionHandler { ValueTask<bool> TryHandleAsync(HttpContext httpContext, Exception exception, CancellationToken cancellationToken); } |
Then, register it as follow. Where “T” is the type of your Exception handler class.
1 | IServiceCollection.AddExceptionHandler<T> |
Checkout this Github discussion for more information about the feature.
If you find this article useful, please follow me on Twitter, Github, Linkedin, or like my Facebook page to stay updated.Follow me on social media and stay updated
2 – Support for native AOT in ASP.net core
First, what is AOT and JIT? () and (Just in time compilation)
AOT: Ahead of Time Compilation
This is when source code written in a high-level programming language is compiled into a lower-level programming language before execution.
JIT: Just in Time Compilation
This is when a program is compiled during execution. In dotnet, this has always been used, to compile any dotnet language down to machine code when needed. The dotnet language code (C#, F# etc) is compiled to CIL language in a “.exe” or dll, which is then executed, and during execution, the JIT compiler transforms this CIL into the native code of the underlying OS.
Dotnet 7 which was released last year, brought us the ability to compile and publish console applications as native AOT. Now in dotnet 8, we will be able to compile and release ASP.net core apps as native AOT. But this will be focused initially on cloud-native API applications as mentioned by Microsoft here (https://devblogs.microsoft.com/dotnet/asp-net-core-updates-in-dotnet-8-preview-3/#asp-net-core-support-for-native-aot).
What does this change?
After understanding JIT and comparing it to AOT, you’ll quickly see the difference. The software you write could be deployed as a platform-specific, package that is smaller in size, consumes less memory, and quicker to launch, without the dotnet runtime installed on the device.
NOTE: not all ASP.net core features are Native AOT compatible yet. This is something new, and I’m really excited to see what will be done in future versions of dotnet. For more information, you can read this
3 – Add Authorization Policies Easily
When implementing authorization policies, a bunch of code gets to be written. Especially if you intend to create custom attributes for your policies. In dotnet 8, Asp.net core has a new feature that makes it easy to create authorization policies with fewer lines of code. This is possible thanks to the addition of IAuthorizationRequirementData. The advantage that this brings us is that the attribute definition can also specify the requirements associated with the authorization policy.
The best way to demonstrate how this is an improvement is to show you an example directly. If you compare this to the former way or making Authorization Policies, you’ll quickly understand why it is awesome. Here is a demo from a Microsoft repository. This demo will clearly show you the amelioration.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 | [ApiController] [Route("api/[controller]")] public class GreetingsController : Controller { [MinimumAgeAuthorize(16)] [HttpGet("hello")] public string Hello() => $"Hello {(HttpContext.User.Identity?.Name ?? "world")}!"; } class MinimumAgeAuthorizeAttribute : AuthorizeAttribute, IAuthorizationRequirement, IAuthorizationRequirementData { public MinimumAgeAuthorizeAttribute(int age) => Age =age; public int Age { get; } public IEnumerable<IAuthorizationRequirement> GetRequirements() { yield return this; } } class MinimumAgeAuthorizationHandler : AuthorizationHandler<MinimumAgeAuthorizeAttribute> { private readonly ILogger<MinimumAgeAuthorizationHandler> _logger; public MinimumAgeAuthorizationHandler(ILogger<MinimumAgeAuthorizationHandler> logger) { _logger = logger; } // Check whether a given MinimumAgeRequirement is satisfied or not for a particular context protected override Task HandleRequirementAsync(AuthorizationHandlerContext context, MinimumAgeAuthorizeAttribute requirement) { // Log as a warning so that it's very clear in sample output which authorization policies // (and requirements/handlers) are in use _logger.LogWarning("Evaluating authorization requirement for age >= {age}", requirement.Age); // Check the user's age var dateOfBirthClaim = context.User.FindFirst(c => c.Type == ClaimTypes.DateOfBirth); if (dateOfBirthClaim != null) { // If the user has a date of birth claim, check their age var dateOfBirth = Convert.ToDateTime(dateOfBirthClaim.Value, CultureInfo.InvariantCulture); var age = DateTime.Now.Year - dateOfBirth.Year; if (dateOfBirth > DateTime.Now.AddYears(-age)) { // Adjust age if the user hasn't had a birthday yet this year age--; } // If the user meets the age criterion, mark the authorization requirement succeeded if (age >= requirement.Age) { _logger.LogInformation("Minimum age authorization requirement {age} satisfied", requirement.Age); context.Succeed(requirement); } else { _logger.LogInformation("Current user's DateOfBirth claim ({dateOfBirth}) does not satisfy the minimum age authorization requirement {age}", dateOfBirthClaim.Value, requirement.Age); } } else { _logger.LogInformation("No DateOfBirth claim present"); } return Task.CompletedTask; } |
4 – New ASP.net core metrics
In the past, implementing telemetry and diagnostic features in your software required you to write code tidily coupled with the telemetry provider’s SDK. Once you needed to switch to a new vendor, you’d often need to re-write the instrumentation code. This was a problem and needed to be addressed.
To address this, System.Diagnostics.Metrics API was created. This provides cross-platform APIs for telemetry and was designed in collaboration with Open Telemetry. Open telemetry adoption makes telemetry more flexible. Why? you may ask. To answer your question, I’ll quote this from Microsoft’s docs.
“The OpenTelemetry effort is an industry-wide collaboration across telemetry tooling vendors, programming languages, and application developers to create a broadly compatible standard for telemetry APIs.”
Microsoft Docs
But what does it have to do with ASP.net Core?
Now you understand the necessity of having an industry-wide standard for collecting metrics. This has been added to parts of ASP.net core. Including Kestrel, Hosting, and Signal-R. Microsoft has put at our disposal a sample source code, with a Grafana dashboard that reports metrics collected from the ASP.net core app by Prometheus.
What is Prometheus?
To answer this question, I’ll simply quote what is on their website. Since it is very clear. Here is a link to their website.
“Prometheus is an open-source systems monitoring and alerting toolkit originally built at SoundCloud. Since its inception in 2012, many companies and organizations have adopted Prometheus, and the project has a very active developer and user community.”
Prometheus
5 – Better Debugging Experience
Playing the detective with your source code is now more fun. Finding important and precise information on types like the HttpContext and WebApplication is a lot easier on dotnet 8. Even IConfiguration values are easily displayed on the debug window. This improvement is depicted here.
Conclusion
As I said earlier, the dotnet team is treating its developers as first-class customers, and I love that! I can’t wait to see the latest dotnet 8 release and upgrade my projects in accordance with the improvements and new features coming. There are more features added that I love, like better authentication for example, but I just decided to pick 5 of them. What’s the feature you love most?
References
ASP.NET Core updates in .NET 8 Preview 6
ASP.NET Core updates in .NET 8 Preview 3
https://devblogs.microsoft.com/dotnet/asp-net-core-updates-in-dotnet-8-preview-1/#native-aot https://www.geeksforgeeks.org/what-is-just-in-time-jit-compiler-in-dot-net/
Follow me on social media and stay updated