Error handling in ASP.NET Core Web API
We all know the traditional try-catch blocks and -used correctly- there is of course nothing wrong with them! But even though all is good with that, ASP.NET Core has an even better way of doing things, two ways actually, that can make our code cleaner and easier to read! By following the “Middleware” approach, we extract all our custom exception handling code from within the actions and centralizing it in one place thus, cleaner code!
In this post we will explore these three cases, and starting from the simple try-catch block we will refactor towards a custom error handling middleware.
IdentityServer4, ASP.NET Core API and a client with username/password
This is an end-to-end guide on how to quickly setup IdentityServer4, use it in your ASP.NET Core API for authentication, and finally login to your API from a client by asking a user for their username and password. It is divided in three parts that describe respectively the configuration of each one of the following three systems:
Writing a custom OutputFormatter to return an Excel (.xlsx) from an action in ASP.NET Core API
As most of us, I already know my next week work schedule. It includes writing some actions in respond to a requirement for excel exports. It’s nothing new and its’s relatively easy with libraries like NPOI: you just create your excel on the fly and return a FileResult.
Handling, serializing and returning exceptions with a middleware in an ASP.NET Core API
ASP.NET Core offers a very cool way to avoid all that boring boilerplate exception handling code, just by intercepting all requests. It is called Middleware and actually, ASP.NET Core is full of built-in middlewares!
Publishing ASP.NET Core: An error occurred while starting the application
Have you seen this error?
An error occurred while starting the application.
.NET Core <version> | Microsoft.AspNetCore.Hosting <version> | Microsoft Windows <version> | Need help?
Parameterized Raw SQL Queries with Entity Framework: How to Unit Test with SQLite
Entity Framework Core allows you to drop down to raw SQL queries when working with a relational database. This can be useful, because raw SQL queries can return entity types or, starting with EF Core 2.1, query types that are part of your model, but it could also be a problem when it comes down to Unit Testing.