De alguna forma, los desarrolladores somos como relojeros: construimos sistemas complejos utilizando piezas diminutas que van encajando armoniosamente unas con otras para formar una máquina que funciona como un todo y aporta valor a nuestros usuarios. Quizás por eso me ha llamado la atención un precioso y trabajado artículo interactivo de Bartosz Ciechanowski, al que he llegado a través de MicroSiervos, sobre cómo funcionan los relojes mecánicos.
Continuando con la serie "cómo funcionan las cosas", Mia Koring nos explica cómo funciona la compresión de texto usando el algoritmo de codificación Huffman, uno de los muchos que existen para que nuestros datos ocupen menos espacio.
También esta semana, Martin Fowler ha publicado una reflexión, que comparto totalmente, sobre cómo los LLMs tienen la capacidad de redefinir lo que entendemos como "programación". De la misma forma que el ensamblador nos alejó de los ceros y unos, o los lenguajes de alto nivel nos fueron aislando cada vez más de la máquina permitiéndonos jugar con abstracciones superiores, los LLMs son una capa de abstracción aún mayor, que incluso nos permite alejarnos de los detalles de implementación y centrarnos más en la lógica y el diseño de alto nivel... eso sí, a costa de la indeterminación. Un artículo muy interesante que no te puedes perder.
Por último, me ha alegrado leer en el post de David Ortinau que .NET 10 va a reducir la verbosidad del XAML usado en páginas y componentes MAUI, algo que siempre me ha parecido más farragoso de la cuenta... sobre todo cuando vienes de la web y usas sintaxis superconcisas como Razor.
El resto de contenidos interesantes recopilados la semana pasada, a continuación.
Por si te lo perdiste...
- Un ejemplo de uso elegante del operador "null coalescing assignment" de C#
José M. Aguilar - Extendiendo claims de usuarios en ASP.NET Core
José M. Aguilar
.NET
- Wire Up XUnit Logging for Crazy Integration Testing
Jeremy D. Miller - Legacy Code Survival Guide: Visual Basic and .NET in 2025
DeeDee Walsh - Task.WhenAll or Parallel.ForEach?
Fati Iseni - Day 11: Implementing a C# Mutation Operator for Genetic Algorithms
Chris Woodruff - Managing Secrets in .NET Applications with Azure Key Vault & Managed Identities
Sudhir Mangla - .NET 8.0.17 Upgrades, Forwarded Headers, and Unknown Proxy Issues
Khalid Abuhakmeh & Wesley Cabus - .NET Channels as a In-Memory Message Bus – Beware!
Derek Comartin
Estamos acostumbrados a usar el operador await de C# para esperar la finalización de tareas asíncronas representadas por objetos de tipo Task, Task<T>, ValueTask o ValueTask<T>, pero, ¿sabíais que en realidad podemos usarlo con cualquier tipo de objeto?.
En este artículo vamos a ver que es bastante sencillo, y lo ilustraremos con un ejemplo muy simple: cómo esperar un segundo usando la expresión await 1000 o await TimeSpan.FromSeconds(1) en lugar del clásico await Task.Delay(1000).
Una vez más, vamos con los contenidos interesantes recopilados durante la semana pasada 🙂
En esta ocasión, me vais a permitir a destacar un post propio que, aunque tiene más de un año de vida y es bastante básico, creo sigue siendo muy válido y puede ser de ayuda para algunos desarrolladores que siguen malgastando recursos. En "¡No uses ContainsKey() en un diccionario .NET para ver si existe un elemento antes de obtenerlo!" demostramos de forma empírica lo absurdo de realizar una comprobación de existencia de un elemento en un diccionario .NET antes de obtenerlo, un detalle en los que a veces no caemos.
También destacaremos algunos contenidos relacionados con MCP, que sin duda es la palabra de moda de los últimos tiempos. Primero, Aaron Stannard nos cuenta en qué consiste este estándar y para qué podamos usarlo en la práctica, eliminando el hype que le rodea.
Juan Luis Guerrero continúa explorando la implementación y uso de servidores MCP, esta vez usando como modelo Google Gemini 2.5.
Rhea Patel nos cuenta que el modo agente ya está disponible de forma general en Visual Studio.
Y el equipo de Visual Studio Code ha publicado un catálogo de servidores MCP listos para usar en el modo agente del editor, instalables con un único click.
El resto de enlaces, a continuación.
Por si te lo perdiste...
- ¡No uses ContainsKey() en un diccionario .NET para ver si existe un elemento antes de obtenerlo!
José M. Aguilar - Renderizar una vista Razor a un string en ASP.NET Core MVC
José M. Aguilar
.NET
- .NET 10 Performance Edition
Steven Giesel - Song recommendations from C# combinators
Mark Seemann - Getting started with Open Telemetry in .NET with Jaeger and Seq
Anton Martyniuk - 16 common mistakes C#/.NET developers make (and how to avoid them)
Ali Hamza Ansari - Temporal.IO in .NET
Marek Sirkovský - RunJS: An MCP server that lets LLMs generate and execute JavaScript safely in an embedded .NET runtime sandbox using the Jint library.
Charles Chen - 7 Underrated C# 12 and C# 13 Features Every Developer Should Know!
Saravanan Madheswaran - Kickstarting your libraries with the .NET Library Starter Kit Dennis Doomen
Dennis Doomen - How to use frozen collections in C#
Joydip Kanjilal - Unpacking Zip Folders into Windows Long File Paths
Rick Strahl
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.
Buena cosecha la semana pasada, con mucho contenido interesante 🙂
Destacamos el lanzamiento de la quinta preview de .NET 10, que esta vez incluye cambios en C#, ASP.NET Core, Blazor, .NET MAUI y otras áreas.
Rick Strahl nos enseña a añadir paquetes NuGet en tiempo de ejecución a una aplicación, algo que puede ser muy útil en sistemas con plugins o extensiones.
Vale la pena también echar un vistazo a Next Edit Suggestions, una nueva característica de GitHub Copilot para Visual Studio y Code que sugiere la siguiente edición en el código, lo que puede mejorar la productividad de los desarrolladores.
Shalitha Suranga comparte sus reflexiones sobre el declive de los blogs técnicos y cómo los desarrolladores somos los únicos que podemos hacer algo para que no desaparezcan.
Finalmente, Ricardo Peres nos presenta RazorSharpener, un componente que simplifica la compilación y renderización de componentes Razor en tiempo de ejecución.
Más contenidos interesantes, a continuación.
Por si te lo perdiste...
- Procesar secuencias por lotes, o cómo usar chunks en C#
José M. Aguilar - Autenticación JWT en APIs con ASP.NET Core
José M. Aguilar
.NET
- .NET 10 Preview 5
James Montemagno - Adding Runtime NuGet Package Loading to an Application
Rick Strahl - Don't reinvent the wheel
Josef Ottosson - Federated Identity in .NET: A Complete Guide for Software Architects
Sudhir Mangla - Converting a Microsoft XNA 3.1 game to MonoGame
Andrew Lock - How to Create and Convert PDF Documents in ASP.NET Core
Anton Martyniuk - Are Your LINQ Queries Slowing Down Your App? Here's How to Fix Them
Meena Alagiah - Repeating a test multiple times in C#
Bart Wullems - C# Tip: Handling exceptions with Task.WaitAll and Task.WhenAll
Davide Bellone - Queue-Based Load Leveling Pattern in C#: Cloud Stability, Scalability & Best Practices
Sudhir Mangla - Domain-Driven Design Principles: Value Objects in ASP.NET Core
Assis Zang - Run C# Scripts With dotnet run app.cs (No Project Files Needed)
Milan Jovanović
Desde la aparición de Blazor y sus distintos tipos de hosting de componentes (SSR, Server, WebAssembly), se intentó promover que estos fueran agnósticos respecto a su modo de ejecución. Sin embargo, en la práctica esto no es siempre posible, y en ocasiones necesitamos saber en qué modo se está ejecutando un componente para poder adaptarlo a las necesidades de la aplicación.
Hace más de un año, cuando aún Blazor 8 era la versión más reciente de este framework, vimos por aquí un truco para detectar si un componente Blazor estaba ejecutándose de forma estática (SSR) o interactiva. Y algunos años antes, ya habíamos visto también distintas formas para detectar si un componente interactivo estaba corriendo sobre Blazor Server o Blazor WebAssembly.
Aunque las soluciones propuestas funcionaban bien y solucionaban nuestro problema, eran simplemente trucos (o "hacks", algo retorcidos en algunos casos) para cubrir unas necesidades que no estaban bien resueltas desde el propio framework.
Con .NET 9 esto cambió, y desde esta versión de Blazor ya existen mecanismos nativos para detectar cuándo un componente se ejecuta en modo estático o interactivo, y en este último caso, qué modo de renderizado se está utilizando.
Vamos a ver cómo conseguirlo.
