Si os gusta trastear con las previews de .NET en el mismo equipo en el que estáis desarrollando proyectos que usan versiones estables, es posible que al compilar encontréis en la consola o ventana Output de vuestro IDE favorito un mensaje de error parecido al siguiente:
NETSDK1057: You are using a preview version of .NET. See: https://aka.ms/dotnet-support-policy
Básicamente, el sistema nos está informando de que estamos usando un SDK que aún está en fase de pruebas, o preview. Aunque esto no debería ser un problema porque el SDK debería ser totalmente compatible hacia atrás, simplemente es un recordatorio de que no es la versión estable y siempre podríamos encontrarnos algún problema.
Esto ocurre porque los comandos del SDK utilizan la última versión instalada en el equipo, por lo que, si hemos instalado una versión preliminar, será ésta la que se utilice. Podemos comprobarlo fácilmente ejecutando el siguiente comando en consola, que nos mostrará la versión del SDK que se está utilizando por defecto:
C:\> dotnet --version
10.0.100-preview.5.25277.14
Normalmente, el mensaje NETSDK1057 podemos ignorarlo sin problema, pero si por cualquier motivo queremos eliminarlo o simplemente queremos forzar el uso de una versión determinada del SDK de .NET en algún proyecto o de forma global, podremos hacerlo usando un archivo llamado global.json.
Forzar la versión del SDK
Para forzar el uso de una versión específica del SDK de .NET, bien sea de forma global o bien en un proyecto concreto, lo primero que debemos hacer es determinar qué versiones del SDK tenemos instaladas en nuestro equipo. Para ello, podemos ejecutar el siguiente comando en la consola:
C:\> dotnet --list-sdks
2.1.818 [C:\Program Files\dotnet\sdk]
3.1.426 [C:\Program Files\dotnet\sdk]
6.0.301 [C:\Program Files\dotnet\sdk]
6.0.321 [C:\Program Files\dotnet\sdk]
7.0.120 [C:\Program Files\dotnet\sdk]
8.0.117 [C:\Program Files\dotnet\sdk]
8.0.206 [C:\Program Files\dotnet\sdk]
8.0.411 [C:\Program Files\dotnet\sdk]
9.0.301 [C:\Program Files\dotnet\sdk]
10.0.100-preview.5.25277.14 [C:\Program Files\dotnet\sdk]
Una vez sabemos qué versiones del SDK tenemos instaladas y cuál queremos forzar, lo siguiente es crear un archivo llamado global.json. Su ubicación es importante, porque su ámbito se extiende a todos los proyectos que estén en la misma carpeta o en sus subdirectorios a cualquier nivel de profundidad.
Es decir, si creamos el archivo global.json en la raíz de un proyecto, afectará únicamente a ese proyecto y a sus subproyectos. Si lo creamos en una carpeta superior, por ejemplo en la carpeta de una solución, afectará a todos sus proyectos, que típicamente se encontrarán en subdirectorios. Si lo creamos en la carpeta raíz de un disco duro, afectará a todos los proyectos guardados en él.
El archivo global.json es un archivo JSON con una estructura muy sencilla (podéis consultarla siguiendo este enlace). Básicamente en él indicaremos la versión del SDK que queremos forzar a los proyectos que se encuentren en su ámbito, así como algunas opciones adicionales para personalizar su comportamiento.
Veamos un ejemplo sencillo. Si queremos forzar el uso de la versión 9.0.301 en un proyecto, basta con crear el archivo global.json en su raíz con el siguiente contenido:
{
"sdk": {
"version": "9.0.301"
}
}
La propia CLI de .NET también nos permite hacerlo usando el comando dotnet new global.json --sdk-version <version>, que creará el archivo global.json en la carpeta actual, forzando la versión del SDK que le indiquemos. El contenido del archivo creado será exactamente el mismo que el del ejemplo anterior:
C:\MyProject>dotnet new global.json --sdk-version 9.0.301
The template "global.json file" was created successfully.
C:\MyProject>type global.json
{
"sdk": {
"version": "9.0.301"
}
}
En cualquiera de los casos, si sobre la misma carpeta o alguna de sus subcarpetas consultamos el SDK utilizado por defecto, obtendremos el valor esperado:
C:\MyProject>dotnet --version
9.0.301
C:\MyProject>md Test
C:\MyProject>cd Test
C:\MyProject\Test>dotnet --version
9.0.301
A partir de este momento, dado que ya no estamos usando la versión preview del SDK, el mensaje de aviso habrá desaparecido 😊
Posibles efectos secundarios
Sin duda, usar global.json es una forma muy sencilla de forzar una versión del SDK de .NET en un proyecto o en un conjunto de proyectos. Sin embargo, al hacerlo también podemos estar introduciendo algunos inconvenientes que debemos considerar.
En primer lugar, si forzamos una versión del SDK que no está instalada en el equipo, obtendremos un error al intentar compilar o ejecutar el proyecto. Normalmente no ocurrirá en casos de desarrolladores aislados o si se hace de forma global, pero pueden surgir problemas si trabajamos en un equipo de desarrollo y alguno de los miembros no tiene instalada la versión del SDK que hemos forzado, pues se encontrará con el error al intentar compilar el proyecto.
Por ejemplo, si forzamos en el global.json el uso del SDK 9.0.400, que no está instalado en el equipo, al intentar compilar el proyecto obtendremos un error similar al siguiente:
C:\MyProject>dotnet build
The command could not be loaded, possibly because:
* You intended to execute a .NET application:
The application 'build' does not exist or is not a managed .dll or .exe.
* You intended to execute a .NET SDK command:
A compatible .NET SDK was not found.
Requested SDK version: 9.0.400
global.json file: C:\MyProject\global.json
También debemos tener en cuenta que al forzar una versión específica del SDK, podemos estar limitando el uso de nuevas características o mejoras que se vayan introduciendo en versiones posteriores del SDK. Es decir, si la versión estable actual es la 9.0.301 y se lanza la 9.0.400, no pasaremos a usar esta última de forma automática, será necesario actualizar el global.json para referenciar la nueva versión.
Por último, a la hora de forzar una versión del SDK, sobre todo si se hace de forma global, también es importante tener en cuenta que cada versión del SDK admite un conjunto de versiones del runtime de .NET. Por ejemplo, si forzamos el uso del SDK 9.0.301, no podremos compilar o ejecutar proyectos cuyo <TargetFramework> en el archivo .csproj sea superior a net9.0, como net10.0 o posteriores:
C:\MyProject>dotnet build
C:\Program Files\dotnet\sdk\9.0.301\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.TargetFrameworkInference.targets(166,5): error NETSDK1045: The current .NET SDK does not support targeting .NET 10.0. Either target .NET 9.0 or lower, or use a version of the .NET SDK that supports .NET 10.0. Download the .NET SDK from https://aka.ms/dotnet/download
Cómo forzar la última versión estable
Afortunadamente, muchos de estos problemas podemos solucionarlos usando opciones adicionales en el archivo global.json.
Por ejemplo, si queremos que el SDK use la última versión estable instalada en el equipo, sea cual sea su número de versión, podemos usar la opción allowPrerelease. Dado que no usamos la propiedad version para especificar una versión concreta, el sistema simplemente buscará la más reciente que no sea preview:
{
"sdk": {
"allowPrerelease": false
}
}
El valor por defecto de
allowPrereleasepuede variar según el entorno. En la CLI suele sertrue, pero si estamos en Visual Studio, depende de lo que hayamos configurado en la secciónHerramientas>Opciones>Entorno>Características de versión preliminar.
Adicionalmente, existe la propiedad rollForward, que nos permite controlar cómo se comporta el SDK cuando no existe la versión del SDK que hemos especificado en la propiedad version, o cómo actuar si existen versiones posteriores a la especificada. Pero esto, si os interesa, lo veremos en un artículo posterior, y mientras tanto, podéis consultar la documentación oficial para más detalles.
Conclusión
En resumen, el uso de global.json nos permite tener un control preciso sobre la versión del SDK de .NET utilizada en nuestros proyectos, evitando sorpresas y mensajes de advertencia relacionados con versiones preliminares. Sin embargo, es importante conocer sus implicaciones y utilizarlo de forma consciente, especialmente en entornos colaborativos.
¡Espero que os resulte útil!
Desde hace ya bastante tiempo, el equipo de .NET está introduciendo mejoras en el SDK para simplificar algunos escenarios y facilitar el acceso a la tecnología de desarrolladores que, o bien están empezando, o bien proceden de otras plataformas.
Una de estas mejoras fueron los top level statements, que permiten escribir los entry points de nuestras aplicaciones C# sin necesidad de definir una clase o un método Main. También las directivas using globales e implícitas ayudaban a reducir el boilerplate necesario para escribir una aplicación C#.
Pero esta vez han ido más lejos 🙂
Con .NET 10, se está trabajando en eliminar toda la ceremonia necesaria para crear y ejecutar una aplicación .NET simple. De la misma forma que se puede hacer en otras plataformas y lenguajes como Node.js o Python, ahora bastará con crear un archivo con extensión .cs y ejecutar el comando dotnet run para compilar y ejecutar el archivo sobre la marcha. Es decir, pasamos de aplicaciones basadas en proyecto a aplicaciones basadas en archivos.
Pero, además, esto abre interesantes posibilidades para la creación de prototipos, pruebas rápidas o incluso para la creación de scripts que aprovechen el poder de .NET y C# sin necesidad de crear un proyecto completo.
Lo vemos en profundidad a continuación.
Cuando usamos tipos enumerados en C#, muchas veces buscamos seguridad. Los valores de un enum son constantes conocidas de antemano y se comprueban en tiempo de compilación, lo que evita asignaciones inválidas que podrían derivar en errores en tiempo de ejecución.
También, el hecho de poder acceder a los valores del enum utilizando nombres o identificadores descriptivos da lugar a un código más legible y fácil de mantener. Y encima, las ayudas para el autocompletado y descubrimiento de valores posibles que nos proporcionan los IDEs modernos nos ayudan a ser más productivos. Todo son ventajas 🙂
Sin embargo, los enum de C# sólo permiten que sus valores subyacentes sean numéricos ( byte, sbyte, short, ushort, int -el tipo por defecto-, uint, long o ulong). Esto puede suponer una limitación en casos en los que nos vendría bien disfrutar de todos los beneficios anteriores, pero usando valores string... es decir, deberíamos poder definir un tipo que pueda contener únicamente un conjunto de cadenas de texto predefinidas.
Algunos lenguajes como TypeScript, Python o Swift soportan de forma nativa la creación de enumerados de texto; en cambio, en C# no tenemos esta posibilidad. Pero bueno, no todo está perdido... gracias a la flexibilidad del lenguaje, podemos conseguir algo bastante parecido 😉
Hace unas semanas estuvimos hablando de los atributos englobados en la categoría de "caller information" de .NET: [CallerFilePath], [CallerLineNumber], [CallerMemberName] y [CallerArgumentExpression]. Como vimos, estos atributos permiten que un método o función conozca información sobre el método que lo ha llamado, como el nombre del archivo, el número de línea, el nombre del método o la expresión de argumento.
Sin embargo, ninguna de estas opciones nos permite saber cuál es la clase que contiene el código que ha llamado al método que está actualmente en ejecución, algo que podría venir bien en algunos escenarios. Por ejemplo, recientemente me lo he encontrado revisando un proyecto en el que se utilizaba el sistema de logging NLog, donde encontraba un código como el siguiente para obtener y almacenar de forma estática un logger para la clase actual:
public static class Program
{
private static readonly NLog.Logger Logger = NLog.LogManager.GetCurrentClassLogger();
public static void DoSomething()
{
try
{
Logger.Info("Hello world");
System.Console.ReadKey();
}
catch (Exception ex)
{
Logger.Error(ex, "Goodbye cruel world");
}
}
}
A la vista de estas líneas, puede parecernos difícil deducir qué hace ese método GetCurrentClassLogger() por detrás para saber cuál es la clase actual y crearle un logger específico para ella.
En este post, vamos a abrir el capó para ver la "magia" que hace esto posible.
En C#, existen atributos que no están diseñados para añadir metadatos consumibles en tiempo de ejecución, sino que están pensados para ser interpretados por el compilador.
Entre ellos, se encuentran los atributos englobados en la categoría "caller information", que ofrecen la posibilidad de que un método o función conozca información sobre el método que lo ha llamado, como el nombre del archivo, el número de línea, el nombre del método o la expresión de argumento.
Esto puede ser muy interesante en diversos escenarios, pero probablemente el ejemplo más claro lo encontramos en la generación de trazas y puntos de control, puesto que, en lugar de tener que escribir manualmente el nombre del método o el número de línea, podemos obtenerlos de forma automática.
Lo vemos a continuación.
Cuando hablamos de comparar números enteros, está claro que 1 es menor que 2, y éste menor que 10:
1 < 2 < 10
Sin embargo, si estos valores están en una cadena de texto, la comparación se hace carácter a carácter, y en ese caso "10" es menor que "2":
"1" < "10" < "2"
Este criterio de ordenación puede ser molesto en muchos escenarios, sobre todo cuando queremos ordenar o comparar valores numéricos se encuentran en el interior de cadenas de texto donde hay otros contenidos. En todos estos casos, la comparación lexicográfica tradicional no nos dará los resultados esperados:
- Una lista de nombres de archivo como "file1.txt", "file2.txt"... así hasta "file10.txt". Al ordenarlos, "file10.txt" aparecerá antes que "file2.txt".
- Versiones de un software, como "1.2" y "1.10". Si las comparamos, la versión "1.10" será anterior a la "1.2", cuando en realidad es al revés.
- De la misma forma, una lista de direcciones IP, como "10.10.2.10", "10.10.10.10", si queremos mostrarlas de forma ordenada, obtendremos "10.10.10.10" y "10.10.2.10", que no es su orden numérico real.
- O simplemente, si comparamos las horas "01:10" con "1:10", la primera será anterior a la segunda, cuando en realidad se trata de la misma hora.
Hasta la versión 10 de .NET no existía una forma sencilla de resolver estos casos, por lo que teníamos que implementar soluciones propias, bastante farragosas en algunos casos, o bien utilizar bibliotecas de terceros. Sin embargo, en .NET 10 se ha añadido una forma nativa para conseguirlo, que vemos a continuación.
En nuestras aplicaciones, es relativamente frecuente tener que buscar una serie de valores dentro de un conjunto de datos. Existen muchos escenarios, como cuando tenemos que buscar una serie de palabras dentro de un texto largo, o comprobar si todos los caracteres de un string pertenecen a un conjunto de caracteres válidos.
Por ejemplo, centrándonos en este último caso, imaginad que queremos comprobar si el contenido de una cadena de texto de tamaño arbitrario contiene únicamente una serie de caracteres válidos (por ejemplo, las vocales). La implementación que se nos ocurriría de forma natural sería muy simple: recorrer la cadena de texto de entrada, y, por cada carácter, comprobar si está en el conjunto de caracteres permitidos. ¿Fácil, no?
Sin embargo, como veremos en este post, hay formas mucho más eficientes de hacerlo.
Si lleváis algunos años en esto, seguro recordaréis que en ASP.NET "clásico", los settings de las aplicaciones eran valores inmutables. Se guardaban habitualmente en el célebre archivo Web.config, y cualquier cambio a este archivo implicaba reiniciar la aplicación para que los cambios tuvieran efecto.
En ASP.NET Core, los settings son mucho más flexibles: se pueden cargar desde diferentes orígenes, pueden almacenarse en distintos formatos, y es posible modificarlos en caliente sin necesidad de reiniciar la aplicación. Pero además, ofrecen otra capacidad que es interesante conocer: podemos detectar y reaccionar a cambios en los settings en tiempo real, es decir, en el mismo momento en que se producen.
Para ello, básicamente tendremos que bindear una clase personalizada a la sección de settings que nos interese, y luego utilizar la interfaz IOptionsMonitor, para registrar un manejador personalizado que se ejecute cada vez que se produzca un cambio en los valores de configuración que estamos monitorizando.
En este post vamos a ver cómo hacerlo, paso a paso.
Habitualmente los paquetes NuGet que usamos en un proyecto se registran en entradas <PackageReference> de su archivo .csproj. Es un mecanismo sencillo y efectivo cuando trabajamos con un único proyecto o un número reducido de ellos.
Sin embargo, cuando la cosa crece y estamos trabajando con muchos proyectos que usan paquetes comunes cuyas versiones deben estar alineadas, todo se complica un poco, y trabajar con ellos se puede convertir en algo bastante tedioso. Y más aún si no usamos una herramienta visual como NuGet Package Manager de Visual Studio.
Para estos escenarios, NuGet 6.2, lanzado en agosto de 2023 y presente por defecto en todas las instalaciones actualizadas de .NET y Visual Studio, introdujo el concepto de gestión centralizada de paquetes (en inglés, Central Package Management o CPM). Esta funcionalidad nos brinda la posibilidad de definir en un archivo independiente los paquetes utilizados, con sus versiones correspondientes, de forma que todos los proyectos de la solución puedan hacer referencia a él y mantener sus dependencias actualizadas.
Cuando estamos usando alguna clase de .NET en nuestro código, a veces tenemos interés o necesidad de ver qué hace por dentro, para lo que nos gustaría tener acceso rápido a su código fuente. Aunque los IDEs modernos disponen en muchos casos de herramientas o extensiones que lo permiten, está bien saber que hay otras fórmulas sencillas para conseguirlo muy rápida y cómodamente.
Hace poco me he topado con una de ellas, que me ha parecido muy útil y quería compartirla con vosotros, por si hay alguien más que aún no la conoce: la página https://source.dot.net.
Me encanta LINQ. Bueno, ciertamente la sintaxis de consultas integrada en el lenguaje no la uso desde hace muchísimos años, pero los métodos de extensión que proporciona son una maravilla para recorrer y operar sobre colecciones de datos en memoria o almacenados en sistemas externos.
LINQ ha sido uno de los objetivos de .NET 9. Además de mejorarlo internamente y optimizar su rendimiento (en algunos casos, considerablemente), se han incluido tres nuevos métodos, CountBy(), AggregateBy() e Index(), que amplían las posibilidades que teníamos hasta el momento, simplificando la escritura de código y aumentando su legibilidad en algunos escenarios.
Vamos a verlos en detalle.
Hace unas semanas estuvimos echando un vistazo a HybridCache, la alternativa de .NET 9 al sistema de caché distribuida que apareció con .NET Core años atrás. Como vimos entonces, HybridCache aporta una serie de ventajas respecto a su predecesor, como la protección contra estampidas, la caché multinivel, invalidación por etiquetas, y otras mejoras.
Sin embargo, también introduce algunos inconvenientes que debemos tener en cuenta si queremos sacarle el máximo partido. En esta ocasión, nos centraremos en la penalización debido a excesiva deserialización de objetos de la caché local, un detalle que puede pasar desapercibido pero que puede tener un impacto significativo en el rendimiento de nuestra aplicación.
La clase Task de .NET dispone de algunos métodos estáticos para trabajar con colecciones de tareas de forma sencilla. Uno de ellos es Task.WhenAll(), que nos permite esperar a que todas las tareas que le pasemos como argumento se completen, o Task.WhenAny() para esperar a que finalice sólo alguna de ellas.
Sin embargo, hasta ahora no existía una forma sencilla y directa de procesar las tareas conforme se fueran completando. O bien esperábamos a que todas finalizaran con Task.WhenAll(), o bien teníamos que crear un bucle que fuera esperando la finalización de la siguiente tarea con Task.WhenAny(), saliendo cuando todas hubieran acabado.
Afortunadamente, .NET 9 ha añadido el nuevo método llamado Task.WhenEach() que lo pone más fácil, permitiéndonos detectar sobre la marcha la finalización de las tareas conforme va ocurriendo. Esto nos facilita el proceso de sus resultados secuencialmente, en el orden en el que se completan y sin esperar a que acaben todas.
Vamos a verlo, pero para entenderlo mejor, primero vamos a recordar las opciones que teníamos antes de la llegada de este método.
Una de las novedades más destacables de .NET 9 es, sin duda, el nuevo sistema de caché híbrida (Hybrid cache), una puesta al día del sistema de caché distribuida que nos acompaña desde las primeras versiones de .NET Core, y al que iban haciendo falta ya algunas mejoras.
Este nuevo sistema está construido encima de la infraestructura de caching existente (Microsoft.Extensions.Caching), añadiendo mejoras que hacen que su uso sea más sencillo y contemplando de serie funcionalidades que antes nos veíamos obligados a implementar manualmente.
Vamos a echarle un vistazo a sus principales características :)
Disclaimer: lo que vamos a ver a continuación está basado en .NET 9 RC2, por lo que todavía es posible que haya cambios en la versión final.
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.
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...
Cuando trabajamos con diccionarios en .NET, es muy común comprobar si existe un elemento con una clave determinada antes de obtenerlo para evitar una excepción KeyNotFoundException:
var numbers = new Dictionary<int, string>()
{
[1] = "One",
[2] = "Two",
[3] = "Three"
};
// Aseguramos que el elemento existe antes de obtenerlo
if (numbers.ContainsKey(3))
{
Console.WriteLine(numbers[3]);
}
Sin embargo, esta comprobación tiene coste. Es decir, aunque el acceso a los diccionarios sea muy rápido -O(1)-, no quiere decir que no consuma tiempo, por lo que es interesante conocer alternativas más eficientes para estos escenarios.
Hace poco vimos cómo serializar y deserializar datos en JSON de forma personalizada usando custom converters e implementamos un ejemplo simple capaz de introducir en campos de tipo int de .NET casi cualquier valor que pudiera venir en un JSON.
Pero como comentamos en su momento, la serialización y deserialización de objetos más complejos no es una tarea tan sencilla y requiere algo más de esfuerzo. En este post vamos a ver la solución para un escenario que creo que puede ser relativamente habitual: deserializar un objeto JSON a un diccionario Dictionary<string, object>.
En otras palabras, queremos que funcione algo como el siguiente código:
using static System.Console;
...
var json = """
{
"name": "Juan",
"age": 30
}
""";
var dict = ... // Código de deserialización
WriteLine($"{dict["name"]} tiene {dict["age"]} años"); // --> Juan tiene 30 años
Hace poco, andaba enfrascado en el proceso de modernización de una aplicación antigua que, entre otras cosas, guardaba datos en formato JSON en un repositorio de archivos. Dado que se trataba de una aplicación creada con .NET "clásico", la serialización y deserialización de estos datos se realizaba utilizando la popular biblioteca Newtonsoft.Json.
Al pasar a versiones modernas de .NET, esta biblioteca ya no es la mejor opción, pues ya el propio framework nos facilita las herramientas necesarias para realizar estas tareas de forma más eficiente mediante los componentes del espacio de nombres System.Text.Json. Y aquí es donde empiezan a explotar las cosas 😉.
Si habéis trabajado con este tipo de asuntos, probablemente habréis notado que, por defecto, los componentes de deserialización creados por James Newton-King son bastante permisivos y dejan pasar cosas que System.Text.Json no permite. Por ejemplo, si tenemos una clase .NET con una propiedad de tipo string y queremos deserializar un valor JSON numérico sobre ella, Newtonsoft.Json lo hará sin problemas, pero System.Text.Json nos lanzará una excepción. Esa laxitud de Newtonsoft.Json es algo que en ocasiones nos puede venir bien, pero en otras puede puede hacer pasar por alto errores en nuestros datos que luego, al ser procesados por componentes de deserialización distintos, podrían ocasionar problemas.
Por ejemplo, observad el siguiente código:
var json = """
{
"Count": "1234"
}
""";
// Deserializamos usando Newtonsoft.Json:
var nsj = Newtonsoft.Json.JsonConvert.DeserializeObject<Data>(json);
Console.WriteLine("Newtonsoft: " + nsj.Count);
// Intentamos deserializar usando System.Text.Json
// y se lanzará una excepción:
var stj = System.Text.Json.JsonSerializer.Deserialize<Data>(json);
Console.WriteLine("System.Text.Json: " + stj.Count);
Console.Read();
// La clase de datos utilizada
record Data(int Count);
Para casos como este, nos vendrá bien conocer qué son los custom converters y cómo podemos utilizarlos.
Sabemos que está feo y no sea especialmente recomendable en muchos casos, pero hay veces en las que es totalmente necesario acceder a miembros privados de una clase. Por ejemplo, sería un requisito imprescindible si fuéramos a implementar un serializador o deserializador personalizado, o necesitásemos clonar objetos, o simplemente realizar pruebas unitarias a una clase que no ha sido diseñada para ello.
Para conseguirlo, siempre hemos utilizado los mecanismos de introspección de .NET, conocidos por todos como reflexión o por su término en inglés reflection. Por ejemplo, imaginemos una clase como la siguiente, virtualmente inexpugnable:
public class BlackBox
{
private string _message = "This is a private message";
private void ShowMessage(string msg) => Console.WriteLine(msg);
public override string ToString() => _message;
}
Aunque a priori no podemos hacer nada con ella desde fuera, usando reflexión podríamos acceder sin problema a sus miembros privados, ya sean propiedades, campos, métodos o cualquier tipo de elemento, como podemos ver en el siguiente ejemplo:
var instance = new BlackBox();
// Obtenemos el valor del campo privado _message:
var field = typeof(BlackBox)
.GetField("_message", BindingFlags.NonPublic | BindingFlags.Instance);
var value = field!.GetValue(instance);
// Ahora llamamos al método privado ShowMessage():
var method = typeof(BlackBox)
.GetMethod("ShowMessage", BindingFlags.NonPublic | BindingFlags.Instance);
method.Invoke(instance, [value]);
// Al ejecutar, se nuestra en consola: "This is a private message"
Sin embargo, de todos es sabido que la reflexión es un mecanismo muy lento, a veces farragoso en su implementación y, sobre todo, incompatible con tree-shaking, que es como se suele llamar la técnica que usan los compiladores de eliminar del código final todas las clases, métodos y propiedades que no se utilizan en el código final. Esta técnica va tomando cada vez más relevancia conforme los compiladores son capaces de crear directamente ejecutables nativos puros, porque permiten reducir de forma considerable el peso de los artefactos creados.
Por esta razón, en .NET 8 se ha incluido una nueva fórmula para acceder a miembros privados, mucho más eficiente y amistosa con AOT, porque se lleva a tiempo de compilación algo que antes obligatoriamente se resolvía en tiempo de ejecución.
