Monday, December 5, 2022

ASP.NET Core Web API: Exception Handling

In this post, let's see how we can provide a common approach for handling exceptions in ASP.NET Core Web APIs in the Development environment as well as in Production environments.

It's quite easy, basically, we can introduce UseExceptionHandler Middleware to handle exceptions.

Consider the following code.
WebApplicationBuilder builder = WebApplication.CreateBuilder(args);
 
// Add services to the container.
builder.Services.AddControllers();
 
WebApplication app = builder.Build();
 
// Configure the HTTP request pipeline.
if (app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/error-development");
}
else
{
    app.UseExceptionHandler("/error");
}
 
app.UseHttpsRedirection();
 
app.UseAuthorization();
 
app.MapControllers();
 
app.Run();
Here I have added UseExceptionHandler passing in different routes based on the environment. Now we need to define controller actions to respond to /error-development and /error routes.
using Microsoft.AspNetCore.Diagnostics;
using Microsoft.AspNetCore.Mvc;
using System.Net;
 
namespace WebApplication1.Controllers;
 
[ApiController]
[ApiExplorerSettings(IgnoreApi = true)]
public class ErrorController : ControllerBase
{
    private readonly IHostEnvironment _hostEnvironment;
 
    public ErrorController(IHostEnvironment hostEnvironment)
    {
        _hostEnvironment = hostEnvironment;
    }
 
    [Route("/error-development")]
    public IActionResult HandleErrorDevelopment()
    {
        if (!_hostEnvironment.IsDevelopment())
        {
            return NotFound();
        }
 
        IExceptionHandlerFeature exceptionHandlerFeature = HttpContext.Features.Get<IExceptionHandlerFeature>()!;
 
        if (exceptionHandlerFeature == null)
        {
            return Problem(
                title: $"'{nameof(IExceptionHandlerFeature)}' not found.");
        }
 
        return exceptionHandlerFeature.Error switch
        {
            NotImplementedException notImplementedException => Problem(
                title: notImplementedException.Message,
                detail: notImplementedException.StackTrace,
statusCode: (int)HttpStatusCode.NotImplemented), _ => Problem( title: exceptionHandlerFeature.Error.Message, detail: exceptionHandlerFeature.Error.StackTrace) }; } [Route("/error")] public IActionResult HandleError() => Problem(); }
Note: The actions aren't attributed with HttpVerbs and the controller is attributed with [ApiExplorerSettings(IgnoreApi = true)] to exclude from OpenAPI specification (if there's any).

For the Development environment, based on the type of the exception, I am returning different statusCodes and I am including the StackTrace to troubleshoot the issue easily. 

For an example, consider the following action.
[HttpGet(Name = "GetWeatherForecast")]
public IEnumerable<WeatherForecast> Get()
{
    throw new NotImplementedException("Not implemented.");
}
If we call the above action when running on a Development environment, I will be getting a response like below. It's the standard RFC 7807-compliant Problem Detail.
Development: StatusCode: 501
And now if I change the endpoint to throw a different exception,
[HttpGet(Name = "GetWeatherForecast")]
public IEnumerable<WeatherForecast> Get()
{
    throw new Exception("Something happened.");
}
I am getting the default Internal Server Error status code with the StackTrace.
Development: StatusCode: 500
And when in a production environment, we just get the response hiding internal details.
Production: StatusCode: 500

Hope this helps.

Happy Coding.

Regards,
Jaliya

Sunday, December 4, 2022

ASP.NET Core: Suppress Implicit Required Model Validation For Non Nullable Reference Types

In this post, let's see how we can disable implicit required model validation for non-nullable reference types when the nullable context is enabled in an ASP.NET Core Web Application.

Let's consider the following sample.

#nullable enable
 
using Microsoft.AspNetCore.Mvc;
 
WebApplicationBuilder builder = WebApplication.CreateBuilder(args);
 
// Register Services.
builder.Services.AddControllers();
 
WebApplication app = builder.Build();
 
// Configure the HTTP request pipeline.
app.UseHttpsRedirection();
 
app.MapControllers();
 
app.Run();

[ApiController]
[Route("[controller]")]
public class EmployeesController : ControllerBase
{
    [HttpPost]
    public ActionResult<EmployeeCreate([FromBodyEmployee employee)
    {
        return employee;
    }
}
 
public class Employee
{
    public string FirstName { getset; }
 
    public string LastName { getset; }
 
    public Employee(string firstNamestring lastName)
    {
        FirstName = firstName;
        LastName = lastName;
    }
}

Here if we try to post a payload with null values for reference types that are not marked with nullable, ASP.NET Core by default is doing a model validation and throwing an error.

For example, here if we post a payload without setting the value for LastName, I am getting the following error.
ASP.NET Core Model Validation
But there are times, we need to offload the validation to a separate module. In that case, we can easily suppress this validation as follows.
builder.Services.AddControllers(x =>
{
    x.SuppressImplicitRequiredAttributeForNonNullableReferenceTypes = true;
});
And then, we won't be seeing that validation anymore.
ASP.NET Core: Suppress Implicit Required Attribute For Non Nullable Reference Types
Hope this helps.

Happy Coding.

Regards,
Jaliya

Friday, December 2, 2022

JsonExtensionDataAttribute in System.Text.Json.Serialization

In this post let's have a look at this nice attribute JsonExtensionDataAttribute that's available in System.Text.Json.Serialization Namespace.

I had a requirement where I have an integration API that connects a client application with a third-party API. The client application is sending some JSON that needs to be sent to the third-party API as is, and at the same time, within the integration API, I need to intercept and read some values in the JSON. The JSON schema can be huge, and the Integration API doesn't really care about the full JSON schema. So how do we define a POCO class having the properties I really care about and let other properties get deserialized/serialized without any data loss.

Let's go by an example.

Consider the following JSON schema.

string jsonString =
    """
    {
        "_id": "57d0a0a676f943a4007e1525",
        "modified": "2022-09-07T23:20:06.949Z",
        "title": "Register",
        "display": "form",
        "type": "form",
        "name": "register",
        "path": "register",
        "components": [
            {
                "label": "First Name",
                "key": "firstName",
                "type": "textfield",
                "placeholder": "",
                "prefix": "",
                "suffix": "",
                "multiple": false
            },
            {
                "label": "Last Name",
                "key": "firstName",
                "type": "textfield",
                "placeholder": "",
                "prefix": "",
                "suffix": "",
                "multiple": false
            }
        ],
        "tags": []
    }
    """;

Now let's say, I only care about _idname and type properties.

I can create a POCO class, something like below.

public class Form
{
    [JsonPropertyName("_id")]
    public string Id { getset; }
 
    public string Name { getset; }
 
    public string Type { getset; }
}

But then the issue is, upon deserialization, I am going to lose some data. And this is where JsonExtensionDataAttribute comes in handy.

public class Form
{
    [JsonPropertyName("_id")]
    public string Id { getset; }
 
    public string Name { getset; }
 
    public string Type { getset; }
 
    [JsonExtensionData]
    public Dictionary<stringobject> JsonExtensionData { getset; }
}

Now when I deserialized the jsonString to Form what's going to happen is, the properties with matching members will get their values and the properties that do not have a matching member will get added to the JsonExtensionData dictionary.

JsonSerializerOptions jsonSerializerOptions = new()
{
    PropertyNamingPolicy = JsonNamingPolicy.CamelCase
};
 
Form form = JsonSerializer.Deserialize<Form>(jsonString, jsonSerializerOptions);

Here if I have a look at the form, it's going to look like this.

Deserialization
You can see that properties with matching members got their values and the rest went into the Dictionary.

And now when I serialize the form, the values in the Dictionary are written back as expected. 

string serializedString = JsonSerializer.Serialize(form, jsonSerializerOptions);
//{
//    "_id": "57d0a0a676f943a4007e1525",
//    "name": "register",
//    "type": "form",
//    "modified": "2022-09-07T23:20:06.949Z",
//    "title": "Register",
//    "display": "form",
//    "path": "register",
//    "components": [
//        {
//            "label": "First Name",
//            "key": "firstName",
//            "type": "textfield",
//            "placeholder": "",
//            "prefix": "",
//            "suffix": "",
//            "multiple": false
//        },
//        {
//            "label": "Last Name",
//            "key": "firstName",
//            "type": "textfield",
//            "placeholder": "",
//            "prefix": "",
//            "suffix": "",
//            "multiple": false
//        }
//    ],
//    "tags": []
//}

Isn't it nice?

Happy Coding.

Regards,
Jaliya

Thursday, December 1, 2022

C# 11.0: File-local Types

In this post let's have a look at one of the newest additions to C#, which is the file access modifier. 

For types that are declared with file access modifier, its visibility or scope is only limited to the file in which it's declared.

Consider the below code.

File1.cs

namespace MyNamespace;
 
file class MyClass
{
    public static void MyMethod()
    {
        //
    }
}

File2.cs

namespace MyNamespace;
 
file class MyClass
{
    public static void MyMethod()
    {
        //
    }
}

Here I have 2 classes with the same name and within the same namespace but in different files. With C# 11.0, this will build just fine. Prior to C# 11.0, we weren't able to do this.

file keyword can be applied only to the following types.

And it's allowed only at the top-level type. 

public class MyClass
{
    // Error: Not allowed as MyOtherClass is a nested type
    file class MyOtherClass
    { 
    
    }
}

It's very unlikely we will be using this file access modifier during business application development. But wanted to share it, because in case you see it, you know what it is.

More read:
   file (C# Reference)
   File-local types

Hope this helps.

Happy Coding.

Regards,
Jaliya