Aquí tenemos la recopilación de enlaces de la semana. Entre ellos, me han llamado especialmente la atención los datos que muestra Trevor I. Lasn en su artículo sobre el factor edad en el mundo tecnológico, probablemente porque estoy en el 15% del que habla, los desarrolladores que vuelan ya por encima de los 45 tacos 😆

Y aparte, como siempre, un poco de ASP.NET Core, datos, IA, programación web y otros temas que espero que os resulten interesantes 🙂

Por si te lo perdiste...

• Custom middlewares en ASP.NET Core
  José M. Aguilar
• ¡No uses Replace() para eliminar los guiones de un GUID en .NET!
  José M. Aguilar

.NET Core / .NET

• .NET 9 Release Candidate 2 is now available!
  .NET Team
• Embedding Python into your .NET project with CSnakes
  Tony Baloney
• Centralize your packages in .NET with NuGet
  Steven Giesel
• Unleashing .NET 9: Key Performance Boosts and Pitfalls Compared to .NET 8
  David McCarter
• .NET 8 vs .NET 9: What's the Difference and Should you Migrate?
  Cheyenne Sokkappa
• Replacing Exceptions-as-flow-control with the result pattern
  Andrew Lock
• How To Simplify Assertions in Unit and Integration Tests with Verify in .NET
  Anton Martyniuk
• Domain Events with .NET
  Visit profile
• Avoiding Repetitive Code With Metalama
  Gael Fraiteur
• Using Windows Error Reporting in .NET
  Kevin Gosse
• Have you ever memory-profiled in a unit test?
  Dennis Frühauff
• Engineering the Scalable Vector Extension in .NET
  Kunal Pathak
• Typed chat completions with OpenAI and .NET 9
  Daniel Cazzulino
• Cancellation, Part 6: Linking
  Stephen Cleary
• Advanced Unit Testing in .NET with xUnit, NSubstitute, and AutoFixture: A Deep Dive into my HangfireDemoApi
  Juan Luis Guerrero

Probablemente, todos hemos usado en algún momento el método Guid.NewGuid() de .NET para generar identificadores únicos globales. Y muchos hemos sufrido con el problema que supone su (pseudo) aleatoriedad, principalmente cuando necesitamos ordenarlos... sobre todo si su destino final es acabar siendo el campo clave de una base de datos relacional.

Pero pocos éramos conscientes de que el método Guid.NewGuid() de .NET retorna un GUID versión 4, y que existen otras versiones de UUID (¡hasta 8!) que pueden resultar más beneficiosas en determinados escenarios.

Una semana más, aquí tenéis los enlaces recopilados durante la semana pasada, con mucho protagonismo de los últimos lanzamientos de OpenAI que, si usáis sus APIs o planeáis hacerlo, seguro que os interesarán: la API realtime y el prompt caching. 

Por si te lo perdiste...

• El filtro [OutputCache], por fin de vuelta en ASP.NET Core
  José M. Aguilar
• Gestionar errores 404 (y otros) en ASP.NET Core y MVC
  José M. Aguilar

.NET Core / .NET

• What's New in .NET 9: A Developer's Perspective
  Vinoth Kumar Sundara Moorthy
• How To Test Integrations with APIs Using WireMock in .NET
  Anton Martyniuk
• How to use IHttpClientFactory and WireMock.NET together using Moq
  Davide Bellone
• Getting the Running Operating System in C#
  Bryan Hogan
• Serilog fallback sinks
  Nicholas Blumhardt
• An Efficient Dictionary for IPAddress Tracking using .NET 9 with AlternateLookup and IAlternateEqualityComparer
  Steve Gordon
• Effortlessly Upload Files and Data in .NET applications using HttpClient
  Hariom Dubey
• .NET's ActivityListener sampling API
  Nicholas Blumhardt
• Visualizing the Serilog 4.1 batch retry algorithm
  Nicholas Blumhardt

Como sabemos, una forma habitual de registrar servicios en el contenedor de dependencias de .NET consiste en indicar al framework la implementación de la interfaz o clase abstracta que debe ser utilizada cuando se solicite una instancia de la misma. Por ejemplo, en el siguiente código, que podría pertenecer a la inicialización de una aplicación ASP.NET Core, se registra la implementación FriendDbRepository para la interfaz IFriendRepository con un ámbito scoped o por petición:

builder.Services.AddScoped<IFriendRepository, FriendDbRepository>();

Hecho esto, podríamos solicitar una instancia de IFriendRepository en cualquier parte de nuestra aplicación que admita inyección de dependencias, como los controladores, manejadores Minimal API, otras dependencias, etc. El inyector encargará de proporcionarnos una instancia de FriendDbRepository allá donde la necesitemos:

public class FriendsController: Controller
{
    public FriendsController(IFriendRepository friendRepository)
    {
        // ... Aquí la tenemos!
    }
}

O bien, podríamos obtenerla directamente desde la colección de servicios:

public void DoSomething(IServiceProvider services)
{
    var repo = services.GetRequiredService<IFriendRepository>();
    ...
}

Como vemos en ambos casos, la única forma disponible para identificar el servicio que deseamos obtener es utilizar su tipo, o muy habitualmente, la abstracción (interfaz o clase abstracta) a la que está asociado.

Pero eso cambió con la llegada de .NET 8...

Una semana más, comparto la recopilación de enlaces a contenidos que me han parecido interesantes.

De esta tirada, me quedo con "Las interfaces describen qué, las implementaciones describen cómo", un gran título para el artículo de Steve Smith sobre conceptos que todos deberíamos tener claros.

Por si te lo perdiste...

• Cómo crear componentes Blazor usando directamente C# en lugar de la sintaxis Razor
  José M. Aguilar
• Obtener la última excepción producida en ASP.NET Core
  José M. Aguilar

.NET Core / .NET

• (Non-)Nullable Reference Types in C#
  Paulo Zemek
• Conditional compilation symbols in C#
  Bart Wullems
• FSZipper in C#
  Mark Seemann
• Preparing for .NET 9
  Mattias Karlsson
• A Better Way to Handle Entity Identification in .NET with Strongly Typed IDs
  Anton Martyniuk
• Boosting Loop Performance in .NET: The Simple Trick of Caching Array Length
  David McCarter
• Mastering C# 12: New Features and How to Use Them
  Cosmic Meta
• .NET Terminology
  Rockford Lhotka
• Interact with Ollama through C#
  Bart Wullems
• Service Discovery in .NET
  Ricardo Peres
• Tired of other developers?
  Stanislav Nedelchev
• Implementing Blocked Floyd-Warshall algorithm for solving all-pairs shortest path problem in C#
  Oleg Karasik

Acercándose el lanzamiento de .NET 9 el próximo mes de noviembre, podemos ver ya algunas de las novedades que traerá la nueva versión, con las que podemos jugar desde hace algunos meses instalando las previews que van apareciendo cada mes.

En esta ocasión vamos a ver algunas novedades más interesantes que se han añadido a la biblioteca de serialización JSON oficial, conocida por todos como System.Text.Json:

• Opciones de personalización de la indentación
• Singleton de opciones de serialización y deserialización para la web
• Soporte de anotaciones de anulabilidad
• Comprobación de parámetros obligatorios del constructor
• Descripción de tipos .NET usando JSON Schema

¡Vamos a ello!

Nota: Este artículo está basado en .NET 9 RC1, por lo que algunas de las características descritas podrían cambiar en la versión final.

1. Opciones de personalización de la indentación

Hasta .NET 8, las opciones de personalización relativas al indentado de JSON generado era bastante limitada. De hecho, sólo podíamos decidir si lo queríamos indentar o no usando la propiedad WriteIndented de JsonOptions:

var obj = new
{
    Name = "John",
    Age = 30,
    Address = new { Street = "123 Main St", City = "New York" }
};

var jsonOptions = new JsonSerializerOptions()
{
    WriteIndented = true, // Queremos indentar el JSON
};

Console.WriteLine(JsonSerializer.Serialize(obj, jsonOptions));

El resultado será siempre un JSON indentado a dos espacios como el siguiente:

{
  "Name": "John",
  "Age": 30,
  "Address": {
    "Street": "123 Main St",
    "City": "New York"
  }
}

En .NET 9 disponemos de dos nuevas propiedades para personalizar la indentación del JSON generado. La propiedad IndentCharacter permite especificar el carácter a utilizar (espacio o tabulador, exclusivamente), y mediante IndentSize podemos indicar el número de caracteres a utilizar en cada nivel de indentación.

var jsonOptions = new JsonSerializerOptions()
{
    WriteIndented = true,
    IndentCharacter = '\t',
    IndentSize = 2
};

Console.WriteLine(JsonSerializer.Serialize(obj, jsonOptions));

En este caso, el resultado será así (2 tabuladores por nivel de indentación):

{
                "Name": "John",
                "Age": 30,
                "Address": {
                                "Street": "123 Main St",
                                "City": "New York"
                }
}

2. Singleton de opciones de serialización y deserialización para la web

ASP.NET Core utiliza una configuración por defecto para serializar y deserializar objetos JSON, que ahora está disponible de forma pública en la propiedad JsonSerializerOptions.Web.

El objeto retornado es un singleton JsonSerializerOptions de sólo lectura, que estará disponible en cualquier punto de la aplicación.

Por defecto, este objeto está configurado de la siguiente manera:

• PropertyNameCaseInsensitive está establecido a true, por lo que la deserialización de propiedades es insensible a mayúsculas y minúsculas.
• JsonPropertyNamingPolicy tiene el valor JsonNamingPolicy.CamelCase, así que las propiedades se serializan en formato camelCase, el habitual en JavaScript y JSON.
• NumberHandling es JsonNumberHandling.AllowReadingFromString, así que será posible deserializar números que vengan especificados como texto.

Un ejemplo de utilización de este objeto sería el siguiente:

var obj = new
{
    Name = "John",
    Age = 30,
    Address = new { Street = "123 Main St", City = "New York" }
};

Console.WriteLine(JsonSerializer.Serialize(obj, JsonSerializerOptions.Web));

// Resultado:
// {"name":"John","age":30,"address":{"street":"123 Main St","city":"New York"}}

Dado que el objeto es de sólo lectura, no podemos modificar sus propiedades. Si necesitásemos algún tipo de cambio en la configuración, podríamos crear una configuración nueva partiendo de él, e introducir las modificaciones deseadas, por ejemplo:

var jsonOptions = new JsonSerializerOptions(JsonSerializerOptions.Web)
{
    WriteIndented = true,
    IndentCharacter = '\t',
    IndentSize = 2
};

3. Soporte de anotaciones de anulabilidad

En .NET 8 y versiones anteriores, System.Text.Json no respetaba las anotaciones de anulabilidad de C# en las propiedades de los tipos de referencia. Por ejemplo, si tenemos una propiedad de tipo referencia que no puede ser nula como en el siguiente caso, podemos ver que el siguiente código deserializará sobre ella un valor nulo sin problema:

var myFriend = JsonSerializer.Deserialize<Friend>("""{ "Name": null }""");
Console.WriteLine(myFriend.Name ?? "Unknown"); // Muestra "Unknown"

// Friend tiene un campo "Name" que no puede ser nulo
public record Friend (string Name);

A partir de .NET 9, podemos indicar opcionalmente a System.Text.Json que respete la anulabilidad de propiedades, es decir, si una propiedad no es anulable, al deserializarla no podremos establecerla al valor nulo.

Esto podemos conseguirlo simplemente estableciendo a true la propiedad RespectNullableAnnotations de las opciones de deserialización:

var opt = new JsonSerializerOptions() { RespectNullableAnnotations = true };
var myFriend = JsonSerializer.Deserialize<Friend>("""{ "Name": null }""", opt);
Console.WriteLine(myFriend.Name ?? "Unknown"); // Lanza una excepción

Según la documentación, otra posibilidad es hacerlo de forma global para todo el proyecto, añadiendo la siguiente configuración en el archivo .csproj:

<ItemGroup>
  <RuntimeHostConfigurationOption 
     Include="System.Text.Json.JsonSerializerOptions.RespectNullableAnnotations" 
     Value="true" />
</ItemGroup>

Supongo que, debido a que aún estamos jugando con versiones preview del compilador, esta última opción no conseguí que me funcionara.

Otra cosa que he visto curiosa es que el siguiente código, a mi entender, debería lanzar una excepción, pero no lo hace:

var opt = new JsonSerializerOptions() { RespectNullableAnnotations = true };

var myFriend = JsonSerializer.Deserialize<Friend>("{ }", opt);
Console.WriteLine(myFriend.Name ?? "Unknown"); // Muestra "Unknown"

En principio, si la propiedad Name hemos dicho que no era anulable, ¿no debería lanzar una excepción al deserializar un objeto que no especifica su valor? Pues no, y parece ser que se trata de un comportamiento esperado; hay un interesante hilo al respecto en GitHub discutiendo el por qué de esta decisión, aunque en el siguiente apartado veremos que existe en algunos casos existe una forma alternativa de evitar esta situación.

Por último, la propiedad RespectNullableAnnotations también afecta a la serialización, de forma que si una propiedad no anulable tiene un valor nulo al ser serializada, se lanzará una excepción:

var opt = new JsonSerializerOptions() { RespectNullableAnnotations = true };

var myFriend = new Friend(null);
Console.WriteLine(JsonSerializer.Serialize(myFriend, opt)); // Lanza una excepción

4. Comprobación de parámetros obligatorios del constructor

En .NET 8 y anteriores, los parámetros del constructor del tipo a deserializar eran tratados como siempre como opcionales. Por esta razón, el código siguiente no provoca errores:

var myFriend = JsonSerializer.Deserialize<Friend>("""{ }""");
Console.WriteLine(myFriend.Name ?? "Unknown"); // Muestra "Unknown"

public record Friend(string Name);

En .NET 9, es posible indicar al deserializador que queremos respetar los parámetros requeridos del constructor, de forma que si no pueden ser satisfechos se lanzará una excepción. Esto se consigue con el nuevo flag RespectRequiredConstructorParameters en las opciones de deserialización:

var opt = new JsonSerializerOptions() { RespectRequiredConstructorParameters = true };

var myFriend = JsonSerializer.Deserialize<Friend>("""{ }""", opt);
Console.WriteLine(myFriend.Name ?? "Unknown"); // Lanza una excepción

La excepción, de tipo JsonException es bastante clara en su texto de descripción: 'JSON deserialization for type 'Friend' was missing required properties including: 'Name'.'.

Como en el caso anterior, este comportamiento puede ser también configurado de forma global para todo el proyecto, añadiendo la siguiente configuración en el archivo .csproj:

<ItemGroup>
  <RuntimeHostConfigurationOption 
      Include="System.Text.Json.JsonSerializerOptions.RespectRequiredConstructorParameters" 
      Value="true" />
</ItemGroup>

Y como en el caso anterior, tampoco he conseguido que me funcione de esta forma 😆 Esperemos que las siguientes preview o la versión final lo solucionen.

5. Descripción de tipos .NET usando JSON Schema

La nueva clase estática JsonSchemaExporter expone el método GetJsonSchemaAsNode(), que permite obtener el esquema JSON de un tipo .NET en forma de objeto JsonNode.

Su uso es muy sencillo, simplemente pasamos las opciones a utilizar para serializar el esquema, y el tipo del que queremos obtenerlo. Observad el siguiente ejemplo:

var schema = JsonSchemaExporter.GetJsonSchemaAsNode(
    JsonSerializerOptions.Default, 
    typeof(Friend)
);
Console.WriteLine(schema);

public record Friend(string Name, string? nickName, int Age = 20);

El resultado que obtendremos es una descripción del tipo, siguiendo el estándar JSON Schema, que en este caso sería algo así:

{
  "type": [
    "object",
    "null"
  ],
  "properties": {
    "Name": {
      "type": "string"
    },
    "nickName": {
      "type": [
        "string",
        "null"
      ]
    },
    "Age": {
      "type": "integer",
      "default": 20
    }
  },
  "required": [
    "Name",
    "nickName"
  ]
}

Conclusión

En este artículo hemos visto algunas de las novedades que traerá la nueva versión de .NET 9 en la biblioteca de serialización JSON oficial, System.Text.Json. Aunque no son cambios revolucionarios, sí que son mejoras que facilitarán la vida a los desarrolladores que trabajamos con JSON en nuestras aplicaciones.

¡Espero que os haya resultado interesante!