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.
En JavaScript es frecuente encontrar expresiones como esta para comprobar si un objeto tiene valor (o, al menos, si su valor es uno de los reconocidos como truthy):
const friend = getFriend(1); // Obtiene un objeto friend, o null si no existe
if (friend) {
// Hacer algo con el objeto friend
}
Debido a su sistema de tipos estricto, en C# no es posible hacer lo mismo de forma directa, tenemos que comprobar si el objeto es null, por ejemplo así:
var friend = GetFriend(1); // Obtiene un objeto friend, o null si no existe
if (friend is not null) {
// Hacer algo con el objeto friend
}
Sin embargo, con muy poco esfuerzo podemos hacer que C# acepte la sintaxis de JavaScript para ese tipo de chequeos de nulidad, implementando en nuestra clase un conversor implícito a bool. Lo 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.
Normalmente los servicios usados por nuestra aplicación ASP.NET Core los registraremos en el contenedor de dependencias, para luego ir satisfaciendo los requisitos de los distintos componentes gracias a los mecanismos de inyección de dependencias que nos proporciona el framework. De estos servicios, aquellos que se registran como scoped se liberarán automáticamente al finalizar el proceso de la petición.
Sin embargo, si instanciamos manualmente un servicio durante el proceso de la petición, tendremos que encargarnos nosotros mismos de liberarlo cuando ya no sea necesario. Los que tengan un ámbito de vida corto, normalmente los crearemos y destruiremos utilizando using en algunos de sus sabores (como bloque o con ámbito local implícito), pero cuando queremos que pueda ser compartido entre varios componentes, no es sería tan sencillo... si no fuera porque el framework ya lo ha tenido en cuenta 🙂
Para estos casos, ASP.NET Core proporciona el extensor RegisterForDispose(), que nos permite registrar un servicio para que se libere automáticamente al finalizar la petición.
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.
Como sabemos, es muy sencillo implementar servicios en segundo plano alojados en el interior de aplicaciones ASP.NET Core porque el framework nos proporciona infraestructura que simplifica la tarea, permitiendo que nos enfoquemos en la lógica de negocio que queremos ejecutar en background en lugar de tener que preocuparnos de los aspectos de más bajo nivel necesarios para hacer que funcione.
En la práctica, basta con heredar de la clase BackgroundService y sobreescribir el método ExecuteAsync para implementar la lógica que queremos ejecutar en segundo plano. Por ejemplo, el siguiente servicio se encarga de escribir un mensaje en la consola cada segundo:
public class MyBackgroundService : BackgroundService
{
protected override async Task ExecuteAsync(CancellationToken stoppingToken)
{
while (!stoppingToken.IsCancellationRequested)
{
Console.WriteLine($"Current time: {DateTime.Now:T}");
await Task.Delay(1000, stoppingToken);
}
}
}
Luego tendríamos registrar este servicio en el contenedor de dependencias de ASP.NET Core, de forma que el framework lo detectará automáticamente y lo lanzará cuando la aplicación sea iniciada:
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddHostedService<MyBackgroundService>();
...
Al ejecutar, veremos que, en la consola donde hemos lanzado la aplicación, se escribirá periódicamente la hora desde la tarea en segundo plano:
Current time: 13:34:06
info: Microsoft.Hosting.Lifetime[14]
Now listening on: https://localhost:7080
info: Microsoft.Hosting.Lifetime[14]
Now listening on: http://localhost:5148
info: Microsoft.Hosting.Lifetime[0]
Application started. Press Ctrl+C to shut down.
info: Microsoft.Hosting.Lifetime[0]
Hosting environment: Development
info: Microsoft.Hosting.Lifetime[0]
Content root path: D:\Projects\BackgroundServiceCrash
Current time: 13:34:07
Current time: 13:34:08
Pero bueno, no es esto de lo que quería hablar, sino de lo que ocurre cuando en uno de estos servicios en segundo plano se produce un error... porque ojo, que si no tenemos cuidado puede tumbar completamente nuestra aplicación.
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.
Hoy me voy a salir un poco de las temáticas habituales para compartir un pequeño truco que llevaba buscando desde hace meses, pero que hasta ahora no había tenido tiempo de investigar.
Como seguro os ocurre a muchos de vosotros, tengo un par de cuentas de Gmail (personal y profesional) y estoy habitualmente saltando de una a otra para gestionar los correos y calendarios. He intentado durante bastante tiempo usar herramientas de escritorio de Windows para gestionar el mail y la agenda de ambas cuentas, pero no he conseguido dar con ninguna que me convenciera del todo, así que he llegado a la conclusión de que realmente la mejor interfaz para Gmail o Google Calendar está en la web.
Pero por otro lado, no me gusta usarlas directamente desde el navegador, así que la opción de instalarlas como aplicaciones web progresivas (PWA) me parecía la mejor solución. Basta con acudir a la página que queremos instalar, por ejemplo https://mail.google.com, abrir el menú de Chrome, acceder a la opción "Enviar, guardar y compartir > Instalar página como aplicación..." y listo. Durante el proceso, incluso se nos pregunta si queremos anclar la aplicación a la barra de tareas, así que podremos tener muy a mano un acceso directo a la aplicación.
El problema es que, al instalarlas, se abren siempre con el usuario de Google que tengamos configurado como por defecto. En la práctica, la aplicación anclada se abrirá siempre con la misma cuenta, que es aquella con la que nos logamos primero en el navegador. Y esto es un problema si queremos tener acceso rápido a varias cuentas, como es el caso.
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.
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.
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 pregunta que me hacen con cierta frecuencia los alumnos de mi curso de ASP.NET Core en CampusMVP es que por qué, al ejecutar una aplicación de este tipo, Visual Studio les muestra un mensaje como el siguiente, no se lanza el navegador y no pueden acceder a la aplicación:
Generalmente la respuesta es bastante sencilla: Visual Studio nos está informando de que el servidor web no ha sido lanzado al ejecutar la aplicación.
Cuando en un bucle for necesitamos más de una variable de control, lo habitual es inicializarlas fuera del bucle y luego usarlas en su interior, por ejemplo, como en el siguiente código:
int j = 0;
for (int i = 0; i < 10 && j < 100; i++)
{
Console.WriteLine($"i = {i}, j = {j}");
j+= 10;
}
Blazor ha venido en ASP.NET Core 8 cargadito de novedades, aunque probablemente la más destacable sea la introducción de las Blazor Web Apps como modelo de proyecto que unifica los distintos modos de renderizado de componentes. Aunque se trata de un cambio positivo, la realidad es que ha complicado algunas cosas que antes, con unos modelos de proyecto más sencillos, eran más fáciles de implementar.
Un ejemplo claro lo tenemos en las páginas de error 404 (not found): con este nuevo modelo unificado no hay una fórmula trivial o integrada de serie en el framework para implementar esta funcionalidad, tan habitual en nuestras aplicaciones.
En este post vamos a ver un posible enfoque para conseguir que si un usuario introduce una ruta inexistente en el navegador o bien pulsa un enlace interno que no exista, podamos mostrarle una página de error 404 totalmente personalizada, implementada como componente Blazor, e integrada en nuestra Blazor Web App.
Este post pertenece a una serie de tres partes donde estamos viendo cómo renderizar componentes Blazor en el interior de vistas MVC de ASP.NET Core. Hasta ahora, hemos visto cómo renderizar desde vistas MVC componentes Blazor usando los siguientes modos de renderización:
En esta entrega final veremos cómo renderizar componentes Blazor ejecutados por completo en el lado cliente (WebAssembly).
Este post pertenece a una serie de tres partes donde estamos viendo cómo renderizar componentes Blazor en vistas MVC de ASP.NET Core.
En la primera parte de la serie vimos cómo renderizar componentes estáticos (SSR) en servidor, y ahora vamos a centrarnos en hacerlo con componentes con interactividad también en el lado servidor (Blazor Server), dejando para una siguiente entrega los componentes interactivos ejecutados por completo en cliente con WebAssembly.
Hace no demasiado, mientras analizábamos la posibilidad de que Blazor acabara en algún momento sustituyendo a MVC como tecnología "por defecto" para el desarrollo de aplicaciones web en .NET, comentaba que técnicamente no hay nada que impida a ambas tecnologías convivir pacíficamente en una misma aplicación. De hecho, están diseñadas para trabajar juntas :)
En este sentido, uno de los escenarios soportados es la inserción de componentes Blazor en el interior de vistas de una aplicación ASP.NET Core MVC. Esto puede ser muy interesante, entre otros casos, si queremos ir introduciendo Blazor progresivamente en aplicaciones MVC existentes o para reutilizar componentes entre distintos proyectos.
En esta miniserie vamos a ver cómo conseguirlo con los distintos modos de renderizado de Blazor, porque cada uno tiene sus particularidades:
- Renderizado estático (SSR), lo que veremos en este post.
- Renderizado en servidor (Blazor Server), en un futuro post.
- Renderizado en cliente (Blazor WebAssembly), también en un artículo posterior.
El espacio de nombres System.IO de .NET proporciona clases para trabajar con archivos y directorios, algo que, a priori, no tendría demasiado sentido en componentes Blazor WebAssembly, ya que éstos se ejecutan en el navegador del cliente y, por motivos de seguridad, no tienen acceso al sistema de archivos del servidor, ni tampoco a los archivos del dispositivo del usuario que está ejecutando la aplicación.
El primero de los casos es salvable: si desde un componente Blazor WebAssembly quisiéramos leer o escribir archivos en el servidor, podríamos hacerlo a través de una API que, ejecutada en el servidor, tuviera acceso a este tipo de recursos.
Sin embargo, técnicamente no hay forma de acceder a los archivos locales del usuario, dado que los componentes Blazor WebAssembly se ejecutan en el sandbox del navegador, que impide acceder a los recursos del sistema.
Pues bien, a pesar de ello, y de forma totalmente contraria a lo que podríamos intuir, desde Blazor WebAssembly sí que se pueden usar los componentes de System.IO (bueno, o muchos de ellos) para leer o escribir archivos y directorios, aunque con algunas peculiaridades que veremos a continuación.
Revisando código ajeno, me he encontrado con un ejemplo de uso del operador null coalescing assignment de C# que me ha parecido muy elegante y quería compartirlo con vosotros.
Como recordaréis, este operador, introducido en C# 8, es una fórmula muy concisa para asignar un valor a una variable si ésta previamente es null, una mezcla entre el operador de asignación y el null coalescing operator que disfrutamos desde C# 2:
// C# "clásico":
var x = GetSomething();
...
if(x == null) {
x = GetSomethingElse();
}
// Usando null coalescing operator (C# 2)
var x = GetSomething();
...
x = x ?? GetSomethingElse();
// Usando null coalescing assignment (C# 8)
var x = GetSomething();
...
x ??= GetSomethingElse();
Pero, además, al igual que otras asignaciones, este operador retorna el valor asignado, lo que nos permite encadenar asignaciones y realizar operaciones adicionales en la misma línea.
Por ejemplo, observad el siguiente código:
Console.WriteLine(y ??= "Hello, World!");
Aquí, básicamente lo que hacemos es asignar el valor "Hello, World!" a la variable si ésta contiene un nulo, y luego imprimirlo por consola. Y si no es nulo, simplemente se imprime su valor actual.
