Emiliano Montesdeoca

Blazor desde cero: Capítulo 3 — Componentes que escalan

Mon, 01 Jun 2026 00:00:00 +0000

Bienvenido al Capítulo 3 de Blazor desde cero. Si te perdiste el Capítulo 2, léelo primero para tener el proyecto base listo.

En el Capítulo 2 hicimos que la app corriera. En este capítulo haremos que sea mantenible.

Las apps Blazor se vuelven caóticas rápido cuando cada página termina como un .razor gigante. Los componentes son la forma de evitarlo: te dan consistencia, reutilización y límites claros entre piezas de UI.

Qué es realmente un componente en Blazor

Un componente es un archivo .razor que puede:

Renderizar marcado
Mantener estado local
Recibir datos por parámetros
Emitir eventos al componente padre
Renderizar contenido hijo

En runtime, Blazor trata cada componente como una pequeña máquina de estado. Cuando cambia el estado, vuelve a renderizar y aplica un diff del DOM.

Por eso tu objetivo es definir entradas limpias y comportamiento predecible.

Paso 1: Empieza con un componente enfocado

Crea Components/Common/SectionHeader.razor:

<header class="section-header">
 <h2>@Title</h2>
 @if (!string.IsNullOrWhiteSpace(Subtitle))
 {
 <p>@Subtitle</p>
 }
</header>

@code {
 [Parameter] public string Title { get; set; } = string.Empty;
 [Parameter] public string? Subtitle { get; set; }
}

Úsalo en Components/Pages/Home.razor:

@page "/"

<PageTitle>Blazor desde cero</PageTitle>

<SectionHeader
 Title="Blazor desde cero"
 Subtitle="El capítulo 3 trata sobre componentes." />

Es pequeño, pero introduce la idea más importante: un componente debería entenderse solo leyendo sus parámetros.

Paso 2: Usa parámetros para hacer explícito el comportamiento

Ahora, un botón reutilizable.

Components/Common/AppButton.razor:

<button class="app-button @VariantCssClass" @onclick="OnClick">
 @Text
</button>

@code {
 [Parameter] public string Text { get; set; } = "Button";
 [Parameter] public string Variant { get; set; } = "primary";
 [Parameter] public EventCallback OnClick { get; set; }

 private string VariantCssClass => Variant.ToLowerInvariant() switch
 {
 "secondary" => "app-button--secondary",
 "danger" => "app-button--danger",
 _ => "app-button--primary"
 };
}

Uso:

@code {
 private int _savedCount;

 private void Save()
 {
 _savedCount++;
 }
}

<AppButton Text="Save" Variant="primary" OnClick="Save" />
<p>Guardado @_savedCount veces.</p>

Lo importante aquí es el contrato:

Parámetros pocos y claros
Nombres explícitos en lugar de comportamiento mágico
Valores por defecto seguros

Paso 3: Usa `RenderFragment` para composición de layout

RenderFragment permite que el padre pase bloques de UI al hijo.

Crea Components/Common/Card.razor:

<article class="card">
 <header class="card__header">@Title</header>
 <section class="card__body">
 @ChildContent
 </section>
</article>

@code {
 [Parameter] public string Title { get; set; } = string.Empty;
 [Parameter] public RenderFragment? ChildContent { get; set; }
}

Uso:

<Card Title="Roadmap">
 <ul>
 <li>Componentes</li>
 <li>Data binding</li>
 <li>Routing</li>
 </ul>
</Card>

Este patrón ayuda a construir estructuras consistentes sin repetir el mismo markup contenedor en cada página.

Paso 4: Prefiere composición sobre páginas gigantes

Si una página crece demasiado, sepárala por responsabilidad:

ProfileSummary para el bloque principal
ProfileStats para métricas
ProfileActivityList para actividad reciente

La página principal queda como orquestación, no como detalle de implementación.

Paso 5: Equilibra markup y lógica

Para componentes simples, @code inline está bien.

Para componentes grandes, mueve lógica a code-behind:

UserCard.razor
UserCard.razor.cs

Así el markup queda legible y la lógica C# más fácil de navegar.

Paso 6: Estructura de carpetas práctica

Una estructura que escala bien:

Components/Pages/ -> páginas enrutable
Components/Layout/ -> shell y navegación
Components/Common/ -> bloques genéricos compartidos
Components/Features/<FeatureName>/ -> componentes por funcionalidad

Errores comunes al empezar con Blazor

Pasar demasiados parámetros en vez de usar un modelo dedicado
Poner reglas de negocio dentro de páginas
Crear un “componente dios” con cientos de líneas
Repetir patrones de markup en vez de extraer piezas reutilizables

Próxima entrega

En el Capítulo 4 veremos data binding y eventos: @bind, manejo de eventos, tradeoffs del two-way binding y patrones para mantener un estado predecible.

Blazor desde cero: Capítulo 2 — Tu primera app Blazor

Thu, 14 May 2026 00:00:00 +0000

Bienvenido al Capítulo 2 de Blazor desde cero. Si te perdiste el Capítulo 1, léelo primero para tener fresco el contexto de los modelos de renderizado.

En este capítulo vamos a crear una app Blazor nueva, ejecutarla en local y entender qué hace cada archivo importante.

Paso 1: Crear el proyecto

Desde tu terminal:

dotnet new blazor -o BlazorFromScratch
cd BlazorFromScratch

Esto crea una Blazor Web App de .NET 9 con la estructura por defecto.

Si tu herramienta te pide elegir un modelo de interactividad, empieza con Servidor interactivo. Es el modo más fácil para aprender porque todo se ejecuta en el servidor y la configuración es más directa.

Paso 2: Ejecutarla en local

Inicia la app:

dotnet watch

Luego abre la URL que aparece en la terminal (normalmente https://localhost:5xxx). Deberías ver la app por defecto con las páginas Home, Counter y Weather.

Si esto funciona, tu entorno está listo.

Paso 3: Entender la estructura del proyecto

Estos son los archivos y carpetas que debes conocer primero:

Program.cs — registra servicios y configura el pipeline HTTP.
Components/App.razor — componente raíz de la aplicación.
Components/Routes.razor — mapeo de rutas para las páginas.
Components/Pages/ — páginas enrutable como Home y Counter.
Components/Layout/ — layout compartido (MainLayout.razor, menú de navegación).
wwwroot/ — recursos estáticos (CSS, imágenes, favicon).
appsettings.json — valores de configuración.

No te preocupes por cada archivo todavía. En esta fase basta con entender dónde vive la UI y dónde se configura el arranque.

Paso 4: Haz tu primer cambio

Abre Components/Pages/Home.razor y reemplaza el contenido por:

@page "/"

<PageTitle>Blazor desde cero</PageTitle>

<h1>Blazor desde cero</h1>
<p>El Capítulo 2 está ejecutándose en local.</p>

Guarda el archivo y refresca el navegador. Con dotnet watch, la app debería actualizarse al momento.

Este cambio pequeño confirma el ciclo completo: editar -> compilar -> renderizar.

Paso 5: Leer Program.cs una vez

No hace falta memorizarlo, pero sí reconocer estas líneas clave:

AddRazorComponents() habilita los componentes Razor.
AddInteractiveServerComponents() habilita componentes interactivos del lado servidor.
MapRazorComponents<App>() mapea el componente raíz a endpoints.

Estas líneas te dicen cómo arranca la app y qué capacidades de renderizado están activas.

Problemas comunes

Si algo falla, normalmente es uno de estos casos:

SDK antiguo: ejecuta dotnet --version y asegúrate de usar .NET 9.
Advertencias del certificado HTTPS: ejecuta dotnet dev-certs https --trust.
Conflictos de puerto: detén procesos dotnet viejos y vuelve a ejecutar.

Próxima entrega

En el Capítulo 3 nos centraremos en componentes a fondo: parámetros, composición y cómo estructurar UI reutilizable sin convertir el proyecto en un caos.

Blazor desde cero: Capítulo 1 — ¿Qué es Blazor?

Fri, 08 May 2026 00:00:00 +0000

Bienvenido al Capítulo 1 de Blazor desde cero. Si te perdiste el post introductorio donde expliqué de qué va esta serie y a quién va dirigida, empieza por allí — es corto.

En este capítulo vamos a responder la pregunta fundamental: ¿qué es Blazor? Parece sencillo, pero la respuesta tiene varias capas, sobre todo porque “Blazor” ha llegado a significar cosas ligeramente distintas con el paso de los años. Al final de este post sabrás qué es Blazor, cómo encaja en el ecosistema .NET, cuáles son los distintos modelos de renderizado y por qué podrías elegirlo — o no — frente a un framework de JavaScript.

Un poco de historia

Blazor empezó como un proyecto experimental de Steve Sanderson en Microsoft alrededor de 2017. La idea era provocadora: ejecutar C# en el navegador usando WebAssembly, eliminando por completo la necesidad de JavaScript. Era una prueba de concepto, y el nombre fue una mezcla deliberada de Blazer y Razor — el motor de plantillas sobre el que Blazor acabaría construyéndose.

El experimento generó suficiente entusiasmo como para que Microsoft lo tomara en serio. Blazor llegó como parte de ASP.NET Core 3.0 en septiembre de 2019, primero como Blazor Server — un modelo que ejecuta tu código C# en el servidor y usa una conexión SignalR en tiempo real para enviar actualizaciones de la UI al navegador. Blazor WebAssembly llegó en mayo de 2020 como parte de ASP.NET Core 3.1, aportando ejecución verdaderamente del lado del cliente al framework.

.NET 6 y 7 refinaron la experiencia del desarrollador. Luego .NET 8, lanzado en noviembre de 2023, replanteó fundamentalmente el modelo de renderizado con lo que Microsoft llamó UI web full-stack. Renderizado estático del lado del servidor, streaming rendering, servidor interactivo, WebAssembly interactivo y un nuevo modo Auto convivían bajo el mismo techo en un único proyecto. .NET 9 construyó sobre esta base y pulió los bordes rugosos.

Ahí estamos hoy.

Qué es Blazor realmente

En esencia, Blazor es un framework de UI basado en componentes para .NET. Construyes tu interfaz a partir de componentes — piezas autocontenidas de C# y marcado HTML que pueden mantener estado, responder a eventos y componerse en estructuras más grandes. Si has trabajado con React o Vue, ese modelo mental te resultará familiar. La diferencia clave es que en lugar de JavaScript, escribes C#.

Los componentes en Blazor se escriben en archivos .razor. Un archivo .razor mezcla marcado HTML con código C# usando la sintaxis Razor que ya puedes conocer de las vistas de ASP.NET MVC. Así es como luce un componente simple:

@page "/counter"

<h1>Contador</h1>
<p>Cuenta actual: @currentCount</p>
<button @onclick="IncrementCount">Haz clic</button>

@code {
 private int currentCount = 0;

 private void IncrementCount()
 {
 currentCount++;
 }
}

No hay JavaScript a la vista. La directiva @onclick conecta el clic del botón con un método C#. La expresión @currentCount renderiza el valor actual. Cuando cambia el estado, Blazor determina qué actualizar en el DOM.

Ese es el núcleo. Todo lo demás — routing, inyección de dependencias, formularios, llamadas HTTP — se construye sobre este modelo de componentes.

Los modelos de renderizado

Aquí es donde vive mucha confusión, así que seamos precisos. “Blazor” hoy hace referencia a una familia de modos de renderizado, no a un único modelo de despliegue. Entender la diferencia importa porque afecta al rendimiento, los requisitos de infraestructura y lo que tus componentes pueden y no pueden hacer.

SSR estático

El modo más simple. Tus componentes Razor se renderizan en el servidor a HTML y ese HTML se envía al navegador. No hay conexión persistente, no hay WebAssembly y no hay interactividad del lado del cliente por defecto. Es esencialmente lo que hace Razor Pages, pero usando el modelo de componentes.

Úsalo para páginas con mucho contenido, landing pages, cualquier cosa que no necesite interactividad en tiempo real.

Servidor interactivo

Tu código de componente se ejecuta en el servidor. Se establece una conexión WebSocket SignalR entre el navegador y el servidor. Cuando haces clic en un botón o escribes en un input, el evento viaja por el WebSocket al servidor, tu C# se ejecuta, se calcula el diff y las actualizaciones del DOM se envían de vuelta al navegador.

Ventajas: Acceso completo a recursos del servidor (bases de datos, sistema de archivos, secretos). Carga inicial rápida. Tamaño de descarga pequeño. Funciona en navegadores sin soporte de WebAssembly.

Desventajas: Cada interacción del usuario requiere un viaje de ida y vuelta al servidor, lo que añade latencia. Los recursos del servidor escalan con el número de conexiones activas. La app se degrada si la conexión cae.

Úsalo para apps de negocio, herramientas internas, apps donde el acceso a datos del servidor importa más que la capacidad offline.

WebAssembly interactivo

El runtime de .NET se descarga al navegador y tu app se ejecuta completamente en el cliente. Tras la descarga inicial, la app funciona completamente offline y cada interacción es inmediata — sin viajes al servidor para la lógica de UI.

Ventajas: Ejecución verdaderamente del lado del cliente. Funciona offline. Carga del servidor reducida una vez cargada la app.

Desventajas: Descarga inicial mayor (el runtime de .NET + tu app). Primera carga más lenta. Necesitas una API para acceder a datos del servidor.

Úsalo para apps con capacidad offline, herramientas que necesitan capacidad de respuesta inmediata, escenarios donde el procesamiento del servidor no es necesario para la UI.

Modo Auto

Introducido en .NET 8. La app arranca en modo Servidor interactivo (carga inicial rápida, sin esperar que se descargue WebAssembly). Una vez que los archivos de WebAssembly se han descargado en segundo plano, las visitas posteriores cambian automáticamente al modo WebAssembly.

Esto te da la carga inicial rápida del modo Servidor y eventualmente la ejecución completa del lado del cliente de WebAssembly. Es el modelo más complejo de razonar, pero es un punto de partida práctico para muchas apps.

Mezclar modos en la misma app

En .NET 8 y posteriores, no estás limitado a un único modo de renderizado para toda la app. Una landing page puede ser SSR estático; el dashboard autenticado puede ser Servidor interactivo; un widget de visualización de datos puede ser WebAssembly interactivo. El framework gestiona las transiciones.

En esta serie empezaremos con Servidor interactivo porque es el más sencillo de poner en marcha y tiene el modelo mental más directo. Exploraremos los otros modos a medida que avancemos.

Cómo se compara Blazor con los frameworks de JavaScript

Si has construido con React, Angular o Vue, esta es probablemente la comparación que te interesa.

Las similitudes son reales. El modelo de componentes de Blazor es deliberadamente similar al de React. Tienes props (Parámetros en Blazor), estado local (campos en el bloque @code), hooks de ciclo de vida y el mismo patrón de comunicación de datos hacia abajo y eventos hacia arriba. Si conoces React, te sentirás como en casa en pocas horas.

La diferencia clave es el lenguaje. En Blazor escribes C#. Tu lógica de negocio, las reglas de validación y los modelos de datos se pueden compartir entre tu frontend Blazor y tu backend ASP.NET Core. No más duplicar una clase User en TypeScript cuando ya la tienes en C#.

La brecha del ecosistema es real pero se está reduciendo. El ecosistema npm es enorme. El ecosistema NuGet para componentes de UI es más pequeño, aunque ha crecido sustancialmente. Si necesitas una librería de gráficos específica o un widget de drag-and-drop, JavaScript todavía tiene más opciones. Pero para la mayoría de las aplicaciones de negocio, lo disponible en el mundo .NET es más que suficiente.

La interoperabilidad con JavaScript existe cuando la necesitas. Blazor te permite llamar a JavaScript desde C# y a C# desde JavaScript. Para APIs del navegador que todavía no tienen un wrapper .NET, o cuando quieres usar una librería JS existente, el interop está disponible. Añade una capa pero no es doloroso.

La respuesta honesta: si tu equipo son completamente desarrolladores JavaScript construyendo un producto público donde el SEO, el rendimiento y el ecosistema npm son críticos, quédate con JavaScript. Si tu equipo son desarrolladores .NET, si estás construyendo aplicaciones internas o de negocio, o si compartir código entre frontend y backend te importa, Blazor es una opción convincente.

Qué necesitas para seguir la serie

Para el resto de esta serie necesitarás:

.NET 9 SDK — descárgalo en dot.net
Un IDE — Visual Studio 2022 (la edición Community es gratuita), VS Code con la extensión C# Dev Kit, o JetBrains Rider
Comodidad básica con C# — clases, propiedades, interfaces, async/await

Eso es todo. Sin Node, sin npm, sin webpack.

Próxima entrega

En el Capítulo 2 montaremos tu primera app Blazor, recorreremos la estructura del proyecto y nos aseguraremos de que puedes ejecutarla en local. Al final tendrás una app funcionando y una imagen clara de qué hace cada archivo.

Nos vemos allí.

Blazor desde cero: una nueva serie

Mon, 04 May 2026 00:00:00 +0000

Llevo un tiempo escribiendo sobre Blazor — ciclos de vida de componentes, CSS aislado, modelos de interactividad, autenticación. Estos posts han sido útiles por sí solos, pero siempre he sentido que les falta base. Dan por hecho que ya sabes qué es Blazor, por qué existe y cómo encaja en el ecosistema .NET. No todo el mundo lo sabe, y está perfectamente bien.

Por eso empiezo algo nuevo: Blazor desde cero. Una serie en condiciones, construida desde los cimientos, pensada para desarrolladores que quieren entender de verdad lo que están construyendo — no solo copiar y pegar hasta que funcione.

A quién va dirigida esta serie

Esta serie es para ti si:

Eres desarrollador .NET, has oído hablar de Blazor pero nunca has tenido el momento ni el punto de partida adecuado para adentrarte.
Has probado Blazor, lo has hecho funcionar, pero tienes la sensación de que estás adivinando el por qué de las cosas.
Vienes del mundo JavaScript/React/Angular y quieres entender cómo es la apuesta de Microsoft para el frontend moderno.
Quieres un recurso único y coherente en lugar de documentación dispersa y posts sueltos.

No necesitas ser desarrollador senior. Sí necesitas sentirte cómodo con lo básico de C# — clases, interfaces, async/await. Si puedes escribir una API CRUD sencilla en ASP.NET Core, estás listo.

Qué vamos a ver

Aquí tienes un esquema aproximado de lo que tengo planificado. Algunos temas se expandirán en varios posts según sea necesario:

¿Qué es Blazor? — Modelos de alojamiento, historia, cómo se compara con el desarrollo web tradicional
Tu primera app Blazor — Scaffolding, estructura del proyecto, ejecución en local
Componentes — El bloque fundamental de cualquier interfaz en Blazor
Data binding y eventos — Cómo hacer que tu interfaz sea reactiva
Comunicación entre componentes — Parámetros, EventCallbacks, valores en cascada
Routing y navegación — Cómo gestiona Blazor las URLs y las transiciones de página
Inyección de dependencias — Servicios, scopes y el contenedor DI en Blazor
Formularios y validación — EditForm, DataAnnotations, validadores personalizados
HTTP y datos externos — Llamadas a APIs desde tu app Blazor
Autenticación y autorización — Cómo proteger tu app correctamente
Interop con JavaScript — Cuándo necesitas llegar al navegador
Rendimiento y optimización — Virtualización, lazy loading, estrategias de renderizado
Testing de componentes Blazor — bUnit y cómo es un buen test
Despliegue — Publicar en Azure, IIS y hosts estáticos

Esta lista irá evolucionando. Algunos temas se dividirán en varios posts; otros puede que se fusionen. Actualizaré este post conforme avance la serie e iré añadiendo enlaces a cada entrada según se publiquen.

Por qué una serie, por qué ahora

Blazor ha madurado mucho. Con .NET 8 y 9, el modelo de renderizado se renovó en profundidad — SSR estático, streaming rendering, Server interactivo, WebAssembly interactivo y el modo Auto conviven ahora bajo el mismo techo. Es un framework genuinamente interesante y capaz, pero el salto en complejidad hace que la experiencia inicial pueda ser desconcertante.

Quiero construir un recurso que te encuentre donde estás y te guíe por todo el camino de forma sistemática. No pretende reemplazar la documentación oficial — es buena y deberías leerla — sino ser un complemento que explique el por qué detrás del qué.

Cómo seguir la serie

Cada post de la serie será lo bastante autocontenido como para leerse por separado, pero también se apoyarán entre sí. Si empiezas desde cero, te recomiendo ir en orden. Si te unes para cubrir un hueco concreto, también está bien — enlazaré los posts previos necesarios cuando sea relevante.

El código de cada post estará disponible en GitHub. Iré compartiendo los enlaces a medida que avancemos.

Nos vemos en el siguiente.

Tipos de sindicatos de C#: los sindicatos discriminados finalmente están llegando

Wed, 01 Apr 2026 00:00:00 +0000

Si ha estado escribiendo C# durante un período de tiempo significativo, es muy probable que se haya topado con una pared al intentar modelar algo que puede ser “una de varias cosas”. Quizás necesitabas un método para devolver un valor de éxito o un error. Quizás estabas creando un sistema de pago que maneja tarjetas de crédito, transferencias bancarias y billeteras digitales, cada una con datos completamente diferentes. O tal vez simplemente miraste F# o Rust y pensaste: “¿Por qué no puedo tener eso en C#?”

La espera casi ha terminado. Los sindicatos discriminados están llegando a C#.

Esta ha sido una de las funciones lingüísticas más solicitadas durante años, con debates comunitarios que se remontan a 2017 y antes. El equipo de diseño del lenguaje C# ha estado trabajando en una propuesta que introduce una palabra clave union para definir jerarquías de tipos cerrados con coincidencia de patrones exhaustiva. En esta publicación, quiero explicarle qué son las uniones discriminadas, por qué son tan importantes, cómo las hemos falsificado hasta ahora y cómo se ve realmente la sintaxis propuesta, con ejemplos de código real para cada una.

Una nota rápida antes de profundizar: al momento de escribir este artículo, la función de tipos de unión aún se encuentra en la etapa de propuesta y vista previa. La sintaxis y el comportamiento que describo aquí se basan en los últimos documentos de diseño disponibles públicamente y debates del equipo de diseño del lenguaje C#. Las cosas pueden cambiar antes del lanzamiento final. Seré claro sobre lo que está confirmado y lo que aún está en discusión.

¿Qué son los sindicatos discriminados?

En esencia, una unión discriminada (a veces denominada “unión etiquetada” o “tipo de suma”) es un tipo que puede contener uno de un conjunto fijo de valores posibles, donde cada variante puede contener datos diferentes. La parte “discriminada” significa que el tiempo de ejecución siempre sabe qué variante es; hay una etiqueta que la identifica.

Piense en ello como un enum, pero donde cada miembro puede llevar su propia carga de datos.

Si has usado otros lenguajes, probablemente hayas visto este concepto antes:

F# ha tenido sindicatos discriminados desde el primer día:

type Shape =
 | Circle of radius: float
 | Rectangle of width: float * height: float
 | Triangle of base: float * height: float

Rust usa enum para la misma idea:

enum Shape {
 Circle { radius: f64 },
 Rectangle { width: f64, height: f64 },
 Triangle { base: f64, height: f64 },
}

TypeScript logra algo similar con uniones etiquetadas:

type Shape =
 | { kind: "circle"; radius: number }
 | { kind: "rectangle"; width: number; height: number }
 | { kind: "triangle"; base: number; height: number };

En todos estos casos, el compilador conoce todas las variantes posibles y puede exigir que usted las maneje todas. Ése es el superpoder: comprobación exhaustiva. Si agrega una nueva variante, el compilador le indica dónde olvidó manejarla.

C# nunca ha tenido una forma excelente de expresar esto. Hasta ahora.

Cómo simulamos los sindicatos hoy

A lo largo de los años, la comunidad C# ha ideado varias soluciones, cada una con sus propias compensaciones. Permítanme repasar los enfoques más comunes.

Registros abstractos con herencia

La solución más idiomática en C# moderno es usar registros abstractos con tipos derivados sellados:

public abstract record Shape
{
 public sealed record Circle(double Radius) : Shape;
 public sealed record Rectangle(double Width, double Height) : Shape;
 public sealed record Triangle(double Base, double Height) : Shape;

 private Shape() { } // Prevent external inheritance
}

Esto funciona razonablemente bien. Obtienes inmutabilidad, igualdad de valores y puedes usar la coincidencia de patrones:

double Area(Shape shape) => shape switch
{
 Shape.Circle c => Math.PI * c.Radius * c.Radius,
 Shape.Rectangle r => r.Width * r.Height,
 Shape.Triangle t => 0.5 * t.Base * t.Height,
 _ => throw new InvalidOperationException("Unknown shape")
};
```Pero existen importantes inconvenientes. El compilador no sabe que la jerarquía está cerrada, por lo que siempre necesita ese `_` descartar el brazo o recibirá una advertencia. Si agrega una nueva variante, el compilador no le informará sobre todos los lugares donde olvidó manejarla: el descarte la traga silenciosamente. Eso anula completamente el propósito.

### La biblioteca OneOf

Otro enfoque popular es el paquete NuGet [OneOf](https://github.com/mcintyre321/OneOf):

```csharp
public OneOf<Success<Order>, NotFound, ValidationError> ProcessOrder(OrderRequest request)
{
 // ...
}

// Usage
var result = ProcessOrder(request);
result.Switch(
 success => Console.WriteLine($"Order {success.Value.Id} processed"),
 notFound => Console.WriteLine("Order not found"),
 error => Console.WriteLine($"Validation failed: {error.Message}")
);

OneOf proporciona una verificación exhaustiva en tiempo de compilación a través de sus parámetros de tipo genérico, lo cual es excelente. Pero se basa en la coincidencia posicional (primer tipo, segundo tipo, etc.), las firmas genéricas se vuelven difíciles de manejar con rapidez y no se integra con la coincidencia de patrones del lenguaje. Es un truco inteligente, pero sigue siendo un truco.

Enumeración manual + patrón de datos

Algunos desarrolladores siguen la ruta clásica con una etiqueta enum y un contenedor de datos:

public enum PaymentType { CreditCard, BankTransfer, DigitalWallet }

public class Payment
{
 public PaymentType Type { get; init; }
 public CreditCardInfo? CreditCard { get; init; }
 public BankTransferInfo? BankTransfer { get; init; }
 public DigitalWalletInfo? DigitalWallet { get; init; }
}

Esto es frágil. Nada le impide configurar Type en CreditCard pero completar la propiedad BankTransfer. El compilador no puede ayudarle y terminará con errores de tiempo de ejecución y comprobaciones nulas en todas partes. Es el enfoque “tipado en cadena” para el modelado de tipos, y no escala.

Todos estos enfoques comparten un problema fundamental: están luchando contra el lenguaje en lugar de trabajar con él. El compilador no puede razonar sobre el conjunto cerrado de posibilidades, por lo que se pierde la propiedad más valiosa de las uniones discriminadas: la verificación exhaustiva.

La propuesta de C#: la palabra clave `union`

La propuesta del equipo de lenguaje C# introduce una palabra clave union dedicada que define un conjunto cerrado de miembros con nombre, cada uno de los cuales transporta datos opcionalmente. Aquí está la sintaxis básica tal como se ha propuesto:

union Shape
{
 Circle(double Radius),
 Rectangle(double Width, double Height),
 Triangle(double Base, double Height)
}

Eso es todo. Limpio, conciso y de lectura inmediata. Cada miembro dentro de la unión define una variante distinta con sus propios datos. El compilador sabe que Shape solo puede ser una de estas tres cosas.

Debajo del capó, el compilador genera una jerarquía de tipos sellada, similar a la que escribirías a mano con registros abstractos, pero con pleno conocimiento del compilador de la naturaleza cerrada del tipo. Esto significa que el compilador puede imponer exhaustividad en la coincidencia de patrones, que es el beneficio clave.

Miembros de valor exclusivo

Los miembros del sindicato no tienen que llevar datos. Puede mezclar miembros que transportan datos con miembros de valor simple:

union Option<T>
{
 Some(T Value),
 None
}

Este es el tipo clásico Option/Maybe que los programadores funcionales han estado pidiendo en C# durante años. None no contiene datos, es solo una etiqueta.

Uniones genéricas

Como puede ver en el ejemplo Option<T> anterior, los sindicatos admiten genéricos. Aquí hay un ejemplo más complicado:

union Result<T, E>
{
 Ok(T Value),
 Error(E Err)
}

Esto abre todo un estilo de manejo de errores que no depende de excepciones para casos de falla esperados, algo que ha sido una práctica estándar en Rust y los lenguajes funcionales durante años.

Uniones con métodos

La propuesta también permite que las uniones tengan métodos, propiedades calculadas e implementen interfaces, como cualquier otro tipo:```csharp union Shape { Circle(double Radius), Rectangle(double Width, double Height), Triangle(double Base, double Height);

public double Area => this switch
{
Circle(var r) => Math.PI * r * r,
Rectangle(var w, var h) => w * h,
Triangle(var b, var h) => 0.5 * b * h
};
public double Perimeter => this switch
{
Circle(var r) => 2 * Math.PI * r,
Rectangle(var w, var h) => 2 * (w + h),
Triangle(var b, var h) => b + h + Math.Sqrt(b * b + h * h)
};

}


Observe cómo la expresión `switch` dentro de `Area` y `Perimeter` no necesita un brazo predeterminado. El compilador sabe que la unión es exhaustiva: sólo hay tres variantes y se manejan las tres. Si agrega una cuarta variante más adelante, el compilador marcará cada `switch` que no la maneje.

## Integración de coincidencia de patrones

La coincidencia de patrones ha estado evolucionando en C# desde la versión 7.0 y los tipos de unión están diseñados para ser ciudadanos de primera clase de ese sistema.

### Expresiones de cambio exhaustivas

La característica más impactante es la verificación exhaustiva de los interruptores. Con las uniones, el compilador **conoce** todos los casos posibles:

```csharp
string Describe(Shape shape) => shape switch
{
 Circle(var r) => $"A circle with radius {r}",
 Rectangle(var w, var h) => $"A {w}x{h} rectangle",
 Triangle(var b, var h) => $"A triangle with base {b} and height {h}"
};

Sin brazo de descarte. Sin _ => throw new NotImplementedException(). Si olvida un caso, el compilador emite un error, no una advertencia. Se trata de una mejora fundamental en materia de seguridad.

Coincidencia de patrones anidados

Las uniones se componen naturalmente con patrones anidados:

union Expr
{
 Literal(double Value),
 Add(Expr Left, Expr Right),
 Multiply(Expr Left, Expr Right),
 Negate(Expr Inner)
}

double Evaluate(Expr expr) => expr switch
{
 Literal(var v) => v,
 Add(var left, var right) => Evaluate(left) + Evaluate(right),
 Multiply(var left, var right) => Evaluate(left) * Evaluate(right),
 Negate(var inner) => -Evaluate(inner)
};

Este tipo de estructura de datos recursiva es extremadamente común en compiladores, intérpretes, motores de reglas y modelos matemáticos. Hoy en C# necesitarías una jerarquía de clases profunda y el patrón de visitante. Con los sindicatos, el código es muchísimo más sencillo.

Cláusulas de protección

La coincidencia de patrones con uniones admite when guardias tal como era de esperar:

string Classify(Shape shape) => shape switch
{
 Circle(var r) when r > 100 => "Large circle",
 Circle(var r) when r > 10 => "Medium circle",
 Circle(_) => "Small circle",
 Rectangle(var w, var h) when w == h => "Square",
 Rectangle _ => "Rectangle",
 Triangle _ => "Triangle"
};

Ejemplos prácticos

Permítanme analizar algunos escenarios del mundo real donde los tipos de unión mejoran drásticamente el código.

El patrón de resultados: reemplazar excepciones por errores esperados

Uno de los patrones más comunes en el desarrollo de aplicaciones modernas es representar operaciones que pueden tener éxito o fallar sin utilizar excepciones para el flujo de control. Las excepciones deben ser excepcionales: cosas como fallas de red o condiciones de falta de memoria. Un error de validación o un resultado “no encontrado” es un resultado esperado, no una excepción.

union Result<T, E>
{
 Ok(T Value),
 Error(E Err)
}

union OrderError
{
 NotFound(Guid OrderId),
 InsufficientStock(string ProductId, int Requested, int Available),
 PaymentDeclined(string Reason),
 ValidationFailed(IReadOnlyList<string> Errors)
}

Result<Order, OrderError> ProcessOrder(OrderRequest request)
{
 if (!Validate(request, out var errors))
 return new ValidationFailed(errors);

 var product = catalog.Find(request.ProductId);
 if (product is null)
 return new NotFound(request.OrderId);

 if (product.Stock < request.Quantity)
 return new InsufficientStock(request.ProductId, request.Quantity, product.Stock);

 var paymentResult = paymentGateway.Charge(request.Payment);
 if (!paymentResult.Success)
 return new PaymentDeclined(paymentResult.Message);

 var order = CreateOrder(request, product);
 return new Ok(order);
}

Luego, la persona que llama se ve obligada a manejar todos los resultados posibles:

var result = ProcessOrder(request);

var response = result switch
{
 Ok(var order) => Results.Created($"/orders/{order.Id}", order),
 Error(NotFound(var id)) => Results.NotFound($"Order {id} not found"),
 Error(InsufficientStock(var pid, var req, var avail)) =>
 Results.Conflict($"Product {pid}: requested {req}, only {avail} available"),
 Error(PaymentDeclined(var reason)) =>
 Results.UnprocessableEntity($"Payment declined: {reason}"),
 Error(ValidationFailed(var errors)) =>
 Results.BadRequest(new { Errors = errors })
};

Sin bloques try-catch, sin tipos de excepción olvidados, sin sorpresas en tiempo de ejecución. Cada modo de falla es visible en la firma de tipo y el compilador lo aplica. Esta es una mejora enorme para la confiabilidad de la API.

Modelado de dominio: tipos de pago

A continuación se muestra un ejemplo de modelado de dominio del mundo real: manejo de diferentes métodos de pago en un sistema de comercio electrónico:

union PaymentMethod
{
 CreditCard(string CardNumber, string Expiry, string Cvv),
 BankTransfer(string Iban, string Bic),
 DigitalWallet(string Provider, string Token),
 CashOnDelivery
}

decimal CalculateProcessingFee(PaymentMethod method, decimal amount) => method switch
{
 CreditCard _ => amount * 0.029m + 0.30m,
 BankTransfer _ => 1.50m,
 DigitalWallet(provider: "PayPal", _) => amount * 0.034m + 0.35m,
 DigitalWallet _ => amount * 0.025m,
 CashOnDelivery => 4.99m
};

string FormatForReceipt(PaymentMethod method) => method switch
{
 CreditCard(var num, _, _) => $"Credit Card ending in {num[^4..]}",
 BankTransfer(var iban, _) => $"Bank Transfer ({iban[..4]}****)",
 DigitalWallet(var provider, _) => $"Digital Wallet ({provider})",
 CashOnDelivery => "Cash on Delivery"
};

Compare esto con el enfoque actual donde tendría una interfaz o clase abstracta con cinco implementaciones diferentes distribuidas en cinco archivos, posiblemente con un patrón de visitante en la parte superior. El enfoque de unión mantiene la definición de datos y las operaciones juntas, legibles y verificadas exhaustivamente.

Máquinas de estados

Las máquinas de estado están en todas partes del software: procesamiento de pedidos, motores de flujo de trabajo, gestión de conexiones, estado de la interfaz de usuario. Los sindicatos los hacen explícitos y seguros:

union ConnectionState
{
 Disconnected,
 Connecting(string Host, int Port, DateTime StartedAt),
 Connected(string Host, int Port, TcpClient Client),
 Reconnecting(string Host, int Port, int Attempt, TimeSpan Delay),
 Failed(string Host, Exception Error)
}

ConnectionState HandleEvent(ConnectionState state, ConnectionEvent evt) => (state, evt) switch
{
 (Disconnected, Connect(var host, var port)) =>
 new Connecting(host, port, DateTime.UtcNow),

 (Connecting(var h, var p, _), ConnectionSucceeded(var client)) =>
 new Connected(h, p, client),

 (Connecting(var h, var p, _), ConnectionFailed(var ex)) =>
 new Reconnecting(h, p, Attempt: 1, Delay: TimeSpan.FromSeconds(1)),

 (Reconnecting(var h, var p, var attempt, _), ConnectionSucceeded(var client)) =>
 new Connected(h, p, client),

 (Reconnecting(var h, var p, var attempt, _), ConnectionFailed(var ex)) when attempt >= 5 =>
 new Failed(h, ex),

 (Reconnecting(var h, var p, var attempt, _), ConnectionFailed(_)) =>
 new Reconnecting(h, p, attempt + 1, TimeSpan.FromSeconds(Math.Pow(2, attempt))),

 (Connected(_, _, var client), Disconnect) =>
 new Disconnected,

 _ => state // Ignore events that don't apply to current state
};

Cada estado lleva exactamente los datos relevantes para ese estado. No puedes acceder accidentalmente a un TcpClient cuando estás en el estado Connecting porque no existe en esa variante. El sistema de tipos impone las invariantes de la máquina de estados.

Consideraciones de serialización e interoperabilidadUna de las preguntas prácticas que surge inmediatamente con los tipos de sindicatos es: ¿cómo se serializan? Si está creando API o almacenando datos, necesita la serialización JSON para funcionar correctamente.

El equipo de diseño ha estado analizando la compatibilidad integrada con System.Text.Json para tipos de unión. El enfoque esperado implica serializar con una propiedad discriminadora:

{
 "$type": "Circle",
 "radius": 5.0
}

{
 "$type": "Rectangle",
 "width": 10.0,
 "height": 20.0
}

Esto es consistente con el soporte de serialización polimórfica existente introducido en .NET 7 con atributos JsonDerivedType. La expectativa es que los sindicatos funcionen con System.Text.Json listo para usar, usando el nombre de la variante como discriminador de tipo de forma predeterminada.

Para Entity Framework Core, el enfoque probable es almacenar valores de unión utilizando una columna discriminadora, similar a cómo ya funciona el mapeo de herencia de tabla por jerarquía (TPH). La integración exacta de EF Core aún se está diseñando, pero ya existe la infraestructura para manejar jerarquías de tipos cerrados.

Vale la pena señalar que la interoperabilidad con otros lenguajes .NET debería ser fluida, ya que las uniones se compilarán en jerarquías de clases IL estándar bajo el capó. El código de F# que consume una unión de C# lo vería como una jerarquía de tipos estándar y viceversa.

Cómo probarlo

Al momento de escribir este artículo, los tipos de unión están disponibles como una característica de vista previa en las últimas vistas previas del SDK de .NET. Para experimentar con la sintaxis propuesta, necesitará:

Instale el SDK de vista previa de .NET más reciente
Habilite la versión de idioma de vista previa en su archivo de proyecto:

<Project Sdk="Microsoft.NET.Sdk">
 <PropertyGroup>
 <TargetFramework>net10.0</TargetFramework>
 <LangVersion>preview</LangVersion>
 </PropertyGroup>
</Project>

Tenga en cuenta que las funciones de vista previa están sujetas a cambios. La sintaxis, el comportamiento y los diagnósticos del compilador pueden evolucionar significativamente antes del lanzamiento final. No envíe código de producción basándose en funciones de lenguaje de vista previa, pero experimente con ellas y brinde comentarios. El equipo de C# monitorea activamente las discusiones del repositorio csharplang.

Si desea seguir el progreso de la propuesta, los lugares clave a seguir son:

El repositorio dotnet/csharplang para debates sobre diseño de lenguajes.
El repositorio dotnet/roslyn para el progreso de la implementación del compilador
El blog .NET para anuncios oficiales.

Comparación con enfoques existentes

Permítanme hacer una comparación rápida para que puedan ver cómo se comparan los diferentes enfoques:

Característica	Registros abstractos	UnoDe<T1,T2>	Enumeración + Datos	Tipos de unión
Control de exhaustividad	❌ No	✅ Sí	❌ No	✅ Sí
Coincidencia de patrones	✅ Sí	❌ Limitado	❌Manual	✅ Nativo
Cierre impuesto por el compilador	❌ No	✅ Sí	❌ No	✅ Sí
Datos por variante	✅ Sí	✅ Sí	⚠️ Frágil	✅ Sí
Legibilidad	⚠️ Detallado	⚠️ Posicional	❌ Pobre	✅ Excelente
Serialización	✅Manuales	⚠️ Complejo	✅Manuales	✅ Incorporado
Repetitivo	⚠️ Moderado	✅ Bajo	⚠️ Alto	✅ Mínimo
Sin dependencia externa	✅ Sí	❌ NuGet	✅ Sí	✅ Sí

Qué significa esto para el ecosistema .NET

La introducción de uniones discriminadas se extenderá por todo el ecosistema .NET. Esto es lo que espero ver:

El diseño de la biblioteca mejorará. Las API que actualmente devuelven null para indicar “no encontrado” o arrojan excepciones por fallas de validación podrán devolver tipos Result<T, E> en su lugar. Esto hace que los modos de falla sean explícitos en la firma de tipo: puede ver qué puede salir mal mirando la firma del método, no leyendo la documentación o el código fuente.

El modelado de dominio se vuelve más expresivo. La brecha entre el dominio del problema y la representación del código se reduce dramáticamente. Cuando su experto en el dominio dice “un pago puede ser una tarjeta de crédito, una transferencia bancaria o contra reembolso”, puede modelarlo directamente como una unión en lugar de traducirlo a una jerarquía de herencia.

Las ideas de F# se vuelven accesibles para los desarrolladores de C#. Muchos desarrolladores de C# han admirado el sistema de tipos de F# desde la distancia, pero no han podido adoptar F# en sus organizaciones. Los tipos de unión aportan una de las características más poderosas de F# a C#, lo cual es una ventaja para todo el ecosistema .NET.

Menos errores de tiempo de ejecución. La comprobación exhaustiva por sí sola evitará categorías enteras de errores. Cada vez que agrega una nueva variante a una unión, el compilador lo guiará a cada lugar del código base que necesite actualización. No más casos switch olvidados, no más NotImplementedException en ramas predeterminadas que solo aparecen en producción.

Conclusión

Los sindicatos discriminados han estado en lo más alto de la lista de deseos de la comunidad de C# durante casi una década, y con razón. Resuelven una brecha fundamental en el sistema de tipos: la capacidad de modelar datos que pueden ser “una de varias cosas” con seguridad impuesta por el compilador.

La palabra clave union propuesta brinda una sintaxis limpia y concisa que se integra profundamente con la coincidencia de patrones de C#, funciona con genéricos, admite métodos e interfaces y permite una verificación exhaustiva que detecta errores en tiempo de compilación en lugar de en tiempo de ejecución.

Ya sea que esté creando modelos de dominio, diseñando API con tipos de error explícitos, implementando máquinas de estado o simplemente tratando de reemplazar jerarquías de herencia incómodas con algo más natural, los tipos de unión cambiarán la forma en que escribe C#.

Hemos estado esperando esto durante mucho tiempo. La sintaxis es elegante, la integración con las características del lenguaje existente es cuidadosa y el impacto práctico se sentirá en todo el ecosistema .NET.

Esté atento a las versiones preliminares, experimente con la función y proporcione comentarios al equipo de diseño del lenguaje. Esta es una de esas funciones que, una vez que la hayas usado, te preguntarás cómo pudiste vivir sin ella.

Construyendo un sistema RAG en C# con Semantic Kernel

Wed, 18 Mar 2026 00:00:00 +0000

Introducción

Si ha intentado utilizar un LLM para responder preguntas sobre sus propios datos (documentos de la empresa, especificaciones de productos, bases de conocimiento internas) probablemente haya notado que alucina o simplemente dice “No tengo información sobre eso”. Esto se debe a que el modelo sólo sabe en qué fue entrenado.

RAG (Generación aumentada de recuperación) soluciona este problema. En lugar de ajustar un modelo a partir de sus datos, recupera fragmentos relevantes de sus documentos en el momento de la consulta y los pasa al LLM como contexto. Luego, el modelo genera respuestas basadas en sus datos reales.

En esta publicación, lo guiaré en la construcción de una canalización RAG completa en C# usando Semantic Kernel.

Cómo funciona RAG

El flujo es sencillo:

Ingesta: divida sus documentos en fragmentos, genere incrustaciones para cada fragmento y guárdelos en una base de datos vectorial.
Consulta: cuando un usuario hace una pregunta, genera una incrustación para la consulta, busca fragmentos similares en la base de datos de vectores.
Generar: pasar los fragmentos recuperados como contexto al LLM junto con la pregunta del usuario.

Eso es todo. La magia está en las incrustaciones: capturan el significado semántico del texto como vectores, por lo que puedes encontrar contenido relevante incluso cuando las palabras exactas no coinciden.

Requisitos previos

dotnet add package Microsoft.SemanticKernel
dotnet add package Microsoft.SemanticKernel.Connectors.AzureOpenAI
dotnet add package Microsoft.Extensions.VectorData.Abstractions
dotnet add package Microsoft.SemanticKernel.Connectors.InMemory

Para producción, cambiaría el almacén en memoria por Azure AI Search, Qdrant, Pinecone o cualquier otra base de datos vectorial compatible. Pero la memoria es perfecta para aprender y crear prototipos.

Configurando el kernel

using Microsoft.SemanticKernel;
using Microsoft.SemanticKernel.Connectors.AzureOpenAI;
using Microsoft.Extensions.VectorData;
using Microsoft.SemanticKernel.Connectors.InMemory;
using Microsoft.SemanticKernel.Embeddings;

var builder = Kernel.CreateBuilder();

builder.AddAzureOpenAIChatCompletion(
 deploymentName: "gpt-4o",
 endpoint: config["AzureOpenAI:Endpoint"],
 apiKey: config["AzureOpenAI:ApiKey"]);

builder.AddAzureOpenAITextEmbeddingGeneration(
 deploymentName: "text-embedding-3-small",
 endpoint: config["AzureOpenAI:Endpoint"],
 apiKey: config["AzureOpenAI:ApiKey"]);

var kernel = builder.Build();

Necesitamos dos modelos: uno para completar el chat (responder preguntas) y otro para generar incrustaciones (convertir texto en vectores).

Definiendo el modelo de datos

Necesitamos una clase para representar nuestros fragmentos de documentos en el almacén de vectores:

using Microsoft.Extensions.VectorData;

public class DocumentChunk
{
 [VectorStoreRecordKey]
 public string Id { get; set; } = Guid.NewGuid().ToString();

 [VectorStoreRecordData]
 public string Content { get; set; } = string.Empty;

 [VectorStoreRecordData]
 public string Source { get; set; } = string.Empty;

 [VectorStoreRecordData]
 public int ChunkIndex { get; set; }

 [VectorStoreRecordVector(1536)]
 public ReadOnlyMemory<float> Embedding { get; set; }
}

El atributo VectorStoreRecordVector(1536) le dice al almacén de vectores la dimensión de nuestras incrustaciones. El modelo text-embedding-3-small produce vectores de 1536 dimensiones.

Dividir documentos

Antes de que podamos crear incrustaciones, debemos dividir nuestros documentos en partes manejables. Aquí hay un divisor de texto simple:

public static class TextChunker
{
 public static List<string> SplitText(string text, int maxChunkSize = 500, int overlap = 50)
 {
 var chunks = new List<string>();
 var paragraphs = text.Split("\n\n", StringSplitOptions.RemoveEmptyEntries);
 var currentChunk = new System.Text.StringBuilder();

 foreach (var paragraph in paragraphs)
 {
 if (currentChunk.Length + paragraph.Length > maxChunkSize && currentChunk.Length > 0)
 {
 chunks.Add(currentChunk.ToString().Trim());

 // Keep overlap from the end of the previous chunk
 var overlapText = currentChunk.ToString();
 currentChunk.Clear();
 if (overlapText.Length > overlap)
 {
 currentChunk.Append(overlapText[^overlap..]);
 currentChunk.Append(' ');
 }
 }

 currentChunk.Append(paragraph);
 currentChunk.Append("\n\n");
 }

 if (currentChunk.Length > 0)
 {
 chunks.Add(currentChunk.ToString().Trim());
 }

 return chunks;
 }
}

La superposición es importante: garantiza que no se pierda el contexto en el límite entre fragmentos. Si una oración relevante se divide en dos partes, la superposición significa que aparecerá completamente en al menos una de ellas.

Ingesta de documentos

Ahora juntemos todo para incorporar documentos a nuestro almacén de vectores:

var vectorStore = new InMemoryVectorStore();
var collection = vectorStore.GetCollection<string, DocumentChunk>("documents");
await collection.CreateCollectionIfNotExistsAsync();

var embeddingService = kernel.GetRequiredService<ITextEmbeddingGenerationService>();

async Task IngestDocument(string content, string source)
{
 var chunks = TextChunker.SplitText(content);

 for (int i = 0; i < chunks.Count; i++)
 {
 var embedding = await embeddingService.GenerateEmbeddingAsync(chunks[i]);

 var chunk = new DocumentChunk
 {
 Content = chunks[i],
 Source = source,
 ChunkIndex = i,
 Embedding = embedding
 };

 await collection.UpsertAsync(chunk);
 }

 Console.WriteLine($"✅ Ingested {chunks.Count} chunks from {source}");
}

// Ingest some documents
var doc1 = await File.ReadAllTextAsync("docs/product-guide.md");
var doc2 = await File.ReadAllTextAsync("docs/faq.md");
var doc3 = await File.ReadAllTextAsync("docs/troubleshooting.md");

await IngestDocument(doc1, "product-guide.md");
await IngestDocument(doc2, "faq.md");
await IngestDocument(doc3, "troubleshooting.md");

Buscando fragmentos relevantes

Cuando un usuario hace una pregunta, generamos una inserción para su consulta y buscamos fragmentos similares:

async Task<List<DocumentChunk>> SearchAsync(string query, int topK = 3)
{
 var queryEmbedding = await embeddingService.GenerateEmbeddingAsync(query);

 var searchResults = await collection.VectorizedSearchAsync(
 queryEmbedding,
 new VectorSearchOptions { Top = topK });

 var results = new List<DocumentChunk>();
 await foreach (var result in searchResults.Results)
 {
 results.Add(result.Record);
 }

 return results;
}

Generando respuestas con contexto

Ahora la parte RAG: tomamos los fragmentos recuperados y los incluimos como contexto en nuestro mensaje:

using Microsoft.SemanticKernel.ChatCompletion;

var chatService = kernel.GetRequiredService<IChatCompletionService>();

async Task<string> AskAsync(string question)
{
 // Step 1: Retrieve relevant chunks
 var relevantChunks = await SearchAsync(question);

 // Step 2: Build context from chunks
 var context = string.Join("\n\n---\n\n",
 relevantChunks.Select(c => $"[Source: {c.Source}]\n{c.Content}"));

 // Step 3: Generate answer with context
 var history = new ChatHistory();
 history.AddSystemMessage($$"""
 You are a helpful assistant that answers questions based on the provided context.
 Use ONLY the information from the context to answer. If the context doesn't contain
 enough information to answer the question, say "I don't have enough information
 to answer that question."

 Do not make up information. Always cite the source document when possible.

 Context:
 {{context}}
 """);

 history.AddUserMessage(question);

 var response = await chatService.GetChatMessageContentAsync(history);
 return response.Content ?? "No response generated.";
}

Utilizándolo

// Ask questions about your documents
var answer1 = await AskAsync("How do I reset my password?");
Console.WriteLine($"Q: How do I reset my password?\nA: {answer1}\n");

var answer2 = await AskAsync("What are the system requirements?");
Console.WriteLine($"Q: What are the system requirements?\nA: {answer2}\n");

var answer3 = await AskAsync("What's the capital of France?");
Console.WriteLine($"Q: What's the capital of France?\nA: {answer3}\n");
// Should respond with "I don't have enough information" since it's not in the docs

Pasando a producción

El almacén de vectores en memoria es excelente para la creación de prototipos, pero para la producción querrás una base de datos de vectores persistente. Semantic Kernel tiene conectores para varias opciones:

# Azure AI Search
dotnet add package Microsoft.SemanticKernel.Connectors.AzureAISearch

# Qdrant
dotnet add package Microsoft.SemanticKernel.Connectors.Qdrant

# Redis
dotnet add package Microsoft.SemanticKernel.Connectors.Redis

El intercambio es sencillo ya que todos implementan la misma interfaz IVectorStore:

// Instead of InMemoryVectorStore, use:
using Azure;
using Microsoft.SemanticKernel.Connectors.AzureAISearch;

var vectorStore = new AzureAISearchVectorStore(
 new Azure.Search.Documents.Indexes.SearchIndexClient(
 new Uri(config["AzureAISearch:Endpoint"]),
 new AzureKeyCredential(config["AzureAISearch:ApiKey"])));
```Todo lo demás sigue igual. Esa es la belleza de la abstracción.

## Consejos para la construcción de sistemas RAG

Algunas cosas que he aprendido por las malas:

- **El tamaño del fragmento importa mucho.** Si es demasiado pequeño, se pierde el contexto. Demasiado grande y desperdiciarás tokens en contenido irrelevante. Comience con 500-800 tokens y ajústelos según sus datos.
- **La superposición evita problemas de límites.** Una superposición de 50 a 100 tokens entre fragmentos suele ser suficiente.
- **Recupera más de lo que crees.** Comienza con `topK = 5` y redúcelo si obtienes demasiado ruido. Es mejor tener contexto adicional que perderse la parte relevante.
- **Las indicaciones del sistema son cruciales.** Sea muy explícito acerca de utilizar solo el contexto proporcionado. Sin esa instrucción, el modelo felizmente alucinará "basándose en sus datos de entrenamiento".
- **Seguimiento de fuentes.** Almacene siempre metadatos con sus fragmentos para que pueda citar de dónde vino la respuesta. Los usuarios confían más en las respuestas cuando pueden verificar la fuente.
- **Reclasificar si es necesario.** La similitud de vectores no es perfecta. Para aplicaciones críticas, agregue un paso de reclasificación utilizando un modelo de codificador cruzado para mejorar la precisión.

## Conclusión

RAG es uno de los patrones más prácticos en IA en este momento. Le permite crear sistemas de preguntas y respuestas basados en IA a partir de sus propios datos sin necesidad de realizar ajustes, y Semantic Kernel lo hace sorprendentemente limpio en C#. Comience con el almacén en memoria, obtenga la fragmentación y las indicaciones correctas, luego intercambie una base de datos vectorial real cuando esté listo para la producción.

¡Feliz codificación!

## Recursos

- [Documentación del almacén de vectores del kernel semántico](https://learn.microsoft.com/en-us/semantic-kernel/concepts/vector-store-connectors/)
- [Patrón RAG con Azure AI Search](https://learn.microsoft.com/en-us/azure/search/retrieval-augmented-generation-overview)
- [Modelos de incrustación de texto](https://learn.microsoft.com/en-us/azure/ai-services/openai/concepts/models#embeddings)

Creación de flujos de trabajo de agentes con Microsoft Agent Framework

Tue, 10 Feb 2026 00:00:00 +0000

Introducción

Si ha leído mis publicaciones anteriores sobre Agent Framework de Microsoft, sabrá cómo crear agentes individuales e incluso chats grupales con múltiples agentes. Pero en escenarios del mundo real, a menudo se necesita algo más estructurado: un flujo de trabajo en el que los agentes se ejecutan en un orden específico, se pasan resultados entre sí y manejan la lógica de ramificación basada en los resultados.

Eso es exactamente lo que le brindan las capacidades de flujo de trabajo en Agent Framework. En lugar de incluir a los agentes en un chat grupal y esperar que lo resuelvan, usted define pasos explícitos, dependencias y flujo de datos entre agentes.

¿Qué son los flujos de trabajo de los agentes?

Piense en los flujos de trabajo de los agentes como si fueran un canal. Cada paso es manejado por un agente especializado, y el resultado de un paso alimenta el siguiente. Puede ejecutar pasos de forma secuencial, en paralelo o condicionalmente en función de los resultados.

Algunos ejemplos:

Contenido en proceso: Investigación → Borrador → Revisar → Publicar
Procesamiento de datos: Extraer → Transformar → Validar → Cargar
Atención al cliente: Clasificar → Ruta → Responder → Seguimiento

Requisitos previos

Asegúrese de tener los últimos paquetes de Agent Framework:

dotnet add package Microsoft.SemanticKernel
dotnet add package Microsoft.SemanticKernel.Agents.Core

Y un punto final de Azure OpenAI u OpenAI configurado.

Construyendo un flujo de trabajo secuencial

Construyamos un flujo de trabajo de creación de contenido con tres agentes: un investigador, un escritor y un editor.

Definiendo los agentes

using Microsoft.SemanticKernel;
using Microsoft.SemanticKernel.Agents;

var kernel = Kernel.CreateBuilder()
 .AddAzureOpenAIChatCompletion(
 deploymentName: "gpt-4o",
 endpoint: config["AzureOpenAI:Endpoint"],
 apiKey: config["AzureOpenAI:ApiKey"])
 .Build();

var researcher = new ChatCompletionAgent
{
 Name = "Researcher",
 Instructions = """
 You are a research specialist. Given a topic, find key facts, statistics,
 and talking points. Return a structured research brief with bullet points.
 Be thorough but concise.
 """,
 Kernel = kernel
};

var writer = new ChatCompletionAgent
{
 Name = "Writer",
 Instructions = """
 You are a technical blog writer. Given a research brief, write a clear
 and engaging blog post. Use a conversational tone, include code examples
 where relevant, and structure the post with clear headings.
 """,
 Kernel = kernel
};

var editor = new ChatCompletionAgent
{
 Name = "Editor",
 Instructions = """
 You are a senior editor. Review the blog post for clarity, accuracy,
 grammar, and flow. Return the corrected version with a summary of
 changes made at the end.
 """,
 Kernel = kernel
};

Ejecutando secuencialmente

El flujo de trabajo más simple es secuencial: cada agente procesa el resultado del anterior:

using Microsoft.SemanticKernel.Agents.Chat;
using Microsoft.SemanticKernel.ChatCompletion;

async Task<string> RunSequentialWorkflow(string topic)
{
 var history = new ChatHistory();
 string currentInput = $"Research the following topic: {topic}";

 var agents = new[] { researcher, writer, editor };

 foreach (var agent in agents)
 {
 history.AddUserMessage(currentInput);

 var response = new System.Text.StringBuilder();
 await foreach (var message in agent.InvokeAsync(history))
 {
 response.Append(message.Content);
 }

 currentInput = response.ToString();
 Console.WriteLine($"✅ {agent.Name} completed");
 }

 return currentInput;
}

var result = await RunSequentialWorkflow("Blazor render modes in .NET 9");
Console.WriteLine(result);

Cada agente obtiene el contexto acumulado, lo procesa y el resultado pasa al siguiente paso.

Ejecución paralela

A veces los agentes pueden trabajar de forma independiente. Por ejemplo, es posible que desees investigar varios subtemas al mismo tiempo:

async Task<List<string>> RunParallelResearch(string[] topics)
{
 var tasks = topics.Select(async topic =>
 {
 var history = new ChatHistory();
 history.AddUserMessage($"Research: {topic}");

 var response = new System.Text.StringBuilder();
 await foreach (var message in researcher.InvokeAsync(history))
 {
 response.Append(message.Content);
 }

 Console.WriteLine($"✅ Research completed: {topic}");
 return response.ToString();
 });

 var results = await Task.WhenAll(tasks);
 return results.ToList();
}

var topics = new[]
{
 "Blazor SSR streaming",
 "Enhanced navigation in .NET 9",
 "Render mode boundaries"
};

var briefs = await RunParallelResearch(topics);

Luego, puede introducir todos los resúmenes de investigación en un único agente de redacción para producir una publicación coherente.

Ramificación condicional

Los flujos de trabajo reales necesitan decisiones. Tal vez quieras un paso de control de calidad que te lleve al autor si la publicación no es lo suficientemente buena:

var qualityChecker = new ChatCompletionAgent
{
 Name = "QualityChecker",
 Instructions = """
 You are a quality assurance reviewer. Evaluate the blog post on:
 1. Technical accuracy
 2. Clarity and readability
 3. Completeness

 Respond with either:
 - "APPROVED" if the post meets all criteria
 - "REVISION NEEDED: [specific feedback]" if changes are required

 Be strict. Only approve posts that are truly ready to publish.
 """,
 Kernel = kernel
};

async Task<string> RunWithQualityLoop(string topic, int maxRevisions = 3)
{
 var history = new ChatHistory();

 // Step 1: Research
 history.AddUserMessage($"Research: {topic}");
 string research = await InvokeAgent(researcher, history);

 // Step 2: Write
 history.AddUserMessage(research);
 string draft = await InvokeAgent(writer, history);

 // Step 3: Quality loop
 for (int i = 0; i < maxRevisions; i++)
 {
 var qaHistory = new ChatHistory();
 qaHistory.AddUserMessage($"Review this post:\n\n{draft}");
 string qaResult = await InvokeAgent(qualityChecker, qaHistory);

 if (qaResult.Contains("APPROVED", StringComparison.OrdinalIgnoreCase))
 {
 Console.WriteLine($"✅ Approved after {i + 1} review(s)");
 return draft;
 }

 Console.WriteLine($"🔄 Revision {i + 1}: {qaResult[..Math.Min(100, qaResult.Length)]}...");

 // Send back to writer with feedback
 history.AddUserMessage($"Please revise based on this feedback:\n{qaResult}");
 draft = await InvokeAgent(writer, history);
 }

 Console.WriteLine("⚠️ Max revisions reached, returning latest draft");
 return draft;
}

async Task<string> InvokeAgent(ChatCompletionAgent agent, ChatHistory history)
{
 var response = new System.Text.StringBuilder();
 await foreach (var message in agent.InvokeAsync(history))
 {
 response.Append(message.Content);
 }
 return response.ToString();
}

Este patrón es súper útil. El verificador de calidad actúa como una puerta y el flujo de trabajo se repite hasta que el resultado es lo suficientemente bueno o alcanza el límite máximo de revisión.

Agregar complementos a los agentes de flujo de trabajo

Los agentes en flujos de trabajo pueden usar complementos como agentes independientes. Aquí es donde las cosas se vuelven realmente poderosas: los agentes pueden llamar a API, consultar bases de datos o realizar operaciones con archivos como parte de su paso de flujo de trabajo:

var researcherWithTools = new ChatCompletionAgent
{
 Name = "Researcher",
 Instructions = "Research the topic using available tools. Summarize findings.",
 Kernel = kernel
};

// Add a web search plugin
kernel.Plugins.AddFromType<WebSearchPlugin>();

// Add a database plugin
kernel.Plugins.AddFromObject(new DatabasePlugin(connectionString), "Database");

public class WebSearchPlugin
{
 [KernelFunction, Description("Search the web for information")]
 public async Task<string> SearchAsync(
 [Description("The search query")] string query)
 {
 // Your search implementation
 using var httpClient = new HttpClient();
 var response = await httpClient.GetStringAsync(
 $"https://api.search.example.com?q={Uri.EscapeDataString(query)}");
 return response;
 }
}

Manejo de errores en flujos de trabajo

Cuando encadena varios agentes, el manejo de errores se vuelve crítico. No querrás que un paso fallido bloquee todo el flujo de trabajo de forma silenciosa:

async Task<WorkflowResult> RunResilientWorkflow(string input)
{
 var result = new WorkflowResult();

 try
 {
 result.Research = await InvokeAgent(researcher, new ChatHistory(input));
 }
 catch (Exception ex)
 {
 result.Errors.Add($"Research failed: {ex.Message}");
 return result;
 }

 try
 {
 var writeHistory = new ChatHistory(result.Research);
 result.Draft = await InvokeAgent(writer, writeHistory);
 }
 catch (Exception ex)
 {
 result.Errors.Add($"Writing failed: {ex.Message}");
 result.Draft = result.Research; // Fallback to research output
 }

 result.Success = result.Errors.Count == 0;
 return result;
}

class WorkflowResult
{
 public string Research { get; set; } = "";
 public string Draft { get; set; } = "";
 public List<string> Errors { get; set; } = new();
 public bool Success { get; set; }
}

Mejores prácticas

Después de crear varios flujos de trabajo de agentes, esto es lo que aprendí:- Mantenga enfocadas las instrucciones de los agentes: cada agente debe hacer una cosa bien. No intentes convertirte en un agente de la navaja suiza.

Limitar contexto: no pase todo el historial de conversaciones a cada agente. Dale a cada paso solo lo que necesita.
Establecer límites de revisión: los bucles de calidad son excelentes, pero pueden ejecutarse para siempre si no tienes cuidado. Tenga siempre un límite máximo de iteraciones.
Registrar todo: los resultados de los agentes pueden ser impredecibles. Registre la entrada y salida de cada paso para depurar.
Utilice la ejecución paralela con prudencia: acelera las cosas, pero tenga cuidado con los límites de tasa de API y los costos de los tokens.
Pruebe primero con modelos más pequeños: desarrolle y pruebe su lógica de flujo de trabajo con GPT-3.5 antes de cambiar a GPT-4o para producción.

Conclusión

Los flujos de trabajo de los agentes le permiten crear canales de IA complejos y de varios pasos en los que cada agente es un especialista. Comience con flujos de trabajo secuenciales, agregue ejecución paralela donde los pasos sean independientes y use ramificaciones condicionales para puertas de calidad. Los patrones se pueden componer: una vez que lo domines, puedes crear una automatización bastante sofisticada.

¡Feliz codificación!

Recursos

Ciclo de vida de los componentes Blazor: la guía completa

Thu, 15 Jan 2026 00:00:00 +0000

He estado usando Blazor por un tiempo y, sinceramente, los métodos del ciclo de vida me confundieron al principio. ¿OnInitialized frente a OnInitializedAsync? ¿OnParametersSet frente a OnAfterRender? ¿Cuándo StateHasChanged activa realmente una nueva renderización? Después de muchas pruebas y errores, finalmente tengo un modelo mental sólido para todo ello.

El ciclo de vida de un vistazo

Cuando se procesa un componente Blazor, sigue estos métodos en orden:

SetParametersAsync
OnInitialized / OnInitializedAsync
OnParametersSet / OnParametersSetAsync
OnAfterRender / OnAfterRenderAsync
Dispose / DisposeAsync

Repasemos cada uno.

Establecer parámetrosAsync

Este es el primer método llamado. Recibe el ParameterView sin formato del componente principal. La mayoría de las veces no se anula esto: Blazor maneja los parámetros de mapeo automáticamente. Pero si necesita manejo o validación de parámetros personalizados antes de asignarlos:

public override async Task SetParametersAsync(ParameterView parameters)
{
 // Custom logic before parameters are set
 if (parameters.TryGetValue<string>("Title", out var title))
 {
 Console.WriteLine($"Title is being set to: {title}");
 }

 await base.SetParametersAsync(parameters);
}

He usado esto exactamente una vez en un proyecto real. La mayoría de las veces te lo saltarás.

OnInitialized / OnInitializedAsync

Aquí es donde realiza su trabajo de configuración: carga datos, inicializa servicios, establece valores predeterminados. Se ejecuta una vez cuando se crea el componente por primera vez.

@code {
 private List<Product> products = new();

 protected override async Task OnInitializedAsync()
 {
 products = await Http.GetFromJsonAsync<List<Product>>("api/products");
 }
}

Una cosa que me hizo tropezar: en Blazor Server, OnInitializedAsync recibe llamadas dos veces durante el procesamiento previo. La primera vez durante la renderización previa del lado del servidor y la segunda vez cuando se establece la conexión SignalR. Si su llamada API es costosa, es posible que desee encargarse de eso:

private bool isPrerendering = true;

protected override async Task OnInitializedAsync()
{
 products = await Http.GetFromJsonAsync<List<Product>>("api/products");
 isPrerendering = false;
}

O mejor aún, use PersistentComponentState para evitar la doble llamada por completo.

OnParametersSet / OnParametersSetAsync

Esto se activa cada vez que el componente principal se vuelve a renderizar y pasa nuevos valores de parámetros. También se activa después de OnInitialized. Este es el lugar adecuado para reaccionar ante cambios de parámetros:

[Parameter]
public int CategoryId { get; set; }

private int previousCategoryId;
private List<Product> products = new();

protected override async Task OnParametersSetAsync()
{
 if (CategoryId != previousCategoryId)
 {
 previousCategoryId = CategoryId;
 products = await Http.GetFromJsonAsync<List<Product>>(
 $"api/products?category={CategoryId}");
 }
}

La verificación de CategoryId != previousCategoryId es importante: sin ella, recargaría los datos cada vez que el padre se vuelva a renderizar, incluso si la categoría no cambiara.

OnAfterRender / OnAfterRenderAsync

Esto se activa después de que el componente se haya renderizado en el DOM. El parámetro firstRender te indica si es el renderizado inicial. Este es el lugar para las llamadas de JS Interop ya que los elementos DOM existen en este punto:

[Inject]
private IJSRuntime JS { get; set; }

protected override async Task OnAfterRenderAsync(bool firstRender)
{
 if (firstRender)
 {
 await JS.InvokeVoidAsync("initializeChart", chartElement);
 }
}

Utilizo mucho firstRender para evitar reiniciar las bibliotecas de JavaScript en cada renderizado. Si está configurando detectores de eventos, bibliotecas de gráficos o cualquier cosa que toque directamente el DOM, aquí es donde va.

Debería renderizar

Éste es menos conocido pero muy útil. Controla si un componente se vuelve a renderizar cuando se llama a StateHasChanged:

private bool shouldRender = true;

protected override bool ShouldRender() => shouldRender;

private void HeavyOperation()
{
 shouldRender = false;

 // Do a bunch of state changes without triggering renders
 for (int i = 0; i < 1000; i++)
 {
 items[i].Process();
 }

 shouldRender = true;
 StateHasChanged(); // Now render once with all changes
}

He usado esto para optimizar componentes que procesan listas grandes. En lugar de volver a renderizar cada cambio de elemento, agrupa las actualizaciones y las renderiza una vez al final.

Disponer/DisposeAsync

Cuando se elimina un componente de la interfaz de usuario, debe limpiar todos los recursos. Implementar IDisposable o IAsyncDisposable:

@implements IAsyncDisposable

@code {
 private Timer? timer;
 private IJSObjectReference? jsModule;

 protected override void OnInitialized()
 {
 timer = new Timer(OnTick, null, 0, 1000);
 }

 protected override async Task OnAfterRenderAsync(bool firstRender)
 {
 if (firstRender)
 {
 jsModule = await JS.InvokeAsync<IJSObjectReference>("import", "./timer.js");
 }
 }

 public async ValueTask DisposeAsync()
 {
 timer?.Dispose();

 if (jsModule is not null)
 {
 await jsModule.DisposeAsync();
 }
 }
}

Elementos comunes que debe eliminar: temporizadores, suscripciones a eventos, referencias de módulos JS, CancellationTokenSource y cualquier servicio IDisposable que haya creado.

EstadoHaCambiadoEste no es un método de ciclo de vida, pero está estrechamente relacionado. Le dice a Blazor “oye, mi estado cambió, por favor vuelve a renderizarme”. Blazor lo llama automáticamente después de los controladores de eventos, pero a veces es necesario llamarlo manualmente, generalmente cuando el estado cambia desde fuera del flujo normal de eventos de Blazor:

private async Task StartPolling()
{
 while (!cts.Token.IsCancellationRequested)
 {
 data = await Http.GetFromJsonAsync<Data>("api/data");
 StateHasChanged(); // Manual call needed since this isn't a Blazor event
 await Task.Delay(5000, cts.Token);
 }
}

Una nota importante: si está actualizando desde un hilo en segundo plano en Blazor Server, use InvokeAsync:

await InvokeAsync(() =>
{
 data = newData;
 StateHasChanged();
});

La imagen completa

Este es el orden en el que sucede todo:

Component created
 └─ SetParametersAsync
 └─ OnInitialized / OnInitializedAsync
 └─ OnParametersSet / OnParametersSetAsync
 └─ Render
 └─ OnAfterRender(firstRender: true)

Parameter change from parent
 └─ SetParametersAsync
 └─ OnParametersSet / OnParametersSetAsync
 └─ ShouldRender?
 └─ Render
 └─ OnAfterRender(firstRender: false)

Component removed
 └─ Dispose / DisposeAsync

Una vez que tenga este flujo en su cabeza, la depuración de problemas del ciclo de vida se vuelve mucho más fácil.

Espero que os haya gustado el post! No dudes en contactarme en cualquier red social en @emimontesdeoca.

Recursos

Agent Framework de Microsoft para salvar la Navidad

Tue, 16 Dec 2025 00:00:00 +0000

Introducción

Encontrar los regalos de Navidad perfectos puede resultar estresante. Entre intercambiar ideas sobre regalos, comparar precios entre tiendas y asegurarse de que todo llegue a tiempo, las compras navideñas rápidamente se vuelven abrumadoras. ¿Qué pasaría si pudiéramos delegar estas tareas a agentes de IA especializados que trabajen juntos? En esta publicación, exploraremos cómo usar Agent Framework de Microsoft para crear un sistema de múltiples agentes donde cada agente se especializa en una tarea específica, desde generar ideas para regalos hasta comparar precios, todo coordinado a través de flujos de trabajo.

Calendario tecnológico festivo 2025

Este proyecto es parte de mi sesión en el Festive Tech Calendar 2025, un increíble evento comunitario que celebra la tecnología durante la temporada navideña. Puede encontrar más información sobre el evento en Sessionize.

¿Qué es el marco de agentes de Microsoft?

Agent Framework es la solución de Microsoft para crear, orquestar e implementar agentes de IA y sistemas multiagente. Proporciona una base flexible para crear agentes que puedan trabajar de forma secuencial, simultánea o mediante patrones de transferencia. El marco es compatible con los modelos OpenAI, Azure OpenAI y Microsoft Foundry, lo que lo hace increíblemente versátil.

Las características clave incluyen:

Orquestación multiagente: chat grupal, patrones secuenciales, simultáneos y de transferencia
Ecosistema de complementos: Ampliación con funciones nativas, OpenAPI y protocolo de contexto modelo (MCP)
Soporte de flujo de trabajo: cree canales de agentes complejos con ejecutores y bordes

Requisitos previos

Antes de profundizar en el código, asegúrese de tener:

.NET 9
Acceso a Azure OpenAI (o clave API de OpenAI)
Visual Studio o Código de Visual Studio

Instale los paquetes necesarios (tenga en cuenta que el indicador --prerelease es obligatorio durante la vista previa):

dotnet add package Microsoft.Agents.AI.OpenAI --prerelease
dotnet add package Microsoft.Agents.AI.Workflows --prerelease
dotnet add package Azure.AI.OpenAI
dotnet add package Azure.Identity
dotnet add package Azure.AI.Agents.Persistent --prerelease

Los agentes de compras de regalos

Nuestro buscador de regalos de Navidad estará formado por tres agentes especializados que trabajarán juntos:

Agente de ideas de regalos: genera sugerencias de regalos creativas basadas en el perfil del destinatario.
Agente de comparación de precios: encuentra los mejores precios en diferentes tiendas
Agente de resumen: compila las recomendaciones finales.

Los modelos

Comencemos definiendo nuestros modelos de datos que fluirán a través del canal del agente:

public class GiftRecipient
{
 public string Name { get; set; } = string.Empty;
 public int Age { get; set; }
 public List<string> Interests { get; set; } = [];
 public decimal Budget { get; set; }
}

public class GiftIdea
{
 public string Name { get; set; } = string.Empty;
 public string Description { get; set; } = string.Empty;
 public string Category { get; set; } = string.Empty;
 public decimal EstimatedPrice { get; set; }
}

public class PriceResult
{
 public string GiftName { get; set; } = string.Empty;
 public string Store { get; set; } = string.Empty;
 public decimal Price { get; set; }
 public string Url { get; set; } = string.Empty;
}

public class GiftRecommendation
{
 public GiftIdea Gift { get; set; } = new();
 public List<PriceResult> Prices { get; set; } = [];
 public PriceResult? BestDeal { get; set; }
}

Construyendo los agentes

La belleza de Agent Framework es lo fácil que es crear agentes especializados. Cada agente es simplemente un ChatClientAgent con un mensaje de sistema específico que define su experiencia.

using Azure.AI.OpenAI;
using Azure.Identity;
using Microsoft.Agents.AI;
using Microsoft.Agents.AI.Workflows;
using Microsoft.Extensions.AI;

public static class ChristmasAgentFactory
{
 public static AIAgent CreateGiftIdeaAgent(IChatClient chatClient)
 {
 return new ChatClientAgent(
 chatClient,
 @"You are a creative Christmas gift advisor. When given information about a person
 (age, interests, budget), you suggest thoughtful and personalized gift ideas.

 For each suggestion, provide:
 - Gift name
 - Brief description of why it's a good fit
 - Category (Electronics, Books, Fashion, Home, Experience, etc.)
 - Estimated price range

 Always suggest 3-5 gift options within the specified budget.
 Format your response as a structured list.");
 }

 public static AIAgent CreatePriceComparisonAgent(IChatClient chatClient)
 {
 return new ChatClientAgent(
 chatClient,
 @"You are a price comparison specialist. Given a list of gift ideas,
 you research and compare prices from different online retailers.

 For each gift, provide:
 - Store name (Amazon, Best Buy, Target, Walmart, etc.)
 - Current price
 - Any available discounts or deals

 Always highlight the best deal for each item.
 Consider shipping costs and delivery times for Christmas.");
 }

 public static AIAgent CreateSummaryAgent(IChatClient chatClient)
 {
 return new ChatClientAgent(
 chatClient,
 @"You are a gift recommendation summarizer. Take the gift ideas and price
 comparisons and create a final recommendation report.

 Your summary should:
 - Rank gifts by value (quality vs price)
 - Highlight the top pick with reasoning
 - Include total cost estimate
 - Add any tips for holiday shopping

 Make the summary cheerful and festive!");
 }
}

Creando el flujo de trabajo

Ahora viene la parte divertida: conectar a nuestros agentes en un flujo de trabajo secuencial. Agent Framework proporciona WorkflowBuilder y AgentWorkflowBuilder para componer agentes en diferentes patrones.

public static class ChristmasGiftWorkflow
{
 public static async Task RunAsync()
 {
 // Set up the Azure OpenAI client
 var endpoint = Environment.GetEnvironmentVariable("AZURE_OPENAI_ENDPOINT")
 ?? throw new InvalidOperationException("AZURE_OPENAI_ENDPOINT is not set.");
 var deploymentName = Environment.GetEnvironmentVariable("AZURE_OPENAI_DEPLOYMENT_NAME")
 ?? "gpt-4o-mini";

 var chatClient = new AzureOpenAIClient(
 new Uri(endpoint),
 new DefaultAzureCredential())
 .GetChatClient(deploymentName)
 .AsIChatClient();

 // Create our specialized agents
 AIAgent giftIdeaAgent = ChristmasAgentFactory.CreateGiftIdeaAgent(chatClient);
 AIAgent priceAgent = ChristmasAgentFactory.CreatePriceComparisonAgent(chatClient);
 AIAgent summaryAgent = ChristmasAgentFactory.CreateSummaryAgent(chatClient);

 // Build a sequential workflow: Ideas -> Prices -> Summary
 var workflow = AgentWorkflowBuilder.BuildSequential(
 "ChristmasGiftFinder",
 [giftIdeaAgent, priceAgent, summaryAgent]);

 // Define our gift recipient
 var recipient = new GiftRecipient
 {
 Name = "Mom",
 Age = 55,
 Interests = ["gardening", "cooking", "reading", "yoga"],
 Budget = 100
 };

 var prompt = $@"Find Christmas gifts for {recipient.Name},
 age {recipient.Age}, who enjoys {string.Join(", ", recipient.Interests)}.
 Budget: ${recipient.Budget}";

 // Execute the workflow with streaming
 await using StreamingRun run = await InProcessExecution.StreamAsync(
 workflow,
 new ChatMessage(ChatRole.User, prompt));

 // Send the turn token to start processing
 await run.TrySendMessageAsync(new TurnToken(emitEvents: true));

 // Watch for workflow events
 await foreach (WorkflowEvent evt in run.WatchStreamAsync())
 {
 if (evt is AgentRunUpdateEvent agentUpdate)
 {
 Console.Write(agentUpdate.Data);
 }
 else if (evt is WorkflowOutputEvent outputEvent)
 {
 Console.WriteLine("\n🎄 Final Recommendations:");
 Console.WriteLine(outputEvent.Data);
 }
 }
 }
}

Ejecutando agentes simultáneamente

¿Qué pasa si queremos buscar regalos para varias personas a la vez? Agent Framework admite la ejecución simultánea, lo cual es perfecto para este escenario:

public static async Task FindGiftsForEveryoneAsync(IChatClient chatClient, List<GiftRecipient> recipients)
{
 // Create an agent for each recipient
 var agents = recipients.Select(r => new ChatClientAgent(
 chatClient,
 $@"Find the perfect Christmas gift for {r.Name} (age {r.Age}),
 who loves {string.Join(", ", r.Interests)}. Budget: ${r.Budget}.
 Provide one well-researched recommendation with price."
 )).ToList();

 // Build a concurrent workflow - all agents run in parallel
 var workflow = AgentWorkflowBuilder.BuildConcurrent(
 "FamilyGiftFinder",
 agents);

 await using StreamingRun run = await InProcessExecution.StreamAsync(
 workflow,
 new ChatMessage(ChatRole.User, "Find gifts now!"));

 await run.TrySendMessageAsync(new TurnToken(emitEvents: true));

 await foreach (WorkflowEvent evt in run.WatchStreamAsync())
 {
 if (evt is WorkflowOutputEvent output)
 {
 Console.WriteLine("🎁 All gift recommendations ready!");
 Console.WriteLine(output.Data);
 }
 }
}

Ejecutores personalizados para mayor controlPara escenarios más complejos, puede crear ejecutores personalizados que le brinden un control detallado sobre el flujo de trabajo:

public sealed class GiftValidatorExecutor : Executor<List<ChatMessage>, List<ChatMessage>>
{
 public GiftValidatorExecutor() : base("GiftValidator") { }

 public override async ValueTask<List<ChatMessage>> HandleAsync(
 List<ChatMessage> messages,
 IWorkflowContext context,
 CancellationToken cancellationToken = default)
 {
 var lastMessage = messages.LastOrDefault()?.Text ?? "";

 // Validate that suggestions are within budget
 if (lastMessage.Contains("over budget", StringComparison.OrdinalIgnoreCase))
 {
 Console.WriteLine("⚠️ Some suggestions exceeded budget, filtering...");
 // Add validation logic here
 }

 Console.WriteLine("✅ Gift suggestions validated!");
 return messages;
 }
}

Luego puede insertar este ejecutor en su flujo de trabajo:

var validator = new GiftValidatorExecutor();

var workflow = new WorkflowBuilder(giftIdeaAgent)
 .AddEdge(giftIdeaAgent, validator)
 .AddEdge(validator, priceAgent)
 .AddEdge(priceAgent, summaryAgent)
 .WithOutputFrom(summaryAgent)
 .Build();

Agregar búsqueda web real con Bing Grounding

Hasta ahora, nuestros agentes generan respuestas basadas en el conocimiento del modelo de IA. Pero, ¿qué pasa si queremos buscar en la web los precios y la disponibilidad reales de los productos? Aquí es donde entra en juego Grounding with Bing Search. Es una herramienta disponible en Microsoft Foundry (anteriormente Azure AI Foundry) que permite a sus agentes incorporar datos web públicos en tiempo real al generar respuestas.

Primero, deberá crear un recurso Grounding with Bing Search en el Portal Azure. Asegúrese de crearlo en el mismo grupo de recursos que su proyecto de IA.

Configuración de conexión a tierra con Bing Search

Lo bueno de Grounding with Bing Search es que se integra directamente con los agentes de Azure AI. El agente decide cuándo utilizar la herramienta de búsqueda en función de la consulta del usuario, busca en la web y utiliza los resultados para generar una respuesta fundamentada.

using Azure.AI.Agents.Persistent;
using Azure.Identity;

public static class BingGroundingSetup
{
 public static async Task<PersistentAgent> CreateAgentWithBingGroundingAsync(
 string projectEndpoint,
 string modelDeploymentName,
 string bingConnectionId)
 {
 // Create the Persistent Agents client
 var agentClient = new PersistentAgentsClient(projectEndpoint, new DefaultAzureCredential());

 // Configure the Bing Grounding tool
 var bingGroundingTool = new BingGroundingToolDefinition(
 new BingGroundingSearchToolParameters(
 [new BingGroundingSearchConfiguration(bingConnectionId)]
 )
 );

 // Create the agent with Bing Grounding enabled
 var agent = await agentClient.Administration.CreateAgentAsync(
 model: modelDeploymentName,
 name: "ChristmasPriceHunter",
 instructions: @"You are a Christmas gift price comparison specialist.

 When given gift ideas, use Bing to search for:
 - Current prices at major retailers (Amazon, Best Buy, Target, Walmart)
 - Available discounts and holiday deals
 - Shipping times to ensure delivery before Christmas

 Always provide URLs to the products you find.
 Highlight the best deals and recommend where to buy.",
 tools: [bingGroundingTool]
 );

 return agent;
 }
}

Creando un agente de comparación de precios con búsqueda real

Ahora creemos un agente de comparación de precios completo que busque en la web información real del producto:

using Azure.AI.Agents.Persistent;
using Azure.Identity;

public class ChristmasPriceAgent
{
 private readonly PersistentAgentsClient _client;
 private readonly string _modelDeployment;
 private readonly string _bingConnectionId;

 public ChristmasPriceAgent(string projectEndpoint, string modelDeployment, string bingConnectionId)
 {
 _client = new PersistentAgentsClient(projectEndpoint, new DefaultAzureCredential());
 _modelDeployment = modelDeployment;
 _bingConnectionId = bingConnectionId;
 }

 public async Task<string> FindGiftPricesAsync(string giftIdeas)
 {
 // Create agent with Bing Grounding
 var bingTool = new BingGroundingToolDefinition(
 new BingGroundingSearchToolParameters(
 [new BingGroundingSearchConfiguration(_bingConnectionId)]
 )
 );

 var agent = await _client.Administration.CreateAgentAsync(
 model: _modelDeployment,
 name: "PriceHunter",
 instructions: @"Search the web for current prices on the given gift ideas.
 For each gift, find prices from at least 2-3 different stores.
 Include direct links to the products.
 Note any Christmas sales or discounts available.",
 tools: [bingTool]
 );

 try
 {
 // Create a thread for the conversation
 var thread = await _client.Threads.CreateThreadAsync();

 // Add the gift ideas as a message
 await _client.Messages.CreateMessageAsync(
 thread.Id,
 MessageRole.User,
 $"Find current prices for these gift ideas: {giftIdeas}"
 );

 // Run the agent
 var run = await _client.Runs.CreateRunAsync(thread.Id, agent.Id);

 // Wait for completion
 do
 {
 await Task.Delay(500);
 run = await _client.Runs.GetRunAsync(thread.Id, run.Id);
 }
 while (run.Status == RunStatus.Queued || run.Status == RunStatus.InProgress);

 // Get the response
 var messages = _client.Messages.GetMessages(thread.Id);
 var response = messages
 .Where(m => m.Role == MessageRole.Agent)
 .SelectMany(m => m.ContentItems)
 .OfType<MessageTextContent>()
 .FirstOrDefault();

 // Clean up
 await _client.Threads.DeleteThreadAsync(thread.Id);

 return response?.Text ?? "No results found.";
 }
 finally
 {
 // Clean up the agent
 await _client.Administration.DeleteAgentAsync(agent.Id);
 }
 }
}

Integración de Bing Grounding en el flujo de trabajo

A continuación se explica cómo utilizar el agente de precios de Bing en un flujo de trabajo completo de búsqueda de regalos:

public static async Task RunWithBingGroundingAsync()
{
 var projectEndpoint = Environment.GetEnvironmentVariable("PROJECT_ENDPOINT")!;
 var modelDeployment = Environment.GetEnvironmentVariable("MODEL_DEPLOYMENT_NAME") ?? "gpt-4o";
 var bingConnectionId = Environment.GetEnvironmentVariable("BING_CONNECTION_ID")!;
 // Connection ID format: /subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.CognitiveServices/accounts/{account}/projects/{project}/connections/{connection}

 Console.WriteLine("🔍 Searching the web for real prices with Bing Grounding...\n");

 var priceAgent = new ChristmasPriceAgent(projectEndpoint, modelDeployment, bingConnectionId);

 // First, generate gift ideas (could come from another agent)
 var giftIdeas = "1. Milwaukee cordless drill set, 2. Weber portable grill, 3. Carhartt beanie";

 // Search for real prices
 var priceResults = await priceAgent.FindGiftPricesAsync(giftIdeas);

 Console.WriteLine("📊 Price Comparison Results:");
 Console.WriteLine(priceResults);
 Console.WriteLine("\n🎁 Happy Shopping! 🎁");
}

Procesamiento de citas a partir de resultados de Bing

Un aspecto importante de Grounding with Bing Search es que las respuestas incluyen citas con enlaces a los sitios web de origen. A continuación se explica cómo extraerlos y mostrarlos:

public static void ProcessBingGroundingResponse(IEnumerable<PersistentThreadMessage> messages)
{
 foreach (var message in messages.Where(m => m.Role == MessageRole.Agent))
 {
 foreach (var content in message.ContentItems)
 {
 if (content is MessageTextContent textContent)
 {
 var response = textContent.Text;

 // Process URL citations
 if (textContent.Annotations != null)
 {
 foreach (var annotation in textContent.Annotations)
 {
 if (annotation is MessageTextUriCitationAnnotation uriAnnotation)
 {
 // Replace citation placeholder with markdown link
 response = response.Replace(
 uriAnnotation.Text,
 $" [{uriAnnotation.UriCitation.Title}]({uriAnnotation.UriCitation.Uri})"
 );
 }
 }
 }

 Console.WriteLine(response);
 }
 }
 }
}

Ahora, cuando se ejecuta el agente de comparación de precios, utiliza Conexión a tierra con Bing Search para encontrar listados de productos reales, precios actuales y ofertas disponibles en la web en vivo. El agente decide automáticamente cuándo buscar en función de la consulta y devuelve respuestas fundamentadas con las citas adecuadas.

El programa completo

Así es como todo se combina en Program.cs:

using Azure.AI.OpenAI;
using Azure.Identity;
using Microsoft.Agents.AI;
using Microsoft.Agents.AI.Workflows;
using Microsoft.Extensions.AI;

Console.WriteLine("🎄 Christmas Gift Finder - Powered by AI Agents 🎄\n");

var endpoint = Environment.GetEnvironmentVariable("AZURE_OPENAI_ENDPOINT")!;
var deployment = Environment.GetEnvironmentVariable("AZURE_OPENAI_DEPLOYMENT_NAME") ?? "gpt-4o-mini";

var chatClient = new AzureOpenAIClient(new Uri(endpoint), new DefaultAzureCredential())
 .GetChatClient(deployment)
 .AsIChatClient();

// Create the agent team
var ideaAgent = ChristmasAgentFactory.CreateGiftIdeaAgent(chatClient);
var priceAgent = ChristmasAgentFactory.CreatePriceComparisonAgent(chatClient);
var summaryAgent = ChristmasAgentFactory.CreateSummaryAgent(chatClient);

// Build the workflow
var workflow = AgentWorkflowBuilder.BuildSequential(
 "ChristmasGiftWorkflow",
 [ideaAgent, priceAgent, summaryAgent]);

Console.Write("Who are you shopping for? ");
var recipientName = Console.ReadLine() ?? "Someone special";

Console.Write("What are their interests? ");
var interests = Console.ReadLine() ?? "general";

Console.Write("What's your budget? $");
var budget = Console.ReadLine() ?? "50";

var prompt = $"Find Christmas gifts for {recipientName} who enjoys {interests}. Budget: ${budget}";

Console.WriteLine("\n🔍 Searching for the perfect gifts...\n");

await using var run = await InProcessExecution.StreamAsync(
 workflow,
 new ChatMessage(ChatRole.User, prompt));

await run.TrySendMessageAsync(new TurnToken(emitEvents: true));

await foreach (var evt in run.WatchStreamAsync())
{
 switch (evt)
 {
 case AgentRunUpdateEvent update:
 Console.Write(update.Update.Text);
 break;
 case WorkflowOutputEvent output:
 Console.WriteLine("\n\n🎁 Happy Shopping! 🎁");
 break;
 }
}

Conclusión

Agent Framework de Microsoft hace que sea sorprendentemente fácil crear sistemas multiagente donde cada agente se especializa en una tarea específica. Al coordinar a estos agentes a través de flujos de trabajo, podemos abordar problemas complejos como las compras navideñas de forma estructurada y eficiente.

Lo que hace que esto sea aún más poderoso es la capacidad de agregar capacidades del mundo real a través de herramientas. Al integrar Grounding con Bing Search de Microsoft Foundry, nuestro agente de comparación de precios puede buscar en la web precios, ofertas y disponibilidad actuales, convirtiendo un simple chatbot de IA en un asistente de compras verdaderamente útil con las citas adecuadas.

El soporte del marco para patrones secuenciales, concurrentes y de transferencia significa que puede diseñar sistemas de agentes que satisfagan sus necesidades exactas. Ya sea encontrar regalos, planificar viajes o cualquier otra tarea de varios pasos, Agent Framework proporciona los elementos básicos para hacerlo realidad.¡Esta temporada navideña, deja que los agentes de IA se encarguen de la investigación mientras tú te concentras en envolver regalos y disfrutar del tiempo con la familia!

Código fuente

Los conceptos que se muestran en esta publicación se basan en los ejemplos oficiales de Agent Framework. Puede explorar más ejemplos en el repositorio GitHub de Microsoft Agent Framework.

¡Felices fiestas y feliz codificación! 🎄

Creación de un agregador de feeds RSS impulsado por IA

Fri, 12 Dec 2025 00:00:00 +0000

Como MVP de Microsoft y entusiasta de la tecnología, constantemente me ahogo en el océano de contenido sorprendente publicado en los DevBlogs de Microsoft. Desde anuncios de .NET hasta actualizaciones de Visual Studio, desde innovaciones de Azure hasta análisis profundos del Kernel Semántico, siempre sucede algo nuevo y emocionante en el ecosistema de Microsoft.

¿El problema? Mantenerse al día con todo esto es casi imposible.

Quería estar al tanto de los últimos anuncios y compartirlos con mi red, pero revisar manualmente siete fuentes RSS diferentes, leer artículos, crear publicaciones atractivas en las redes sociales y realizar un seguimiento de lo que ya había compartido se estaba convirtiendo en un trabajo de tiempo completo en sí mismo. Todas las mañanas abría varias pestañas del navegador, examinaba docenas de artículos, intentaba recordar cuáles ya había compartido y luego dedicaba un tiempo precioso a escribir publicaciones sobre los que me llamaban la atención.

Así que hice lo que haría cualquier desarrollador: Lo automaticé.

En esta guía completa, le explicaré cómo construí un agregador de fuentes RSS con tecnología de inteligencia artificial que monitorea múltiples fuentes RSS de Microsoft DevBlogs en busca de contenido nuevo, usa Azure OpenAI y Semantic Kernel para analizar artículos y generar publicaciones interesantes, crea documentación de rebajas detallada para cada artículo analizado, envía notificaciones a través de Telegram para que pueda revisar y compartir el contenido, realiza un seguimiento de todo para evitar publicaciones duplicadas y se ejecuta automáticamente a través de GitHub Actions.

Profundicemos en cada aspecto de esta solución.

La historia detrás de este proyecto

Vivir con sobrecarga de información

Permítanme describirles una imagen de mi mañana típica antes de crear esta herramienta. Me despertaba, tomaba mi café y abría mi computadora portátil para ver qué había de nuevo en el ecosistema de desarrolladores de Microsoft. Primero, navegué al sitio principal de DevBlogs para ver si había algún anuncio importante. Luego consultaría el blog de .NET específicamente porque esa es mi pila de tecnología principal. Después de eso, pasaría al blog de Semantic Kernel, ya que la IA se está volviendo cada vez más importante. El blog de Visual Studio fue el siguiente en la lista porque las actualizaciones de IDE pueden afectar significativamente mi flujo de trabajo diario. Luego vino el blog DevOps para CI/CD y noticias relacionadas con GitHub, seguido por el blog All Things Azure para actualizaciones de infraestructura en la nube y, finalmente, el blog Azure SQL para innovaciones en bases de datos.

Son siete feeds diferentes para verificar. Cada uno de estos blogs publica varios artículos por semana, a veces varios por día durante los períodos de anuncios importantes, como .NET Conf o Build. Son potencialmente docenas de artículos para rastrear, leer y compartir. Y esta es la cuestión: como alguien que valora compartir conocimientos con la comunidad, no quería simplemente leer estos artículos. Quería compartir los más valiosos con mi red en LinkedIn, ayudando a otros desarrolladores a mantenerse informados también.Pero elaborar una buena publicación en LinkedIn lleva tiempo. Debe leer el artículo detenidamente, comprender los puntos clave, pensar por qué es importante para su audiencia, escribir un gancho atractivo y formatear todo correctamente. Multiplique eso por varios artículos por semana y obtendrá horas de trabajo.

Lo que realmente quería

Después de lidiar con esto durante meses, me senté y pensé en cómo sería una solución ideal. En primer lugar, no quería volver a perderme anuncios importantes. El sistema debería detectar automáticamente nuevos artículos tan pronto como se publiquen. También quería ahorrar tiempo en la creación de contenido permitiendo que la IA me ayudara a crear publicaciones atractivas, no para reemplazar mi voz por completo, sino para brindarme un punto de partida sólido que pudiera personalizar.

La coherencia fue otro factor importante. Quería compartir contenido con regularidad sin tener que acordarme de hacerlo manualmente todos los días. El aspecto de seguimiento también fue crucial: necesitaba una forma de saber lo que ya había compartido para evitar publicar duplicados y molestar a mis seguidores. Finalmente, quería mantenerme organizado con un registro permanente de todo lo que he procesado, para poder mirar hacia atrás y ver qué temas he cubierto.

La solución toma forma

La solución que imaginé se ejecutaría según un cronograma utilizando GitHub Actions, completamente con manos libres. Recuperaría los siete feeds automáticamente sin tener que abrir una sola pestaña del navegador. El componente de IA realmente leería y comprendería el contenido y luego lo resumiría de una manera que fuera útil para mi audiencia. En lugar de tener que escribir publicaciones desde cero, crearía contenido de redes sociales listo para compartir que podría modificar si fuera necesario. Todo se enviaría a mi Telegram para su revisión, de modo que pudiera mirar rápidamente mi teléfono y decidir qué compartir. Y por supuesto, mantendría un registro permanente de todo para referencia futura.

Antes de comenzar a construir

Lo que necesitará en su máquina

Para seguir este tutorial, necesitará algunas cosas instaladas en su máquina de desarrollo. El más importante es la versión 9.0 o posterior del SDK de .NET. Este es nuestro tiempo de ejecución y proporciona todas las herramientas de compilación que necesitamos. Si no lo tiene instalado, diríjase a dot.net y descargue la última versión. La instalación es sencilla en Windows, macOS o Linux.

También querrás tener instalado Git para el control de versiones. Enviaremos nuestro código a GitHub y usaremos GitHub Actions para la automatización, por lo que tener Git configurado localmente es esencial. Cualquier versión reciente funcionará bien.

Para su entorno de desarrollo, recomiendo Visual Studio o VS Code. Personalmente, uso VS Code para la mayor parte de mi trabajo estos días porque es liviano y tiene un excelente soporte para C# a través de la extensión C# Dev Kit. Pero si se siente más cómodo con Visual Studio completo, eso también funciona perfectamente.

Servicios y cuentas que necesitarásMás allá de las herramientas locales, necesitará cuentas con algunos servicios. El más importante es Azure OpenAI, que impulsa nuestro análisis de IA. Este es un servicio de pago por uso, pero los costos son mínimos para este caso de uso: estamos hablando de centavos por artículo analizado. Si no tiene una cuenta de Azure, puede registrarse para una prueba gratuita que incluye algunos créditos para comenzar.

Para las notificaciones, usaremos un Telegram Bot. Lo mejor de Telegram es que su API de bot es de uso completamente gratuito. Puedes crear tantos bots como quieras y enviar mensajes ilimitados. Lo guiaré a través del proceso de configuración más adelante en esta guía.

Finalmente, necesitará una cuenta de GitHub para alojar su código y ejecutar GitHub Actions. El nivel gratuito es más que suficiente para este proyecto. GitHub le ofrece 2000 minutos de tiempo de ejecución de Acciones por mes en repositorios privados y minutos ilimitados en repositorios públicos.

Las bibliotecas que hacen esto posible

Nuestro proyecto se basa en tres paquetes principales de NuGet, cada uno de los cuales tiene un propósito específico.

El primero es HtmlAgilityPack, que es el estándar de oro para el análisis de HTML en .NET. Cuando recuperamos un artículo de un blog, recuperamos el HTML completo de la página, incluidos menús de navegación, pies de página, anuncios y todo tipo de elementos que no nos interesan. HtmlAgilityPack nos permite analizar ese HTML y extraer solo el contenido del artículo que necesitamos.

El segundo paquete es Microsoft.SemanticKernel, que es el SDK de Microsoft para integrar modelos de IA en aplicaciones. Piense en ello como el puente entre su código .NET y modelos de lenguaje grandes como GPT-4. Maneja toda la complejidad de las llamadas API, la administración de tokens y el análisis de respuestas, lo que le permite concentrarse en lo que realmente desea que haga la IA.

El tercer paquete es System.ServiceModel.Syndication, que proporciona soporte integrado para analizar fuentes RSS y Atom. RSS puede parecer una tecnología antigua, pero sigue siendo la mejor manera de obtener actualizaciones estructuradas de blogs y sitios de noticias. Este paquete convierte fuentes XML sin formato en objetos C# fuertemente tipados con los que es fácil trabajar.

Comprender la arquitectura

Cómo encajan las piezas

Antes de profundizar en el código, permítanme explicarles cómo funcionan todos los componentes juntos. Comprender el panorama general hará que los detalles de la implementación sean mucho más claros.

En el nivel más alto, tenemos nuestro archivo principal Program.cs que actúa como orquestador. Este es el punto de entrada de nuestra aplicación y coordina todos los demás componentes. Cuando se ejecuta la aplicación, primero carga la configuración de las variables de entorno, como claves API y credenciales de Telegram. Luego sale y recupera canales RSS de las siete fuentes de Microsoft DevBlogs. A medida que procesa estos feeds, deduplica artículos para manejar casos en los que el mismo artículo aparece en varios feeds. Compara cada artículo con nuestro archivo de seguimiento para ver si ya lo hemos procesado. Para artículos nuevos, los entrega al analizador de IA para su procesamiento.La clase ArticleAnalyzer es donde ocurre la magia de la IA. Este componente recibe un artículo y hace varias cosas con él. Primero, recupera el contenido HTML completo de la URL del artículo. Luego extrae texto limpio de ese HTML, eliminando todos los elementos de navegación, scripts y estilos que no necesitamos. Una vez que tiene texto limpio, lo envía a Azure OpenAI a través del Semantic Kernel con un mensaje cuidadosamente elaborado. La IA analiza el artículo y devuelve una respuesta estructurada que incluye un resumen, temas clave, explicación de relevancia y, lo más importante, una publicación de LinkedIn lista para usar. El analizador analiza esta respuesta y devuelve un objeto ArticleAnalysis que contiene toda esta información.

La clase MarkdownGenerator toma ese objeto ArticleAnalysis y crea un registro permanente del mismo. Genera un archivo de rebajas con un formato agradable que incluye todos los metadatos del artículo, el análisis de la IA y la publicación generada. Estos archivos se almacenan en un directorio de publicaciones generadas, lo que le brinda un archivo con capacidad de búsqueda de todo lo que ha procesado.

Finalmente, la integración de Telegram envía el contenido de la publicación generada a su teléfono. Este es el punto en el que usted, como ser humano, puede revisar el trabajo de la IA y decidir si lo comparte. El bot te envía un mensaje con el contenido de la publicación y puedes copiarlo directamente a LinkedIn o modificarlo primero.

El flujo de datos

Permítame explicarle lo que sucede cuando se publica un nuevo artículo en el blog de .NET. El flujo de trabajo comienza cuando GitHub Actions activa nuestra aplicación según lo programado, digamos cada seis horas. La aplicación se activa y comienza a buscar los siete canales RSS. Cada feed devuelve un documento XML que contiene los artículos más recientes de ese blog.

A medida que analizamos cada feed, extraemos artículos individuales y los almacenamos en una lista. Pero aquí hay una parte complicada: el feed principal de DevBlogs a menudo incluye artículos que también aparecen en los feeds de categorías individuales. Por lo tanto, es posible que aparezca un artículo sobre “.NET 10” tanto en la fuente principal como en la fuente específica de .NET. Manejamos esto rastreando las URL en un HashSet, lo que evita automáticamente los duplicados.

Una vez que tenemos nuestra lista de artículos deduplicados, la filtramos solo a los recientes (generalmente artículos publicados en el último día). No queremos procesar artículos antiguos que ya hemos manejado en ejecuciones anteriores. Luego comparamos cada artículo reciente con nuestro archivo de seguimiento. Si ya procesamos y publicamos sobre un artículo, lo omitimos.

Para cada artículo nuevo, iniciamos el proceso de análisis de IA. El analizador recupera el HTML del artículo completo, lo limpia y lo envía a GPT-4 con nuestro mensaje. La IA lee el artículo y genera un análisis completo junto con una publicación de LinkedIn. Guardamos este análisis en un archivo de rebajas para nuestros registros.Con el análisis completo, formateamos un mensaje y lo enviamos vía Telegram. El mensaje incluye el contenido de la publicación generada con la URL y los hashtags adjuntos. En mi teléfono recibo una notificación, reviso la publicación y, si me gusta, puedo copiarla y compartirla en LinkedIn con solo unos pocos toques.

Finalmente, actualizamos nuestro archivo de seguimiento para marcar este artículo como procesado, de modo que no lo volvamos a manejar en ejecuciones futuras. Si se creó o modificó algún archivo, GitHub Actions envía estos cambios nuevamente al repositorio, manteniendo todo sincronizado.

Configurar el proyecto desde cero

Creando la estructura de la solución

Empecemos a construir. Abra su terminal y navegue hasta donde desea crear el proyecto. Me gusta mantener mis proyectos organizados en una carpeta de Desarrollo, pero puedes colocarlos donde tenga sentido para ti.

Primero, crearemos un nuevo archivo de solución. En .NET, una solución es un contenedor que puede contener múltiples proyectos. Aunque por ahora solo tenemos un proyecto, comenzar con una solución hace que sea más fácil agregar más proyectos más adelante si es necesario. Ejecute el comando dotnet new sln -n vs-feed-linkedin para crear una solución llamada vs-feed-linkedin.

A continuación, necesitamos crear nuestro proyecto de aplicación de consola. Pondremos esto en un subdirectorio src para mantener todo organizado. Ejecute dotnet new console -n VsFeedLinkedin -o src para crear un proyecto de consola llamado VsFeedLinkedin en la carpeta src. Luego agregue este proyecto a nuestra solución con dotnet sln add src/VsFeedLinkedin.csproj.

Ahora navega al directorio src con cd src. Aquí es donde agregaremos nuestros paquetes NuGet y realizaremos la mayor parte de nuestro desarrollo.

Agregar los paquetes necesarios

Con nuestro proyecto creado, necesitamos agregar los tres paquetes NuGet que mencioné anteriormente. Ejecute cada uno de estos comandos en secuencia:

dotnet add package System.ServiceModel.Syndication --version 9.0.9
dotnet add package Microsoft.SemanticKernel --version 1.30.0
dotnet add package HtmlAgilityPack --version 1.11.72

Después de ejecutar estos comandos, el archivo de su proyecto debería verse así:

<Project Sdk="Microsoft.NET.Sdk">

 <PropertyGroup>
 <OutputType>Exe</OutputType>
 <TargetFramework>net9.0</TargetFramework>
 <ImplicitUsings>enable</ImplicitUsings>
 <Nullable>enable</Nullable>
 </PropertyGroup>

 <ItemGroup>
 <PackageReference Include="HtmlAgilityPack" Version="1.11.72" />
 <PackageReference Include="Microsoft.SemanticKernel" Version="1.30.0" />
 <PackageReference Include="System.ServiceModel.Syndication" Version="9.0.9" />
 </ItemGroup>

</Project>

El archivo del proyecto le dice a .NET que estamos creando un ejecutable (OutputType es Exe), apuntando a .NET 9.0 y usando características modernas de C# como usos implícitos y tipos de referencia que aceptan valores NULL. La sección ItemGroup enumera nuestras tres dependencias de paquetes con sus versiones exactas.

Profundice en las fuentes RSS

¿Qué es exactamente RSS?

Antes de comenzar a escribir código para recuperar feeds, asegurémonos de comprender con qué estamos trabajando. RSS significa Really Simple Syndication y es un formato XML estandarizado para distribuir actualizaciones de contenido. La idea es simple: en lugar de requerir que los usuarios visiten su sitio web para ver si hay contenido nuevo, publica un archivo legible por máquina que enumera su contenido reciente. Luego, las aplicaciones pueden sondear este archivo periódicamente para descubrir nuevos artículos.

RSS existe desde finales de los años 1990 y principios de los 2000. Podría pensar que es una tecnología obsoleta, pero en realidad todavía se usa ampliamente, especialmente en blogs, sitios de noticias y podcasts. La belleza de RSS es su simplicidad. Es simplemente XML con una estructura definida y cualquier aplicación puede analizarlo.

La estructura de un feed de DevBlogsCuando recupera una fuente RSS de Microsoft DevBlogs, obtiene un documento XML que sigue una estructura específica. En el nivel superior, hay un elemento rss que contiene un elemento de canal único. El canal representa el blog en sí e incluye metadatos como el título, la URL y la descripción del blog.

Dentro del canal, encontrará varios elementos de elementos, cada uno de los cuales representa una publicación de blog individual. Cada elemento incluye un título (el título del artículo), un enlace (la URL donde puede leer el artículo completo), una fecha de publicación (cuando se publicó el artículo), un elemento dc:creator (el nombre del autor), uno o más elementos de categoría (etiquetas para el artículo) y una descripción (generalmente un resumen o extracto del artículo).

Aquí hay un ejemplo simplificado de cómo se ve esto:

<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
 <channel>
 <title>.NET Blog</title>
 <link>https://devblogs.microsoft.com/dotnet</link>
 <description>The latest news about .NET</description>
 <item>
 <title>Announcing .NET 10</title>
 <link>https://devblogs.microsoft.com/dotnet/announcing-dotnet-10</link>
 <pubDate>Mon, 10 Dec 2025 12:00:00 GMT</pubDate>
 <dc:creator>Microsoft</dc:creator>
 <category>Announcements</category>
 <category>.NET</category>
 <description>Article summary...</description>
 </item>
 </channel>
</rss>

Lo mejor del paquete System.ServiceModel.Syndication de .NET es que analiza todo esto por nosotros. No tenemos que navegar manualmente por nodos XML ni preocuparnos por diferentes versiones de RSS. Simplemente cargamos el feed y recuperamos objetos fuertemente tipados.

Los siete feeds que monitoreamos

En mi implementación, superviso siete fuentes diferentes de Microsoft DevBlogs. La fuente principal de DevBlogs en devblogs.microsoft.com/feed nos brinda una visión amplia de todo lo que Microsoft publica en todos sus blogs de desarrolladores. La fuente específica de .NET en devblogs.microsoft.com/dotnet/feed se centra específicamente en las versiones, características y mejores prácticas de .NET. El feed Semantic Kernel en devblogs.microsoft.com/semantic-kernel/feed cubre la orquestación e integración de la IA, algo cada vez más importante a medida que la IA se vuelve central para el desarrollo moderno.

La fuente de Visual Studio en devblogs.microsoft.com/visualstudio/feed me mantiene actualizado sobre las mejoras de IDE y las características de productividad. La fuente de DevOps en devblogs.microsoft.com/devops/feed cubre temas de Azure DevOps, GitHub y CI/CD. La fuente All Things Azure en devblogs.microsoft.com/all-things-azure/feed se centra en los servicios de nube y los patrones de arquitectura. Finalmente, la fuente de Azure SQL en devblogs.microsoft.com/azure-sql/feed cubre las innovaciones y características de las bases de datos.

Quizás se pregunte por qué reviso tanto el feed principal como el feed de categorías individuales. La fuente principal me da amplitud: veré artículos de cualquier blog de desarrolladores de Microsoft, incluidos aquellos que quizás no conozca. Las fuentes de categorías me dan profundidad: garantizan que no me pierda nada importante en mis áreas principales de interés, incluso si esos artículos son eliminados de la fuente principal por contenido más nuevo.

Construyendo la lógica de recuperación de RSS

La función de búsqueda principal

Ahora escribamos algo de código. La base de nuestra aplicación es la capacidad de buscar y analizar fuentes RSS. Aquí está la función que maneja esto:

static async Task<SyndicationFeed?> FetchRssFeedAsync(string url)
{
 using var httpClient = new HttpClient();
 httpClient.DefaultRequestHeaders.Add("User-Agent", "VsFeedLinkedin/1.0");

 var response = await httpClient.GetStringAsync(url);

 using var stringReader = new StringReader(response);

 var settings = new XmlReaderSettings
 {
 DtdProcessing = DtdProcessing.Parse,
 MaxCharactersFromEntities = 1024
 };

 using var xmlReader = XmlReader.Create(stringReader, settings);

 return SyndicationFeed.Load(xmlReader);
}

Déjame explicarte lo que hace este código. Comenzamos creando un HttpClient, que es la clase integrada de .NET para realizar solicitudes HTTP. Configuramos un encabezado User-Agent porque algunos servidores bloquean solicitudes que no se identifican. Es una buena práctica configurar esto incluso cuando los servidores no lo requieran.Luego realizamos una solicitud GET a la URL del feed y recibimos la respuesta como una cadena. Esta cadena contiene el XML sin formato de la fuente RSS.

Para analizar este XML, creamos un StringReader para envolver nuestra cadena de respuesta y luego configuramos algunos XmlReaderSettings. La configuración de DtdProcessing es importante: las fuentes RSS a veces incluyen declaraciones DTD (Definición de tipo de documento) que deben procesarse. La configuración MaxCharactersFromEntities es una medida de seguridad que previene ataques de bombas XML al limitar la expansión de entidades que puede ocurrir.

Finalmente, creamos un XmlReader con esta configuración y usamos SyndicationFeed.Load para analizar el XML en un objeto SyndicationFeed fuertemente tipado. Esto nos da acceso a los metadatos del feed y a todos sus elementos a través de agradables propiedades de C# en lugar de navegación XML sin formato.

Obteniendo múltiples feeds con manejo de errores

En el mundo real, las solicitudes de red fallan. Los servidores caen, las conexiones se agotan y el formato XML puede tener un formato incorrecto. Necesitamos manejar estos casos con gracia. Así es como recuperamos todos nuestros feeds y al mismo tiempo somos resistentes a las fallas:

var allArticles = new List<(SyndicationItem item, string feedUrl)>();
var seenUrls = new HashSet<string>();

foreach (var feedUrl in feedUrls)
{
 try
 {
 Console.WriteLine($" 📡 Fetching {feedUrl}...");
 var feed = await FetchRssFeedAsync(feedUrl);

 if (feed?.Items != null && feed.Items.Any())
 {
 foreach (var item in feed.Items)
 {
 var itemUrl = item.Links.FirstOrDefault()?.Uri.ToString() ?? "";
 if (!string.IsNullOrEmpty(itemUrl) && seenUrls.Add(itemUrl))
 {
 allArticles.Add((item, feedUrl));
 }
 }
 }
 }
 catch (Exception ex)
 {
 Console.WriteLine($" ⚠️ Failed to fetch {feedUrl}: {ex.Message}");
 }
}

Mantenemos dos colecciones aquí. La lista de todos los artículos contendrá todos los artículos que encontremos, junto con el feed de donde provienen. SeenUrls HashSet rastrea las URL de artículos que ya hemos visto, lo que nos ayuda a evitar duplicados.

Recorremos cada URL del feed y envolvemos la operación de recuperación en un bloque try-catch. Si falla la recuperación de un feed en particular (tal vez el servidor esté inactivo temporalmente), registramos una advertencia y continuamos con el siguiente feed. De esta manera, un problema con un feed no nos impide procesar los demás.

Para cada feed obtenido con éxito, iteramos a través de sus elementos. Extraemos la URL del artículo de la colección de enlaces del artículo. El método HashSet.Add devuelve false si la URL ya está en el conjunto, lo cual es perfecto para nuestra lógica de deduplicación. Solo agregamos el artículo a nuestra lista si es nuevo.

Almacenamos la URL del feed junto con cada artículo porque esta información puede ser útil más adelante; por ejemplo, es posible que queramos saber de qué feed específico proviene un artículo para fines de depuración o registro.

Manejo de duplicados y seguimiento del estado

El desafío de la deduplicación

Como mencioné anteriormente, Microsoft DevBlogs tiene una estructura de alimentación jerárquica que crea un desafío interesante. Cuando un miembro del equipo .NET publica un artículo sobre, por ejemplo, mejoras de rendimiento en .NET 10, ese artículo probablemente aparecerá tanto en la fuente principal de DevBlogs como en la fuente específica de .NET. A veces, incluso puede aparecer en el feed de Visual Studio si se relaciona con funciones del IDE.

Si procesáramos ingenuamente cada artículo de cada feed, terminaríamos analizando y publicando sobre el mismo artículo varias veces. Eso desperdiciaría llamadas API a Azure OpenAI, enviaría spam a nuestro Telegram con notificaciones duplicadas y potencialmente molestaría a nuestros seguidores si publicáramos duplicados.La solución es la deduplicación basada en URL. Cada artículo tiene una URL única, por lo que podemos usarla como identificador. La estructura de datos HashSet es perfecta para esto porque proporciona un tiempo de búsqueda O(1) y evita automáticamente duplicados. Cuando intentamos agregar una URL que ya está en el conjunto, el método Agregar simplemente devuelve falso, haciéndonos saber que debemos omitir ese artículo.

Estado persistente con Markdown

La deduplicación maneja duplicados dentro de una sola ejecución, pero ¿qué pasa entre ejecuciones? Cuando nuestra aplicación se ejecuta cada seis horas, debemos recordar qué artículos ya hemos procesado para no volver a procesarlos.

Elegí almacenar este estado en un archivo de rebajas llamado post-articles.md. ¿Por qué rebajas? Algunas razones. Primero, es legible por humanos. Puedo abrir el archivo y ver inmediatamente qué artículos he compartido. En segundo lugar, está controlado por versiones. Dado que este archivo se encuentra en nuestro repositorio de Git, tengo un historial completo de cuándo se procesaron los artículos. En tercer lugar, sirve como documentación. Cualquiera que mire el repositorio puede ver lo que ha hecho la aplicación.

El formato de este archivo es simple. Tiene un encabezado, una marca de tiempo que muestra cuándo se ejecutó la aplicación por última vez y luego una lista de artículos en formato de enlace de rebajas:

# Posted Articles

*Last run: 2025-12-10 15:30:00*

List of articles posted to LinkedIn:

- [Announcing .NET 10](https://devblogs.microsoft.com/dotnet/announcing-dotnet-10?wt.mc_id=DT-MVP-5004972) - Posted on 2025-12-10 15:30:00 (Published: 2025-12-10)
- [Visual Studio 2026 Preview](https://devblogs.microsoft.com/visualstudio/vs-2026-preview?wt.mc_id=DT-MVP-5004972) - Posted on 2025-12-09 10:15:00 (Published: 2025-12-09)

Cargando y analizando el archivo de seguimiento

Para comprobar si ya hemos procesado un artículo, debemos cargar este archivo y extraer las URL. Aquí está la función que hace esto:

static HashSet<string> LoadPostedArticles(string filePath)
{
 var postedUrls = new HashSet<string>();

 if (!File.Exists(filePath))
 {
 return postedUrls;
 }

 var lines = File.ReadAllLines(filePath);
 foreach (var line in lines)
 {
 var match = System.Text.RegularExpressions.Regex.Match(line, @"\(([^)]+)\)");
 if (match.Success)
 {
 var url = match.Groups[1].Value;

 if (url.Contains("?wt.mc_id="))
 {
 url = url.Substring(0, url.IndexOf("?wt.mc_id="));
 }
 else if (url.Contains("?"))
 {
 url = url.Substring(0, url.IndexOf("?"));
 }

 url = url.TrimEnd('/');
 postedUrls.Add(url);
 }
 }

 return postedUrls;
}

Esta función devuelve un HashSet que contiene todas las URL que ya hemos procesado. Comenzamos comprobando si el archivo existe; en la primera ejecución, no existe, por lo que devolvemos un conjunto vacío.

Para cada línea del archivo, utilizamos una expresión regular para extraer la URL del formato de enlace de rebajas. La expresión regular $([^)]+)$ coincide con todo lo que esté entre paréntesis, que es donde los enlaces de rebajas almacenan sus URL.

Luego viene un paso importante: la normalización de URL. Las URL del mismo artículo pueden variar en formato. La fuente RSS puede proporcionarnos https://devblogs.microsoft.com/dotnet/article, pero nuestra versión guardada tiene un parámetro de seguimiento adjunto: https://devblogs.microsoft.com/dotnet/article?wt.mc_id=DT-MVP-5004972. Algunas URL tienen barras al final, otras no.

Para manejar esto, eliminamos todos los parámetros de consulta (todo lo que está después de ?) y eliminamos las barras diagonales. Esta normalización garantiza que reconozcamos los artículos como duplicados incluso si sus URL difieren de manera superficial.

Guardando nuevos artículos

Cuando procesamos exitosamente un artículo, debemos agregarlo a nuestro archivo de seguimiento:

static void SavePostedArticle(string filePath, string url, string title, DateTimeOffset publishDate)
{
 var markdownEntry = $"- [{title}]({url}) - Posted on {DateTime.Now:yyyy-MM-dd HH:mm:ss} (Published: {publishDate:yyyy-MM-dd})\n";

 if (!File.Exists(filePath))
 {
 File.WriteAllText(filePath, "# Posted Articles\n\n*Last run: {DateTime.Now:yyyy-MM-dd HH:mm:ss}*\n\nList of articles posted:\n\n");
 }

 File.AppendAllText(filePath, markdownEntry);
}

Esta función crea una entrada con formato de rebajas con el título del artículo como enlace, seguido de marcas de tiempo que muestran cuándo lo publicamos y cuándo se publicó originalmente. Si el archivo aún no existe, primero lo creamos con un encabezado.

El motor de análisis de IA

Comprender el núcleo semánticoAhora llegamos a la parte más interesante de nuestra aplicación: el análisis de IA. Semantic Kernel es el SDK de código abierto de Microsoft para integrar grandes modelos de lenguaje en aplicaciones. Es más que una simple envoltura de llamadas API. Proporciona un marco para crear aplicaciones de IA sofisticadas con funciones como complementos, planificadores y memoria.

Para nuestro caso de uso, utilizamos las capacidades de finalización de chat de Semantic Kernel. Enviaremos un mensaje a Azure OpenAI y el modelo analizará nuestro artículo y generará una respuesta. Semantic Kernel maneja toda la complejidad de la autenticación de API, el formato de solicitudes y el análisis de respuestas.

Configuración del analizador de artículos

Veamos cómo configuramos nuestra clase de analizador:

using Microsoft.SemanticKernel;
using Microsoft.SemanticKernel.ChatCompletion;
using HtmlAgilityPack;

namespace VsFeedLinkedin.Services;

public class ArticleAnalyzer
{
 private readonly Kernel _kernel;
 private readonly IChatCompletionService _chatService;

 public ArticleAnalyzer(string endpoint, string apiKey, string deploymentName)
 {
 var builder = Kernel.CreateBuilder();

 builder.AddAzureOpenAIChatCompletion(
 deploymentName: deploymentName,
 endpoint: endpoint,
 apiKey: apiKey
 );

 _kernel = builder.Build();
 _chatService = _kernel.GetRequiredService<IChatCompletionService>();
 }

Semantic Kernel utiliza un patrón de creación para la configuración. Creamos un KernelBuilder, agregamos nuestro servicio de finalización de chat Azure OpenAI con las credenciales necesarias y luego compilamos el kernel. Del kernel construido, recuperamos la interfaz IChatCompletionService, que usaremos para enviar mensajes y recibir respuestas.

El constructor toma tres parámetros: el punto final de Azure OpenAI (algo así como https://your-resource.openai.azure.com/), su clave API y el nombre de la implementación (como gpt-4o). Estos se pasan desde variables de entorno, manteniendo nuestras credenciales seguras.

Elaboración del mensaje perfecto

El mensaje que enviamos a la IA es crucial. Un mensaje bien elaborado produce resultados consistentes y de alta calidad. Una indicación vaga o mal estructurada produce resultados mediocres e inconsistentes. Pasé un tiempo considerable iterando este mensaje para obtener resultados con los que estoy satisfecho:

var prompt = $"""
 You are a professional tech content analyst and LinkedIn content creator.
 Analyze the following Microsoft DevBlogs article and create an engaging LinkedIn post.

 Article Title: {title}
 Author: {author}
 URL: {url}
 Tags: {string.Join(", ", tags)}

 Article Content:
 {cleanContent}

 Please provide:
 1. A brief summary (2-3 sentences) of the key points
 2. The main technologies or topics covered
 3. Why this is relevant for developers/tech professionals
 4. An engaging LinkedIn post (max 1300 characters) that:
 - Starts with a hook or attention-grabbing statement
 - Highlights the key value for readers
 - Includes a call to action
 - Uses appropriate emojis (but not too many)
 - Maintains a professional yet approachable tone
 - DO NOT include hashtags in the post (they will be added separately)
 - DO NOT include the URL in the post (it will be added separately)

 Format your response as follows:
 ## Summary
 [Your summary here]

 ## Key Topics
 [List of main topics/technologies]

 ## Relevance
 [Why this matters]

 ## LinkedIn Post
 [Your engaging LinkedIn post here]
 """;

Permítanme explicar las decisiones de diseño aquí. Comenzamos dándole a la IA un papel claro: “Usted es un analista de contenido tecnológico profesional y un creador de contenido de LinkedIn”. Esto prepara al modelo para responder con el estilo y la voz adecuados.

Proporcionamos todo el contexto que la IA necesita: el título del artículo, el autor, la URL, las etiquetas del canal RSS y el contenido completo del artículo. Cuanto más contexto demos, mejor será el análisis.

Luego especificamos exactamente lo que queremos de vuelta. Pido cuatro cosas: un resumen, temas clave, explicación de relevancia y una publicación en LinkedIn. Específicamente para la publicación de LinkedIn, doy instrucciones detalladas sobre lo que hace que una publicación sea buena: debe tener un gancho, resaltar el valor, incluir un llamado a la acción, usar emojis de manera adecuada y mantener un tono profesional.

Las instrucciones negativas son igualmente importantes. Le digo explícitamente a la IA que NO incluya hashtags ni la URL en la publicación. ¿Por qué? Porque los agrego por separado, y si la IA los incluyera, tendría duplicados. Este tipo de instrucción explícita previene errores comunes.

Finalmente, especifico el formato de salida exacto. Al solicitar secciones marcadas con encabezados ##, hago que la respuesta sea fácil de analizar mediante programación. La IA es muy buena para seguir instrucciones de formato y esta coherencia hace que nuestro código de análisis sea más simple y confiable.

Ejecutando el análisis

Así es como lo armamos todo:

public async Task<ArticleAnalysis> AnalyzeArticleAsync(
 string title,
 string url,
 string htmlContent,
 string author,
 List<string> tags)
{
 var cleanContent = ExtractTextFromHtml(htmlContent);

 if (cleanContent.Length > 8000)
 {
 cleanContent = cleanContent.Substring(0, 8000) + "...";
 }

 var chatHistory = new ChatHistory();
 chatHistory.AddUserMessage(prompt);

 var response = await _chatService.GetChatMessageContentAsync(chatHistory);
 var responseText = response.Content ?? "";

 return ParseAnalysisResponse(responseText, title, url, author, tags);
}
```Primero extraemos texto limpio del contenido HTML (lo explicaré en la siguiente sección). Luego truncamos el contenido si es demasiado largo. Los modelos de lenguaje grandes tienen límites simbólicos y los artículos muy largos pueden excederlos. Al limitar a 8000 caracteres, nos aseguramos de mantenernos dentro de los límites y al mismo tiempo proporcionar un contexto sustancial.

Creamos un objeto ChatHistory y agregamos nuestro mensaje como mensaje de usuario. Esta es la abstracción de Semantic Kernel para interacciones basadas en chat. Enviamos esto al servicio de finalización del chat y recibimos una respuesta. Finalmente, analizamos la respuesta para extraer las secciones individuales.

### Analizando la respuesta de la IA

La IA devuelve su respuesta como texto formateado con nuestra estructura solicitada. Necesitamos analizar esto en campos individuales:

```csharp
private static ArticleAnalysis ParseAnalysisResponse(
 string response,
 string title,
 string url,
 string author,
 List<string> tags)
{
 var analysis = new ArticleAnalysis
 {
 Title = title,
 Url = url,
 Author = author,
 Tags = tags,
 RawAnalysis = response
 };

 var sections = response.Split("##", StringSplitOptions.RemoveEmptyEntries);

 foreach (var section in sections)
 {
 var lines = section.Trim().Split('\n', 2);
 if (lines.Length < 2) continue;

 var sectionTitle = lines[0].Trim().ToLower();
 var sectionContent = lines[1].Trim();

 switch (sectionTitle)
 {
 case "summary":
 analysis.Summary = sectionContent;
 break;
 case "key topics":
 analysis.KeyTopics = sectionContent;
 break;
 case "relevance":
 analysis.Relevance = sectionContent;
 break;
 case "linkedin post":
 analysis.LinkedInPost = sectionContent;
 break;
 }
 }

 return analysis;
}

Dividimos la respuesta por los marcadores ##, lo que nos da cada sección. Para cada sección, dividimos por nueva línea para separar el encabezado del contenido. Luego usamos una declaración de cambio para asignar el contenido de cada sección a la propiedad apropiada.

También almacenamos la respuesta sin procesar y sin analizar. Esto es útil para la depuración: si algo sale mal con el análisis, podemos ver lo que realmente devolvió la IA.

Extracción de contenido de HTML

Por qué necesitamos limpiar HTML

Cuando recuperamos un artículo de un blog, obtenemos el HTML completo de la página. Esto incluye mucho más que solo el contenido del artículo: hay menús de navegación, encabezados, pies de página, barras laterales, widgets de artículos relacionados, secciones de comentarios, secuencias de comandos para análisis y seguimiento, hojas de estilo y todo tipo de otros elementos.

Si enviáramos todo esto a nuestra IA, sucederían varias cosas malas. La IA tendría que procesar una gran cantidad de texto irrelevante, desperdiciando tokens y potencialmente confundiendo el análisis. El texto de navegación y pie de página puede incluirse en el resumen. Los scripts y CSS serían tratados como contenido, contaminando aún más el análisis.

Necesitamos extraer sólo el contenido del artículo, la parte que un lector humano realmente leería.

Usando HtmlAgilityPack

HtmlAgilityPack es una sólida biblioteca de análisis HTML para .NET. A diferencia de XML, HTML a menudo tiene un formato incorrecto: es posible que las etiquetas no estén cerradas correctamente y que los atributos no estén entrecomillados correctamente. HtmlAgilityPack maneja todo esto con gracia, brindándonos una estructura similar a DOM que podemos consultar y manipular.

Aquí está nuestra función de extracción:

private static string ExtractTextFromHtml(string html)
{
 if (string.IsNullOrWhiteSpace(html))
 return string.Empty;

 var doc = new HtmlDocument();
 doc.LoadHtml(html);

 var nodesToRemove = doc.DocumentNode.SelectNodes("//script|//style|//nav|//footer|//header");
 if (nodesToRemove != null)
 {
 foreach (var node in nodesToRemove)
 {
 node.Remove();
 }
 }

 var text = doc.DocumentNode.InnerText;

 text = System.Text.RegularExpressions.Regex.Replace(text, @"\s+", " ");
 return text.Trim();
}

Cargamos el HTML en un HtmlDocument, que lo analiza en una estructura de árbol. Luego usamos XPath para seleccionar todos los nodos que queremos eliminar. La expresión XPath //script|//style|//nav|//footer|//header selecciona todos los elementos de script (código JavaScript que no necesitamos), elementos de estilo (CSS que no necesitamos), elementos de navegación (menús de navegación), elementos de pie de página y elementos de encabezado.

Después de eliminar estos nodos, obtenemos la propiedad InnerText, que extrae todo el contenido del texto mientras elimina las etiquetas HTML. Esto nos da el texto plano del artículo.Finalmente, limpiamos los espacios en blanco. HTML a menudo tiene muchos espacios en blanco adicionales para fines de formato: múltiples espacios, tabulaciones, nuevas líneas. Usamos una expresión regular para reemplazar cualquier secuencia de espacios en blanco con un solo espacio y luego recortamos el resultado.

Obteniendo el artículo completo

La fuente RSS sólo nos proporciona resúmenes, no el contenido completo del artículo. Para obtener el texto completo, debemos buscar la página web del artículo:

public static async Task<string> FetchArticleContentAsync(string url)
{
 using var httpClient = new HttpClient();
 httpClient.DefaultRequestHeaders.Add("User-Agent", "VsFeedLinkedin/1.0");

 try
 {
 return await httpClient.GetStringAsync(url);
 }
 catch (Exception ex)
 {
 Console.WriteLine($"⚠️ Failed to fetch article content: {ex.Message}");
 return string.Empty;
 }
}

Esto es sencillo: realizamos una solicitud HTTP GET a la URL del artículo y devolvemos la respuesta HTML. Lo envolvemos en un try-catch porque las solicitudes de red pueden fallar y preferimos devolver una cadena vacía que bloquear toda la aplicación.

Creando documentación permanente

¿Por qué generar archivos Markdown?

Cada vez que analizamos un artículo, generamos un archivo de rebajas detallado que documenta ese análisis. Esto tiene varios propósitos.

Primero, crea un archivo con capacidad de búsqueda. Con el tiempo, creará una colección de artículos analizados. Puede buscar en estos archivos para encontrar contenido anterior sobre temas específicos.

En segundo lugar, proporciona transparencia. Puede ver exactamente lo que generó la IA para cada artículo, incluido el análisis completo y la publicación de LinkedIn.

En tercer lugar, es útil para depurar. Si algo sale mal con una publicación, puede consultar el archivo de rebajas para comprender qué sucedió.

La clase generadora de rebajas

public class MarkdownGenerator
{
 private readonly string _outputDirectory;

 public MarkdownGenerator(string outputDirectory)
 {
 _outputDirectory = outputDirectory;

 if (!Directory.Exists(_outputDirectory))
 {
 Directory.CreateDirectory(_outputDirectory);
 }
 }

 public string GenerateMarkdownFile(ArticleAnalysis analysis)
 {
 var sb = new StringBuilder();

 var safeTitle = GenerateSafeFileName(analysis.Title);
 var fileName = $"{analysis.AnalyzedAt:yyyy-MM-dd}_{safeTitle}.md";
 var filePath = Path.Combine(_outputDirectory, fileName);

 sb.AppendLine($"# {analysis.Title}");
 sb.AppendLine();
 sb.AppendLine("## Article Information");
 sb.AppendLine();
 sb.AppendLine($"- **Author:** {analysis.Author}");
 sb.AppendLine($"- **URL:** [{analysis.Url}]({analysis.Url})");
 sb.AppendLine($"- **Published:** {analysis.PublishDate:yyyy-MM-dd}");
 sb.AppendLine($"- **Analyzed:** {analysis.AnalyzedAt:yyyy-MM-dd HH:mm:ss}");
 sb.AppendLine($"- **Tags:** {string.Join(", ", analysis.Tags)}");
 sb.AppendLine();
 sb.AppendLine("");
 sb.AppendLine();
 sb.AppendLine("## AI Analysis");
 sb.AppendLine();
 sb.AppendLine("### Summary");
 sb.AppendLine();
 sb.AppendLine(analysis.Summary);
 sb.AppendLine();
 sb.AppendLine("### Key Topics");
 sb.AppendLine();
 sb.AppendLine(analysis.KeyTopics);
 sb.AppendLine();
 sb.AppendLine("### Relevance for Developers");
 sb.AppendLine();
 sb.AppendLine(analysis.Relevance);
 sb.AppendLine();
 sb.AppendLine("");
 sb.AppendLine();
 sb.AppendLine("## Generated LinkedIn Post");
 sb.AppendLine();
 sb.AppendLine("```");
 sb.AppendLine(análisis.LinkedInPost);
 sb.AppendLine("```");
 sb.AppendLine();
 sb.AppendLine("");
 sb.AppendLine();
 sb.AppendLine("*This analysis was generated using AI (Semantic Kernel with Azure OpenAI)*");

 File.WriteAllText(filePath, sb.ToString());
 return filePath;
 }

El constructor toma una ruta del directorio de salida y la crea si no existe. El método GenerateMarkdownFile toma un objeto ArticleAnalysis y produce un documento de rebajas con un formato agradable.

El nombre del archivo incluye la fecha y una versión desinfectada del título. Esto hace que los archivos sean fáciles de ordenar cronológicamente e identificar de un vistazo.

Manejo de nombres de archivos inseguros

Los títulos de los artículos pueden contener caracteres que no están permitidos en los nombres de archivos, como dos puntos, barras diagonales, signos de interrogación y comillas. Necesitamos desinfectar estos:

private static string GenerateSafeFileName(string title)
{
 var invalidChars = Path.GetInvalidFileNameChars();
 var safeTitle = new string(title
 .Where(c => !invalidChars.Contains(c))
 .ToArray());

 safeTitle = safeTitle.Replace(" ", "-").Replace("--", "-");

 if (safeTitle.Length > 50)
 {
 safeTitle = safeTitle.Substring(0, 50);
 }

 return safeTitle.TrimEnd('-').ToLowerInvariant();
}

Usamos Path.GetInvalidFileNameChars() para obtener una lista de caracteres que no pueden aparecer en los nombres de archivos en el sistema operativo actual. Los filtramos, reemplazamos los espacios con guiones para facilitar la lectura, limitamos la longitud a 50 caracteres y los convertimos a minúsculas para mantener la coherencia.

Configuración de notificaciones de Telegram

Por qué elegí Telegram

Para el componente de notificación, consideré varias opciones: correo electrónico, SMS, Slack, Discord y Telegram. Finalmente elegí Telegram por varias razones.

La API es completamente gratuita y no tiene límites de velocidad para un uso razonable. Muchos servicios de notificación tienen límites sobre la cantidad de mensajes que puedes enviar de forma gratuita, pero Telegram no restringe los mensajes de bot a usuarios individuales.

La API del bot es increíblemente simple. Son solo solicitudes HTTP con cargas JSON. No se requieren flujos de autenticación complejos ni webhooks para la funcionalidad básica.Telegram funciona en todas partes: en mi teléfono, en mi escritorio, en mi navegador web. Puedo recibir notificaciones donde quiera que esté y responder de inmediato.

Los mensajes admiten formato enriquecido. Puedo usar texto en negrita, cursiva e incluso bloques de código para que mis notificaciones sean más legibles.

Creando tu bot de Telegram

Configurar un bot de Telegram es sorprendentemente fácil. Abra Telegram y busque @BotFather; este es el bot oficial de Telegram para crear y administrar bots. Inicie una conversación con BotFather y envíe el comando /newbot. BotFather le pedirá un nombre para su bot (este es el nombre para mostrar) y un nombre de usuario (debe ser único y terminar en “bot”). Una vez que los haya proporcionado, BotFather creará su bot y le dará un token API. Este token es como una contraseña: manténgalo en secreto y no lo envíe a repositorios públicos.

Para encontrar su ID de chat para que el bot sepa dónde enviar mensajes, inicie una conversación con su nuevo bot buscándolo y presionando Iniciar. Luego accede a la URL https://api.telegram.org/bot<YOUR_TOKEN>/getUpdates en tu navegador o usando curl. Busque el objeto chat en la respuesta; el campo id es su ID de chat.

Envío de mensajes a través de la API

Aquí está nuestra función para enviar mensajes de Telegram:

static async Task SendToTelegramAsync(string botToken, string chatId, string message)
{
 using var httpClient = new HttpClient();

 var telegramApiUrl = $"https://api.telegram.org/bot{botToken}/sendMessage";

 var payload = new
 {
 chat_id = chatId,
 text = message,
 parse_mode = "HTML"
 };

 var jsonContent = JsonSerializer.Serialize(payload);
 var content = new StringContent(jsonContent, Encoding.UTF8, "application/json");

 var response = await httpClient.PostAsync(telegramApiUrl, content);

 if (!response.IsSuccessStatusCode)
 {
 var errorContent = await response.Content.ReadAsStringAsync();
 throw new Exception($"Telegram API error: {response.StatusCode} - {errorContent}");
 }
}

La API de Telegram Bot está basada en REST. Realizamos una solicitud POST al punto final de sendMessage con un cuerpo JSON que contiene el ID del chat (dónde enviar), el texto del mensaje (qué enviar) y, opcionalmente, un modo de análisis (para formatear).

Configurar parse_mode en “HTML” nos permite usar etiquetas HTML básicas en nuestros mensajes, cosas como <b>bold</b> y <i>italic</i>. Esto puede hacer que las notificaciones sean más legibles, aunque para nuestro caso de uso actual enviamos texto sin formato.

Si la solicitud falla, lanzamos una excepción con detalles sobre lo que salió mal. Esto ayuda con la depuración si algo no funciona.

Configurando la aplicación

Variables de entorno

Nuestra aplicación necesita varios datos confidenciales: claves API, tokens de bot y URL de puntos finales. Nunca deberíamos codificarlos ni comprometerlos con el control de versiones. En su lugar, utilizamos variables de entorno, que se pueden configurar de forma segura en cada entorno donde se ejecuta la aplicación.

Para Telegram, necesitamos TELEGRAM_BOT_TOKEN (el token que te dio BotFather) y TELEGRAM_CHAT_ID (tu ID de chat donde se deben enviar los mensajes).

Para Azure OpenAI, necesitamos AZURE_OPENAI_ENDPOINT (la URL de su recurso), AZURE_OPENAI_API_KEY (su clave API) y AZURE_OPENAI_DEPLOYMENT (el nombre de su modelo implementado, como “gpt-4o”).

Cargando configuración en código

Así es como cargamos estos valores al iniciar la aplicación:

var telegramBotToken = Environment.GetEnvironmentVariable("TELEGRAM_BOT_TOKEN");
var telegramChatId = Environment.GetEnvironmentVariable("TELEGRAM_CHAT_ID");

var azureOpenAiEndpoint = Environment.GetEnvironmentVariable("AZURE_OPENAI_ENDPOINT");
var azureOpenAiKey = Environment.GetEnvironmentVariable("AZURE_OPENAI_API_KEY");
var azureOpenAiDeployment = Environment.GetEnvironmentVariable("AZURE_OPENAI_DEPLOYMENT") ?? "gpt-4o";

var aiAnalysisEnabled = !string.IsNullOrWhiteSpace(azureOpenAiEndpoint) &&
 !string.IsNullOrWhiteSpace(azureOpenAiKey);

Usamos Environment.GetEnvironmentVariable para leer cada valor. Para el nombre de la implementación, proporcionamos un valor predeterminado de “gpt-4o” si no se establece ningún valor.

Luego verificamos si el análisis de IA debe habilitarse verificando que tengamos un punto final y una clave API. Esto permite que la aplicación se ejecute en modo degradado si Azure OpenAI no está configurado; seguirá obteniendo feeds y rastreando artículos, pero sin el análisis de IA.### Degradación elegante

Este concepto de degradación elegante es importante. No queremos que la aplicación falle solo porque una característica opcional no está configurada:

ArticleAnalyzer? articleAnalyzer = null;
MarkdownGenerator? markdownGenerator = null;

if (aiAnalysisEnabled)
{
 Console.WriteLine("🤖 AI Analysis enabled - Using Azure OpenAI with Semantic Kernel");
 articleAnalyzer = new ArticleAnalyzer(azureOpenAiEndpoint!, azureOpenAiKey!, azureOpenAiDeployment);
 markdownGenerator = new MarkdownGenerator(articlesOutputDir);
}
else
{
 Console.WriteLine("ℹ️ AI Analysis disabled - Set AZURE_OPENAI_ENDPOINT and AZURE_OPENAI_API_KEY to enable");
}

Si la IA está habilitada, creamos el analizador y el generador de rebajas. De lo contrario, los dejamos nulos y nos saltamos los pasos relacionados con la IA durante el procesamiento. La aplicación sigue aportando valor al obtener feeds y enviar notificaciones básicas, incluso sin la mejora de la IA.

Automatización con acciones de GitHub

Por qué las acciones de GitHub

El verdadero poder de esta solución proviene de la automatización. No queremos ejecutar la aplicación manualmente cada pocas horas; queremos que se ejecute automáticamente en segundo plano.

GitHub Actions es perfecto para esto. Está integrado en GitHub, por lo que no es necesario configurar ningún servicio adicional. Es gratuito para repositorios públicos e incluye generosos minutos gratuitos para repositorios privados. Puede ejecutarse según una programación, activando nuestra aplicación a intervalos regulares. Tiene gestión de secretos incorporada para almacenar nuestras claves API de forma segura. Y puede enviar los cambios al repositorio, manteniendo nuestro archivo de seguimiento actualizado.

El archivo de flujo de trabajo

Cree un archivo en .github/workflows/fetch-and-notify.yml con el siguiente contenido:

name: Fetch DevBlogs and Notify

on:
 schedule:
 - cron: '0 */6 * * *'
 workflow_dispatch:

jobs:
 fetch-and-notify:
 runs-on: ubuntu-latest

 steps:
 - name: Checkout repository
 uses: actions/checkout@v4

 - name: Setup .NET
 uses: actions/setup-dotnet@v4
 with:
 dotnet-version: '9.0.x'

 - name: Restore dependencies
 run: dotnet restore src/VsFeedLinkedin.csproj

 - name: Build
 run: dotnet build src/VsFeedLinkedin.csproj --no-restore

 - name: Run application
 env:
 TELEGRAM_BOT_TOKEN: ${{ secrets.TELEGRAM_BOT_TOKEN }}
 TELEGRAM_CHAT_ID: ${{ secrets.TELEGRAM_CHAT_ID }}
 AZURE_OPENAI_ENDPOINT: ${{ secrets.AZURE_OPENAI_ENDPOINT }}
 AZURE_OPENAI_API_KEY: ${{ secrets.AZURE_OPENAI_API_KEY }}
 AZURE_OPENAI_DEPLOYMENT: ${{ secrets.AZURE_OPENAI_DEPLOYMENT }}
 run: dotnet run --project src/VsFeedLinkedin.csproj

 - name: Commit and push changes
 run: |
 git config user.name "GitHub Actions Bot"
 git config user.email "actions@github.com"

 if [[ -n $(git status --porcelain posted-articles.md generated-posts/) ]]; then
 TIMESTAMP=$(date +%Y%m%d_%H%M%S)
 git add posted-articles.md generated-posts/
 git commit -m "chore($TIMESTAMP): processed new articles"
 git push
 else
 echo "No changes to commit"
 fi

Déjame explicarte cada parte. La sección on define cuándo se ejecuta el flujo de trabajo. El activador de programación utiliza la sintaxis cron: 0 */6 * * * significa “en el minuto 0 de cada sexta hora”. Por lo tanto, el flujo de trabajo se ejecuta a medianoche, a las 6 a. m., al mediodía y a las 6 p. m. UTC. El activador flujo de trabajo_dispatch permite ejecuciones manuales desde la interfaz de usuario de GitHub, lo cual es útil para realizar pruebas.

El trabajo se ejecuta en ubuntu-latest, que es una máquina virtual Linux. Revisamos nuestro repositorio, configuramos .NET 9, restauramos paquetes NuGet y compilamos el proyecto.

El paso Ejecutar aplicación es donde ocurre la magia. Pasamos nuestros secretos como variables de entorno usando la sintaxis ${{ secrets.SECRET_NAME }}. Estos secretos se almacenan de forma segura en GitHub y nunca se exponen en los registros.

Finalmente, confirmamos cualquier cambio en el repositorio. Configuramos Git con una identidad de bot, verificamos si hay algún cambio en nuestro archivo de seguimiento o directorio de publicaciones generadas y, de ser así, creamos una confirmación y la enviamos.

Configuración de secretos

Para agregar secretos a su repositorio de GitHub, vaya a Configuración de su repositorio, luego Secretos y variables, luego Acciones. Haga clic en “Nuevo secreto del repositorio” y agregue cada una de sus variables de entorno. Los nombres deben coincidir exactamente con lo que hacemos referencia en el archivo de flujo de trabajo.

Concluyendo

Lo que hemos construido

Mirando hacia atrás en todo lo que hemos cubierto, hemos creado un agregador de feeds RSS integral impulsado por IA que automatiza lo que solía ser un proceso manual tedioso. La aplicación monitorea automáticamente siete feeds de Microsoft DevBlogs y detecta cada artículo nuevo tan pronto como se publica. Maneja las complejidades de la deduplicación y reconoce cuando el mismo artículo aparece en varios feeds.El análisis de IA impulsado por Semantic Kernel y Azure OpenAI lee y comprende el contenido de los artículos, genera resúmenes, identifica temas clave y explica la relevancia, todo de forma automática. Lo más importante es que crea publicaciones atractivas en LinkedIn que puedo compartir con una edición mínima.

La integración de Telegram significa que recibo notificaciones en mi teléfono cada vez que hay contenido nuevo para revisar. Puedo echar un vistazo al mensaje, decidir si quiero compartirlo y actuar de inmediato.

Y debido a que se ejecuta en GitHub Actions según un cronograma, no tengo que acordarme de hacer nada. El sistema funciona en segundo plano y solo participo cuando hay algo que vale la pena compartir.

Las tecnologías que lo hicieron posible

Este proyecto reunió varias tecnologías y cada una de ellas desempeñó un papel crucial. .NET 9 proporcionó una base sólida con sus características de lenguaje moderno y su excelente rendimiento. Semantic Kernel simplificó la integración de la IA, manejando toda la complejidad de las llamadas API y la gestión de respuestas. Azure OpenAI proporcionó la inteligencia: la capacidad de comprender y analizar contenido técnico. HtmlAgilityPack resolvió el complicado problema de extraer texto limpio de páginas web. System.ServiceModel.Syndication hizo que el análisis de RSS fuera muy sencillo. La API de Telegram Bot nos brindó notificaciones confiables y gratuitas. Y GitHub Actions lo vinculó todo con una ejecución automatizada y programada.

Pensando en los costos

Una pregunta que podría tener es: ¿cuánto cuesta ejecutar esto? La respuesta es: no mucho en absoluto.

Telegram es completamente gratuito: no hay cargos por enviar mensajes a través de tu bot.

GitHub Actions es gratuito para repositorios públicos. Para los repositorios privados, obtienes 2000 minutos por mes en el nivel gratuito, lo cual es más que suficiente para nuestro caso de uso.

Azure OpenAI es el único componente pago y los costos son mínimos. Con GPT-4o, analizar un artículo de blog típico cuesta entre uno y tres centavos. Incluso si procesa docenas de artículos por mes, obtendrá menos de un dólar en costos de IA.

¿Dónde podrías llevar esto a continuación?

Si bien esta solución funciona muy bien para mis necesidades, hay muchas formas de ampliarla. Podrías agregar soporte para múltiples plataformas sociales, tal vez publicar en Twitter/X, Mastodon o Bluesky además de LinkedIn. Podría implementar un análisis de sentimiento para rastrear el tono de los artículos a lo largo del tiempo y detectar tendencias. Podrías permitir diferentes plantillas de mensajes para diferentes feeds, generando diferentes estilos de publicaciones para diferentes temas. Podrías crear un panel web para revisar y administrar publicaciones en lugar de usar Telegram. Puede realizar un seguimiento de las métricas de participación del contenido publicado para ver qué temas resuenan más en su audiencia.

Pensamientos finalesLo que más me gusta de este proyecto es que encarna una filosofía en la que creo firmemente: la automatización debe encargarse de las partes tediosas y dejar las partes creativas y de toma de decisiones a los humanos. El sistema hace todo el trabajo duro (buscar, analizar, generar), pero aún así reviso todo antes de compartirlo. Las publicaciones generadas por IA son puntos de partida que puedo personalizar y personalizar.

Al combinar el poder de .NET, Semantic Kernel y Azure OpenAI, hemos creado una herramienta que ahorra horas de trabajo manual cada semana mientras mantiene la calidad y la coherencia. Es el tipo de automatización práctica que marca una diferencia real en la vida diaria.

Si construyes algo similar o tienes ideas para mejorar, me encantaría saberlo. ¡No dudes en comunicarte con LinkedIn!

¡Feliz codificación y feliz Navidad! 🎄

Creación de sistemas de IA multiagente con el marco de agentes de Microsoft

Mon, 01 Dec 2025 00:00:00 +0000

Introducción

Hemos entrado en la era de los sistemas de IA multiagente. En lugar de una única IA monolítica que se encargue de todo, la industria está avanzando hacia agentes especializados que colaboran para resolver problemas complejos, muy parecidos a un equipo de expertos bien organizado. Un agente investiga, otro analiza, un tercero escribe y un coordinador mantiene a todos al día.

Si ha trabajado con modelos de lenguaje grandes, probablemente haya llegado al límite de lo que puede hacer un solo mensaje. Las ventanas contextuales se llenan, las instrucciones se confunden y la calidad se degrada. Las arquitecturas multiagente resuelven esto descomponiendo tareas complejas en responsabilidades enfocadas, donde cada agente es un experto en una cosa.

Agent Framework de Microsoft, parte del ecosistema más amplio de Semantic Kernel, ofrece a los desarrolladores de .NET un conjunto de herramientas de primera clase para construir exactamente este tipo de sistemas. En esta publicación, pasaremos de cero a una canalización multiagente completamente funcional, cubriendo los conceptos centrales, los patrones de orquestación y el código práctico que necesita para comenzar.

¿Qué es el marco de agentes de Microsoft?

Agent Framework es la respuesta de Microsoft para crear, orquestar e implementar agentes de IA y sistemas multiagente en .NET. Se ubica junto al Semantic Kernel, que ha sido el SDK de código abierto de Microsoft para la orquestación de IA desde 2023, y se integra profundamente con él.

Piénselo de esta manera: Semantic Kernel le brinda las primitivas (kernels, complementos, memoria, planificadores), mientras que Agent Framework le brinda abstracciones de nivel superior diseñadas específicamente para la comunicación y coordinación de agente a agente.

El marco admite múltiples proveedores de modelos, incluidos Azure OpenAI, OpenAI y modelos alojados en Azure AI Foundry. Su diseño es independiente del modelo pero está profundamente integrado con el ecosistema de Azure, lo que lo hace particularmente atractivo para escenarios empresariales.

Las capacidades clave incluyen:

Múltiples tipos de agentes: ChatCompletionAgent, OpenAIAssistantAgent y AzureAIAgent para diferentes backends
Patrones de orquestación: flujos de trabajo secuenciales, simultáneos, de transferencia y de chat grupal
Ecosistema de complementos: amplíe los agentes con funciones nativas de C#, especificaciones de OpenAPI y herramientas de protocolo de contexto de modelo (MCP).
Gestión de conversaciones: estrategias integradas de subprocesamiento, gestión de historial y terminación
Observabilidad: integración con OpenTelemetry para rastrear interacciones de agentes

Conceptos clave

Antes de escribir cualquier código, establezcamos el vocabulario. El Agent Framework gira en torno a algunas abstracciones centrales.

Agentes

Un agente es una entidad respaldada por un modelo de IA, configurada con instrucciones específicas (un mensaje del sistema), un nombre y, opcionalmente, un conjunto de complementos o herramientas. Cada agente es un especialista: usted define lo que sabe, lo que puede hacer y cómo debe comportarse.

Agente de finalización de chatEl tipo de agente más sencillo. Incluye un punto final de finalización de chat (Azure OpenAI, OpenAI, etc.) y mantiene una conversación. No tiene estado entre invocaciones: usted proporciona el historial y responde. Esto lo hace liviano y fácil de razonar.

ChatCompletionAgent agent = new()
{
 Name = "Reviewer",
 Instructions = "You are a senior code reviewer. Analyze the provided code for bugs, security issues, and style violations. Be concise and actionable.",
 Kernel = kernel
};

Agente Asistente de OpenAIA

Este tipo de agente aprovecha la API de OpenAI Assistants, que proporciona estado de conversación del lado del servidor, manejo de archivos e interpretación de código. Es más pesado pero le brinda subprocesos persistentes y herramientas integradas como intérprete de código y búsqueda de archivos.

OpenAIAssistantAgent agent = await OpenAIAssistantAgent.CreateAsync(
 clientProvider: clientProvider,
 definition: new OpenAIAssistantDefinition("gpt-4o")
 {
 Name = "DataAnalyst",
 Instructions = "You analyze datasets and produce statistical summaries."
 }
);

Chat en grupo de agentes

Este es el orquestador. AgentGroupChat administra conversaciones de varios turnos entre múltiples agentes, controlando quién habla a continuación, cuándo termina la conversación y cómo se comparte el historial. Aquí es donde ocurre la magia de la colaboración entre múltiples agentes.

Patrones de orquestación

El marco admite cuatro patrones de orquestación principales, cada uno de ellos adecuado para diferentes problemas.

Secuencial

Los agentes se ejecutan uno tras otro en un orden definido. La salida del Agente A alimenta al Agente B, cuya salida alimenta al Agente C. Esto es ideal para canalizaciones: borrador → revisar → editar → publicar.

// Conceptual flow
var draft = await writerAgent.InvokeAsync("Write a blog post about .NET 9");
var reviewed = await reviewerAgent.InvokeAsync($"Review this: {draft}");
var edited = await editorAgent.InvokeAsync($"Edit based on feedback: {reviewed}");

Concurrente

Varios agentes trabajan en la misma entrada simultáneamente. Distribuyes el trabajo y luego agregas los resultados. Excelente para obtener diversas perspectivas, como que tres revisores observen la misma solicitud de extracción.

Traspaso

Un agente decide transferir el control a otro agente según el contexto de la conversación. Esto imita cómo funciona un equipo de servicio al cliente: el agente de primera línea maneja consultas básicas y las deriva a especialistas cuando es necesario.

Chat grupal

Varios agentes participan en una conversación abierta, turnándose según una estrategia de selección. La clase AgentGroupChat implementa este patrón con lógica configurable de toma de turnos y terminación.

Construyendo su primer agente

Seamos prácticos. A continuación le mostramos cómo crear su primer agente paso a paso.

Requisitos previos

Necesitarás:

SDK .NET 9
Un recurso de Azure OpenAI con un modelo implementado (por ejemplo, gpt-4o)
Visual Studio o código VS

Configuración del proyecto

Cree una nueva aplicación de consola e instale los paquetes necesarios:

dotnet new console -n AgentDemo
cd AgentDemo
dotnet add package Microsoft.SemanticKernel --prerelease
dotnet add package Microsoft.SemanticKernel.Agents.Core --prerelease
dotnet add package Azure.AI.OpenAI
dotnet add package Azure.Identity

Creando un agente simple

Primero, configure el kernel con su configuración de Azure OpenAI:

using Azure.Identity;
using Microsoft.SemanticKernel;
using Microsoft.SemanticKernel.Agents;
using Microsoft.SemanticKernel.ChatCompletion;

var builder = Kernel.CreateBuilder();

builder.AddAzureOpenAIChatCompletion(
 deploymentName: "gpt-4o",
 endpoint: "https://your-resource.openai.azure.com/",
 credentials: new DefaultAzureCredential()
);

Kernel kernel = builder.Build();

Ahora crea un agente e invocalo:

ChatCompletionAgent agent = new()
{
 Name = "TechWriter",
 Instructions = """
 You are a technical writer specializing in software documentation.
 Write clear, concise content aimed at experienced developers.
 Use code examples when appropriate.
 Always structure your output with headings and bullet points.
 """,
 Kernel = kernel
};

ChatHistory history = new();
history.AddUserMessage("Explain dependency injection in .NET in 200 words.");

await foreach (ChatMessageContent response in agent.InvokeAsync(history))
{
 Console.WriteLine(response.Content);
}

Eso es todo. Tienes un agente de trabajo. Pero el verdadero poder surge cuando los agentes trabajan juntos.

Orquestación multiagente con AgentGroupChat

Construyamos algo más interesante: un chat grupal donde colaboran varios agentes. La clase AgentGroupChat administra el flujo de la conversación, incluido quién habla a continuación y cuándo detenerse.

Definición de los agentes

Crearemos tres agentes: un escritor, un revisor y un editor.

ChatCompletionAgent writer = new()
{
 Name = "Writer",
 Instructions = """
 You are a content writer. When given a topic, produce a well-structured
 draft. Focus on clarity and technical accuracy.
 When you receive feedback from the Reviewer, incorporate it into a
 revised draft.
 """,
 Kernel = kernel
};

ChatCompletionAgent reviewer = new()
{
 Name = "Reviewer",
 Instructions = """
 You are a content reviewer. Analyze drafts for technical accuracy,
 clarity, and completeness. Provide specific, actionable feedback.
 Do NOT rewrite the content — only provide feedback.
 When the content meets your standards, respond with: APPROVED
 """,
 Kernel = kernel
};

ChatCompletionAgent editor = new()
{
 Name = "Editor",
 Instructions = """
 You are an editor. Once content is approved by the Reviewer,
 polish it for grammar, tone, and formatting.
 Output only the final polished version.
 When you have produced the final version, respond with: COMPLETE
 """,
 Kernel = kernel
};

Configurar el chat grupal

El AgentGroupChat necesita dos configuraciones clave: una estrategia de selección (quién habla a continuación) y una estrategia de terminación (cuándo detenerse).

AgentGroupChat chat = new(writer, reviewer, editor)
{
 ExecutionSettings = new()
 {
 SelectionStrategy = new SequentialSelectionStrategy(),
 TerminationStrategy = new ApprovalTerminationStrategy()
 {
 Agents = [editor],
 MaximumIterations = 12
 }
 }
};

Estrategia de terminación personalizadaLa estrategia de terminación define cuándo termina la conversación. Aquí hay uno personalizado que busca la palabra clave “COMPLETO”:

class ApprovalTerminationStrategy : TerminationStrategy
{
 protected override Task<bool> ShouldAgentTerminateAsync(
 Agent agent,
 IReadOnlyList<ChatMessageContent> history,
 CancellationToken cancellationToken = default)
 {
 bool isComplete = history
 .Last()
 .Content?
 .Contains("COMPLETE", StringComparison.OrdinalIgnoreCase) ?? false;

 return Task.FromResult(isComplete);
 }
}

Ejecutar la conversación

Inicie la conversación con un mensaje de usuario y deje que los agentes colaboren:

chat.AddChatMessage(
 new ChatMessageContent(AuthorRole.User,
 "Write a 300-word technical overview of gRPC vs REST for microservices.")
);

await foreach (ChatMessageContent message in chat.InvokeAsync())
{
 Console.WriteLine($"[{message.AuthorName}]: {message.Content}");
 Console.WriteLine("---");
}

El flujo se verá así:

El escritor produce un borrador
El revisor proporciona comentarios
El escritor revisa según los comentarios
El revisor dice “APROBADO”
Editor pule y dice “COMPLETO”
La conversación termina

Este ida y vuelta continúa automáticamente hasta que se cumple la condición de terminación o se alcanza MaximumIterations.

Complementos y herramientas

Los agentes se vuelven verdaderamente poderosos cuando pueden interactuar con sistemas externos. Agent Framework admite tres mecanismos de extensión principales.

Funciones nativas (complementos del kernel)

Puede dar a los agentes acceso a métodos de C# como herramientas. El agente llamará a estas funciones cuando determine que son necesarias:

public class ContentToolsPlugin
{
 [KernelFunction("word_count")]
 [Description("Counts the number of words in the provided text.")]
 public int WordCount([Description("The text to count words in")] string text)
 {
 return text.Split(' ', StringSplitOptions.RemoveEmptyEntries).Length;
 }

 [KernelFunction("check_readability")]
 [Description("Calculates a readability score for the given text.")]
 public string CheckReadability([Description("The text to analyze")] string text)
 {
 var words = text.Split(' ', StringSplitOptions.RemoveEmptyEntries).Length;
 var sentences = text.Split(['.', '!', '?'], StringSplitOptions.RemoveEmptyEntries).Length;

 if (sentences == 0) return "Unable to calculate — no sentences found.";

 double avgWordsPerSentence = (double)words / sentences;

 return avgWordsPerSentence switch
 {
 < 15 => $"Easy to read (avg {avgWordsPerSentence:F1} words/sentence)",
 < 25 => $"Moderate difficulty (avg {avgWordsPerSentence:F1} words/sentence)",
 _ => $"Difficult to read (avg {avgWordsPerSentence:F1} words/sentence). Consider shorter sentences."
 };
 }
}

Registre el complemento en el kernel antes de crear el agente:

kernel.Plugins.AddFromType<ContentToolsPlugin>();

ChatCompletionAgent analyst = new()
{
 Name = "ContentAnalyst",
 Instructions = "Analyze content using available tools. Report word count and readability.",
 Kernel = kernel,
 Arguments = new KernelArguments(
 new PromptExecutionSettings
 {
 FunctionChoiceBehavior = FunctionChoiceBehavior.Auto()
 })
};

Protocolo de contexto modelo (MCP)

MCP es un estándar abierto para conectar modelos de IA a herramientas y fuentes de datos externas. Agent Framework es compatible con MCP, lo que significa que sus agentes pueden usar herramientas expuestas por cualquier servidor compatible con MCP. Esto abre la puerta a sistemas de archivos, bases de datos, API y más, todo a través de una interfaz estandarizada.

// Example: Adding an MCP server for file operations
kernel.Plugins.AddFromMcpServer("filesystem",
 new Uri("http://localhost:3000/mcp"));

Esto es particularmente interesante porque significa que sus agentes no están limitados a lo que usted crea: pueden aprovechar un ecosistema de herramientas MCP que otros desarrollan y comparten.

Ejemplo del mundo real: canal de revisión de contenido

Juntemos todo con un escenario práctico. Imagine que está creando una herramienta interna que automatiza la revisión de contenido para un equipo de documentación. El oleoducto tiene cuatro etapas:

Investigador: recopila información técnica relevante
Escritor: produce un borrador basado en una investigación.
Revisor: verifica la precisión y la integridad
Editor: formatea y prepara el resultado final.

Aquí hay una implementación condensada:

using Azure.Identity;
using Microsoft.SemanticKernel;
using Microsoft.SemanticKernel.Agents;
using Microsoft.SemanticKernel.ChatCompletion;

// Build the kernel
var builder = Kernel.CreateBuilder();
builder.AddAzureOpenAIChatCompletion(
 deploymentName: "gpt-4o",
 endpoint: "https://your-resource.openai.azure.com/",
 credentials: new DefaultAzureCredential()
);
Kernel kernel = builder.Build();

// Define specialized agents
ChatCompletionAgent researcher = new()
{
 Name = "Researcher",
 Instructions = """
 You are a technical researcher. Given a topic, identify the key
 concepts, recent developments, and important details that should
 be covered. Output a structured research brief.
 """,
 Kernel = kernel
};

ChatCompletionAgent writer = new()
{
 Name = "Writer",
 Instructions = """
 You are a technical writer. Using the research brief provided,
 write a comprehensive, well-structured article. Include code
 examples where relevant. Target audience: experienced developers.
 """,
 Kernel = kernel
};

ChatCompletionAgent reviewer = new()
{
 Name = "Reviewer",
 Instructions = """
 You are a senior technical reviewer. Check the article for:
 - Technical accuracy
 - Completeness relative to the research brief
 - Code correctness
 - Clarity and structure
 If everything looks good, respond with APPROVED.
 Otherwise, provide specific feedback for revision.
 """,
 Kernel = kernel
};

ChatCompletionAgent publisher = new()
{
 Name = "Publisher",
 Instructions = """
 You are a content publisher. Once the article is approved,
 format it with proper markdown, add a summary at the top,
 and ensure consistent formatting throughout.
 End your response with COMPLETE.
 """,
 Kernel = kernel
};

// Configure the group chat
AgentGroupChat chat = new(researcher, writer, reviewer, publisher)
{
 ExecutionSettings = new()
 {
 SelectionStrategy = new SequentialSelectionStrategy(),
 TerminationStrategy = new ApprovalTerminationStrategy()
 {
 Agents = [publisher],
 MaximumIterations = 15
 }
 }
};

// Start the pipeline
chat.AddChatMessage(new ChatMessageContent(
 AuthorRole.User,
 "Create a technical article about implementing health checks in ASP.NET Core microservices."
));

await foreach (ChatMessageContent message in chat.InvokeAsync())
{
 Console.ForegroundColor = message.AuthorName switch
 {
 "Researcher" => ConsoleColor.Cyan,
 "Writer" => ConsoleColor.Green,
 "Reviewer" => ConsoleColor.Yellow,
 "Publisher" => ConsoleColor.Magenta,
 _ => ConsoleColor.White
 };

 Console.WriteLine($"\n{'='new string('=', 60)}");
 Console.WriteLine($"[{message.AuthorName}]");
 Console.WriteLine(new string('=', 60));
 Console.WriteLine(message.Content);
}

Console.ResetColor();

Este canal produce un artículo completamente investigado, escrito, revisado y formateado, todo ello a través de la colaboración de los agentes. Cada agente se centra en lo que mejor sabe hacer y el AgentGroupChat coordina el flujo de trabajo.

Mejores prácticas

Después de construir varios sistemas multiagente, estos son los patrones y prácticas que he encontrado más valiosos.

Manejo de errores

Configure siempre MaximumIterations en su estrategia de terminación. Sin él, los agentes pueden entrar en bucles infinitos, especialmente cuando un revisor sigue encontrando problemas y un escritor sigue revisando sin mejorar.

TerminationStrategy = new ApprovalTerminationStrategy()
{
 MaximumIterations = 12 // Safety net
}

Envuelva las invocaciones de su agente en bloques try-catch. Los límites de velocidad de API, los problemas de red y los errores de modelo son realidades de los sistemas de producción:

try
{
 await foreach (var message in chat.InvokeAsync(cancellationToken))
 {
 // Process messages
 }
}
catch (HttpOperationException ex) when (ex.StatusCode == System.Net.HttpStatusCode.TooManyRequests)
{
 // Implement retry with exponential backoff
 await Task.Delay(TimeSpan.FromSeconds(30), cancellationToken);
}

ObservabilidadAgent Framework se integra con OpenTelemetry, lo que significa que puede rastrear cada interacción del agente, llamada de herramienta y uso de token. Esto es esencial para depurar flujos de trabajo de múltiples agentes donde no siempre es obvio qué agente causó un problema.

Configure la telemetría básica agregando los paquetes de telemetría del Kernel Semántico y configurando su exportador preferido (Application Insights, Jaeger, etc.):

builder.Services.AddOpenTelemetry()
 .WithTracing(tracing =>
 {
 tracing.AddSource("Microsoft.SemanticKernel*");
 tracing.AddOtlpExporter();
 });

Gestión de costes

Los sistemas multiagente multiplican los costos de API: cada turno de agente es una llamada de API y los chats grupales pueden generar muchos turnos. Algunas estrategias para mantener los costos bajo control:

Utilice modelos más económicos para agentes más simples: No todos los agentes necesitan GPT-4o. Un revisor podría funcionar bien con un modelo más pequeño, mientras que sólo el escritor necesita el peso pesado.
Limitar historial: use ReducedHistoryCount en su configuración de ejecución para limitar la cantidad de contexto de conversación que recibe cada agente.
Establezca límites estrictos de iteración: evite conversaciones descontroladas con valores MaximumIterations razonables.
Almacenar en caché cuando sea posible: si un agente realiza la misma búsqueda repetidamente, almacene en caché los resultados en un complemento.

Diseño de agente

Mantenga las instrucciones enfocadas: Cada agente debe tener una responsabilidad única y clara. Las instrucciones amplias conducen a un rendimiento mediocre en todas las tareas.
Sea explícito sobre el formato de salida: dígales a los agentes exactamente cómo estructurar sus respuestas. Esto hace que el análisis posterior sea confiable.
Utilice palabras clave de terminación: defina señales claras (como “APROBADO” o “COMPLETO”) que los agentes utilizan para indicar que han terminado. Esto hace que las estrategias de terminación sean simples y predecibles.

Conclusión

Los sistemas de IA multiagente representan un cambio fundamental en la forma en que creamos aplicaciones inteligentes. En lugar de luchar con un único mensaje para manejar todo, podemos descomponer los problemas en roles especializados y dejar que los agentes colaboren.

Agent Framework de Microsoft hace que esto sea práctico para los desarrolladores de .NET. Las abstracciones son claras (agentes, chats grupales, estrategias de selección y terminación) y se componen de forma natural. Combinado con el ecosistema de complementos de Semantic Kernel y el alojamiento de modelos de Azure, tiene una pila completa para crear sistemas multiagente de nivel de producción.

El marco aún está evolucionando (muchos paquetes están en versión preliminar), pero los patrones centrales son sólidos y la dirección es clara. Si está creando aplicaciones basadas en IA en .NET, ahora es el momento de comenzar a experimentar con arquitecturas multiagente.

Empiece poco a poco: cree dos agentes que colaboren en una tarea sencilla. Una vez que vea la mejora de la calidad con respecto a los enfoques de un solo agente, querrá descomponer todo en equipos de agentes.

¡Feliz codificación!

Representación de HTML sin formato en Blazor con MarkupString

Sat, 22 Nov 2025 00:00:00 +0000

El otro día estaba creando un componente que necesitaba representar HTML procedente de un CMS. Tenía la cadena HTML en una variable y la solté en la plantilla como @myHtml. Y, por supuesto, Blazor escapó de todo y representó las etiquetas reales como texto en la página. No es lo que quería.

El problema

De forma predeterminada, Blazor codifica cualquier cadena que represente en una plantilla. Entonces si tienes:

@code {
 private string content = "<strong>Hello</strong> <em>world</em>";
}

Y haces esto:

<div>@content</div>

Verás el texto literal <strong>Hello</strong> <em>world</em> en la página en lugar de Hola mundo. Blazor hace esto a propósito para evitar ataques XSS, que es el comportamiento predeterminado correcto.

La solución: MarkupString

Si realmente necesita representar HTML sin formato, envuelva su cadena en un MarkupString:

<div>@((MarkupString)content)</div>

¡Y eso es todo! Ahora Blazor representará el HTML como marcado real. También puedes asignarlo a una variable:

@code {
 private string rawHtml = "<strong>Hello</strong> <em>world</em>";
 private MarkupString HtmlContent => (MarkupString)rawHtml;
}

<div>@HtmlContent</div>

Un ejemplo del mundo real

Estaba extrayendo contenido del blog desde una API y necesitaba representarlo en un componente de vista previa. El contenido tenía todo tipo de HTML: encabezados, bloques de código, enlaces, imágenes. Esto es aproximadamente cómo se veía:

@inject HttpClient Http

@if (article is not null)
{
 <article>
 <h1>@article.Title</h1>
 <div class="content">
 @((MarkupString)article.HtmlBody)
 </div>
 </article>
}

@code {
 [Parameter]
 public int ArticleId { get; set; }

 private ArticleDto? article;

 protected override async Task OnInitializedAsync()
 {
 article = await Http.GetFromJsonAsync<ArticleDto>($"api/articles/{ArticleId}");
 }
}

Funciona perfectamente. El HTML de la API se representa como marcado real.

Tenga cuidado con el contenido que no es de confianza

Esto es importante: MarkupString no desinfecta el HTML. Representa todo lo que le das, incluidas las etiquetas <script>. Entonces, si el contenido proviene de la entrada del usuario o de una fuente que no es confiable, primero debe desinfectarlo.

No hay un desinfectante HTML integrado en Blazor, pero puedes usar una biblioteca como HtmlSanitizer:

using Ganss.Xss;

@code {
 private HtmlSanitizer sanitizer = new();

 private MarkupString SafeHtml(string html)
 {
 var clean = sanitizer.Sanitize(html);
 return (MarkupString)clean;
 }
}

<div>@SafeHtml(untrustedContent)</div>

Esto elimina elementos peligrosos como <script>, onclick controladores y otras cosas que no quieres que se muestren en el contenido proporcionado por el usuario.

Cuando usarlo

Utilizo MarkupString para:

Contenido CMS o rebajas que se han convertido a HTML del lado del servidor
Salida del editor de texto enriquecido
Vista previa de plantillas de correo electrónico
Cualquier HTML prediseñado de fuentes confiables

Para cualquier cosa que provenga de la entrada del usuario, siempre desinfecte primero. Más vale prevenir que lamentar.

Espero que os haya gustado el post! No dudes en contactarme en cualquier red social en @emimontesdeoca.

Recursos

Novedades de EF Core 9: las funciones que necesita conocer

Tue, 18 Nov 2025 00:00:00 +0000

Entity Framework Core 9 se lanzó junto con .NET 9 en noviembre de 2024 y, después de dedicar una gran cantidad de tiempo a trabajar con él en varios proyectos, puedo decir que es uno de los lanzamientos más significativos en mucho tiempo. No porque reinvente la rueda, sino porque pule las áreas donde EF Core históricamente ha causado la mayor fricción: traducción de consultas, rendimiento y trabajo con patrones de datos modernos.

En esta publicación, analizaré las funciones que han tenido el mayor impacto en mi trabajo diario. Si todavía estás en EF Core 8 (o incluso 7), esto debería darte una idea clara de lo que te espera al otro lado de la actualización.

EF Core 9 en el ecosistema .NET 9

EF Core 9 está dirigido a .NET 8 y .NET 9, lo que significa que no necesariamente necesita actualizar toda su aplicación a .NET 9 para aprovechar la mayoría de estas características. Dicho esto, algunas de las mejoras de rendimiento y AOT están estrechamente relacionadas con los cambios en el tiempo de ejecución de .NET 9, por lo que aprovechará al máximo si llega hasta el final.

El lanzamiento sigue la cadencia par/impar que Microsoft ha establecido: las versiones impares (como .NET 9) son soporte a plazo estándar (STS) con 18 meses de soporte, mientras que las versiones pares (como .NET 8) son soporte a largo plazo (LTS). Tenga esto en cuenta al planificar el cronograma de actualización.

Mejoras en la traducción de LINQ

Aquí es donde la mayoría de los desarrolladores sentirán la diferencia inmediatamente. EF Core 9 ha logrado avances significativos en la traducción de expresiones LINQ a SQL que realmente tienen sentido.

Mejores traducciones GroupBy

Si alguna vez escribió una consulta GroupBy en EF Core y terminó con advertencias de evaluación del lado del cliente o SQL extraño, conoce el problema. EF Core 9 maneja un conjunto mucho más amplio de GroupBy escenarios directamente en SQL.

var salesByCategory = await context.Products
 .GroupBy(p => p.Category.Name)
 .Select(g => new
 {
 Category = g.Key,
 TotalRevenue = g.Sum(p => p.Price * p.UnitsSold),
 AveragePrice = g.Average(p => p.Price),
 ProductCount = g.Count()
 })
 .OrderByDescending(x => x.TotalRevenue)
 .ToListAsync();

En versiones anteriores, las consultas que involucraban agregaciones sobre propiedades de navegación dentro de GroupBy a veces recurrían a la evaluación del cliente. EF Core 9 traduce esto claramente a una única consulta SQL con GROUP BY, SUM, AVG y COUNT.

Proyecciones y subconsultas complejas

Las subconsultas anidadas y las proyecciones complejas también obtuvieron una importante actualización. Considere algo como esto:

var orderSummaries = await context.Customers
 .Select(c => new CustomerSummaryDto
 {
 Name = c.FullName,
 TotalOrders = c.Orders.Count(),
 MostRecentOrder = c.Orders
 .OrderByDescending(o => o.OrderDate)
 .Select(o => new OrderBriefDto
 {
 Id = o.Id,
 Date = o.OrderDate,
 Total = o.LineItems.Sum(li => li.Quantity * li.UnitPrice)
 })
 .FirstOrDefault(),
 TopCategory = c.Orders
 .SelectMany(o => o.LineItems)
 .GroupBy(li => li.Product.Category.Name)
 .OrderByDescending(g => g.Count())
 .Select(g => g.Key)
 .FirstOrDefault()
 })
 .ToListAsync();

EF Core 9 ahora puede traducir esta expresión completa a SQL sin activar la evaluación del lado del cliente. La consulta generada utiliza subconsultas correlacionadas y uniones laterales cuando corresponde, y el plan SQL es considerablemente más eficiente que el que producirían versiones anteriores.

Colecciones primitivas parametrizadas

Una de las mejoras destacadas de LINQ es la capacidad de pasar colecciones de valores primitivos directamente a consultas:

var statusFilter = new List<string> { "Active", "Pending", "Review" };

var filteredOrders = await context.Orders
 .Where(o => statusFilter.Contains(o.Status))
 .ToListAsync();

En EF Core 8, esto se tradujo mediante cláusulas IN con valores insertados, lo que significaba que la caché del plan de consulta no se podía reutilizar cuando la lista cambiaba. EF Core 9 parametriza estas colecciones correctamente y las envía como un parámetro estructurado. Esto es muy importante para el almacenamiento en caché de planes de consultas en SQL Server y PostgreSQL.## Operaciones masivas: ejecutar actualización y ejecución de eliminación

ExecuteUpdate y ExecuteDelete se introdujeron en EF Core 7, pero EF Core 9 amplía lo que puedes hacer con ellos de maneras significativas.

Expresiones de actualización más complejas

Ahora puedes usar expresiones más complejas en ExecuteUpdate, incluidas referencias a otras tablas a través de propiedades de navegación:

await context.Products
 .Where(p => p.Category.IsDiscontinued)
 .ExecuteUpdateAsync(setters => setters
 .SetProperty(p => p.IsAvailable, false)
 .SetProperty(p => p.DiscontinuedDate, DateTimeOffset.UtcNow)
 .SetProperty(p => p.Price, p => p.Price * 0.5m));

Esto genera una única declaración UPDATE con un JOIN en la tabla de categorías: no es necesario cargar entidades en la memoria, ni hay gastos generales de seguimiento de cambios.

Eliminaciones masivas condicionales con subconsultas

Las eliminaciones masivas con filtros de subconsultas ahora son totalmente compatibles:

await context.AuditLogs
 .Where(log => log.CreatedAt < DateTime.UtcNow.AddYears(-2))
 .Where(log => !context.ProtectedRecords
 .Any(pr => pr.AuditLogId == log.Id))
 .ExecuteDeleteAsync();

Esto se traduce en una DELETE con una subconsulta NOT EXISTS, exactamente lo que escribirías a mano. Sin entidades cargadas, sin viajes de ida y vuelta.

Mejoras en la columna JSON

Las columnas JSON han sido una de las características más interesantes de las versiones recientes de EF Core, y EF Core 9 las lleva más allá.

Consultando dentro de JSON

Ahora puede filtrar y proyectar datos desde columnas JSON con mejor soporte de traducción:

public class Order
{
 public int Id { get; set; }
 public string CustomerName { get; set; }
 public ShippingAddress Address { get; set; } // Stored as JSON
 public List<OrderNote> Notes { get; set; } // Stored as JSON
}

public class ShippingAddress
{
 public string Street { get; set; }
 public string City { get; set; }
 public string State { get; set; }
 public string ZipCode { get; set; }
 public string Country { get; set; }
}

public class OrderNote
{
 public DateTime CreatedAt { get; set; }
 public string Text { get; set; }
 public string Author { get; set; }
}

Configuración en tu DbContext:

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
 modelBuilder.Entity<Order>(builder =>
 {
 builder.OwnsOne(o => o.Address, ab =>
 {
 ab.ToJson();
 });

 builder.OwnsMany(o => o.Notes, nb =>
 {
 nb.ToJson();
 });
 });
}

Ahora puedes consultar directamente en JSON:

var newYorkOrders = await context.Orders
 .Where(o => o.Address.State == "NY")
 .OrderByDescending(o => o.Notes.Count)
 .Select(o => new
 {
 o.CustomerName,
 o.Address.City,
 LatestNote = o.Notes
 .OrderByDescending(n => n.CreatedAt)
 .Select(n => n.Text)
 .FirstOrDefault()
 })
 .ToListAsync();

EF Core 9 genera llamadas JSON_VALUE y JSON_QUERY adecuadas en SQL Server (o equivalente en otros proveedores) y la traducción cubre una gama mucho más amplia de operaciones LINQ en elementos JSON que antes.

Actualización de propiedades JSON

Uno de los puntos de fricción en EF Core 8 fue que la actualización de una sola propiedad dentro de una columna JSON provocaría que se reescribiera todo el documento JSON. EF Core 9 mejora esto con un seguimiento de cambios más granular para tipos asignados en JSON, generando actualizaciones más específicas cuando sea posible.

var order = await context.Orders.FindAsync(orderId);
order.Address.ZipCode = "10001";
await context.SaveChangesAsync();

En los proveedores compatibles, esto puede generar una modificación JSON más específica en lugar de reescribir todo el blob.

Tipos complejos: objetos de valor sin identidad

Los tipos complejos son una de las características que los profesionales del diseño basado en dominios estaban esperando. A diferencia de los tipos propios, los tipos complejos no tienen identidad: son objetos de valor puro.

[ComplexType]
public record Money(decimal Amount, string Currency);

[ComplexType]
public record DateRange(DateTime Start, DateTime End);

public class Project
{
 public int Id { get; set; }
 public string Name { get; set; }
 public Money Budget { get; set; }
 public DateRange Timeline { get; set; }
}

Estos se almacenan como columnas aplanadas en la tabla principal: Budget_Amount, Budget_Currency, Timeline_Start, Timeline_End, sin requerir una tabla separada ni ningún tipo de clave.

La diferencia clave con los tipos propios: los tipos complejos se comparan por valor, no por referencia. Dos instancias de Money con el mismo Amount y Currency se consideran iguales, independientemente de a qué entidad pertenezcan.

var expensiveProjects = await context.Projects
 .Where(p => p.Budget.Amount > 100_000m && p.Budget.Currency == "USD")
 .OrderByDescending(p => p.Budget.Amount)
 .ToListAsync();

Esto se traduce directamente en filtrar las columnas aplanadas: limpio, eficiente y exactamente lo que esperarías.

Compatibilidad con HierarchyId para SQL Server

Si alguna vez ha trabajado con datos jerárquicos en SQL Server (organigramas, árboles de categorías, sistemas de archivos), sabrá que HierarchyId es el tipo integrado para esto. EF Core 9 le brinda soporte de primera clase.

public class Employee
{
 public int Id { get; set; }
 public string Name { get; set; }
 public string Title { get; set; }
 public HierarchyId PathFromCeo { get; set; }
}

Ahora puede consultar relaciones jerárquicas directamente:

var managerId = HierarchyId.Parse("/1/3/");

// All direct and indirect reports
var allReports = await context.Employees
 .Where(e => e.PathFromCeo.IsDescendantOf(managerId))
 .Where(e => e.PathFromCeo != managerId) // exclude the manager
 .OrderBy(e => e.PathFromCeo)
 .ToListAsync();

// Direct reports only (one level down)
var directReports = await context.Employees
 .Where(e => e.PathFromCeo.GetAncestor(1) == managerId)
 .ToListAsync();

// Get an employee's depth in the hierarchy
var employeesWithDepth = await context.Employees
 .Select(e => new
 {
 e.Name,
 e.Title,
 Level = e.PathFromCeo.GetLevel()
 })
 .OrderBy(e => e.Level)
 .ToListAsync();
```Todos estos se traducen a los métodos `HierarchyId` nativos de SQL Server. Si ha estado implementando estructuras de árbol con claves externas autorreferenciadas y CTE recursivas, este es un enfoque mucho más limpio.

## Modelos compilados y soporte AOT

Los desarrolladores preocupados por el rendimiento apreciarán la inversión continua en modelos compilados y soporte de compilación anticipada (AOT).

### Modelos compilados

Los modelos compilados generan previamente los metadatos del modelo que EF Core normalmente crea al inicio. Para modelos grandes (piense en cientos de entidades), esto puede reducir drásticamente el tiempo de arranque en frío.

```bash
dotnet ef dbcontext optimize --output-dir CompiledModels --namespace MyApp.CompiledModels

Luego conéctalo:

builder.Services.AddDbContext<AppDbContext>(options =>
 options
 .UseSqlServer(connectionString)
 .UseModel(MyApp.CompiledModels.AppDbContextModel.Instance));

En EF Core 9, los modelos compilados son más completos: admiten más funciones de mapeo y generan resultados más pequeños. Para un modelo con alrededor de 400 entidades, el tiempo de inicio puede disminuir desde varios segundos hasta casi instantáneo.

Progreso de la compilación de AOT

La compatibilidad total con AOT nativo para EF Core aún es un trabajo en progreso, pero EF Core 9 logra avances significativos. Muchas de las rutas de código con mucha reflexión se han refactorizado para que sean fáciles de recortar, y los modelos compilados son una parte clave de la historia de AOT. Si su objetivo son escenarios como Azure Functions o microservicios donde el arranque en frío es importante, estas mejoras son directamente relevantes.

Actualizaciones del proveedor de Cosmos DB

El proveedor Azure Cosmos DB continúa madurando con EF Core 9. Algunas mejoras notables:

Manejo de claves de partición

El proveedor ahora admite claves de partición jerárquicas y maneja los filtros de claves de partición de manera más inteligente:

public class TenantDocument
{
 public string Id { get; set; }
 public string TenantId { get; set; } // Partition key
 public string Region { get; set; } // Sub-partition key
 public string Content { get; set; }
}

// This query now correctly uses the partition key for routing
var docs = await context.TenantDocuments
 .Where(d => d.TenantId == "tenant-42" && d.Region == "us-east")
 .Where(d => d.Content.Contains("important"))
 .ToListAsync();

Traducción mejorada de LINQ a NoSQL

Más operaciones LINQ ahora se traducen al dialecto SQL de Cosmos DB, incluida una mejor compatibilidad con Contains, Any, operaciones de matrices anidadas y funciones matemáticas. Las consultas que antes recaían en la evaluación del cliente ahora se manejan en el lado del servidor.

Soporte de búsqueda vectorial

EF Core 9 presenta soporte temprano para la búsqueda de similitudes vectoriales con Cosmos DB, lo cual es útil si está creando aplicaciones que se integran con incrustaciones o búsqueda basada en IA:

var results = await context.Documents
 .OrderBy(d => EF.Functions.VectorDistance(d.Embedding, queryVector))
 .Take(10)
 .ToListAsync();

Mejoras en la migración

Las migraciones obtuvieron algunas mejoras en la calidad de vida que hacen que trabajar con ellas sea menos doloroso en entornos de equipo.

Tablas Temporales en Migraciones

Las migraciones ahora manejan la configuración de la tabla temporal de manera más elegante, con soporte adecuado para columnas de período y nombres de tablas de historial:

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
 modelBuilder.Entity<Employee>()
 .ToTable("Employees", b => b.IsTemporal(t =>
 {
 t.HasPeriodStart("ValidFrom");
 t.HasPeriodEnd("ValidTo");
 t.UseHistoryTable("EmployeeHistory");
 }));
}

Scripts idempotentes

El comando Script-Migration (y su equivalente CLI) produce mejores scripts idempotentes de forma predeterminada, con un manejo mejorado de casos extremos en torno a cambios de esquema que dependen de los datos existentes en ciertos estados.

Paquetes de migración

Los paquetes de migración, que empaquetan sus migraciones en un ejecutable independiente para su implementación, son más confiables en EF Core 9 con mejores informes de errores y lógica de reintento para fallas transitorias.

dotnet ef migrations bundle --self-contained -r linux-x64

Esto produce un binario que puede ejecutar en su canal de CI/CD sin necesidad de que el SDK de .NET esté instalado en su destino de implementación.

Puntos de referencia de rendimientoAquí hay algunos puntos de referencia aproximados de mis propias pruebas. Estos pertenecen a un proyecto con aproximadamente 200 entidades, que se ejecuta en SQL Server 2022, medido con BenchmarkDotNet. Sus números variarán, pero las mejoras relativas deberían ser similares.

Escenario	EF Núcleo 8	EF Núcleo 9	Mejora
Construcción del modelo (arranque en frío)	1.850 ms	320 ms	~5,8 veces más rápido (compilado)
Consulta simple (entidad única por PK)	0,42 ms	0,38 ms	~10% más rápido
Consulta compleja (uniones + agregación)	3,1 ms	2,4 ms	~23% más rápido
Actualización masiva (10.000 filas)	145 ms	118ms	~19% más rápido
Consulta de columna JSON	2,8 ms	1,9 ms	~32% más rápido
SaveChanges (100 entidades)	48ms	41ms	~15% más rápido

La mejora del modelo compilado es la más espectacular, pero las mejoras constantes en todos los ámbitos se suman, especialmente en escenarios de alto rendimiento en los que se ejecutan miles de consultas por segundo.

Actualización desde EF Core 8

Si está en EF Core 8, la ruta de actualización es relativamente sencilla. Aquí hay una lista de verificación:

1. Actualiza tus paquetes:

<PackageReference Include="Microsoft.EntityFrameworkCore" Version="9.0.0" />
<PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="9.0.0" />
<PackageReference Include="Microsoft.EntityFrameworkCore.Tools" Version="9.0.0" />

2. Compruebe si hay cambios importantes. La lista de EF Core 9 es relativamente corta en comparación con algunas versiones anteriores. Los más notables:

Se han eliminado algunas API previamente obsoletas.
Cambios en cómo se traducen ciertas consultas GroupBy (ahora van al lado del servidor, lo que cambia el comportamiento si dependiera de la evaluación del cliente)
Cambios menores en la producción del andamiaje de migración.

3. Vuelva a generar modelos compilados si los está utilizando. El formato cambió, por lo que los modelos compilados antiguos no funcionarán con EF Core 9.

4. Ejecute su conjunto de pruebas. Preste especial atención a las consultas que se evaluaron previamente en el cliente; es posible que ahora se evalúen en el servidor, lo que suele ser mejor, pero podría revelar diferencias en los datos.

5. Verifique sus consultas de Cosmos DB si está utilizando ese proveedor. Las traducciones mejoradas significan que algunas consultas se ejecutarán de manera diferente (generalmente más rápido), pero vale la pena verificar que los resultados sean idénticos.

Una actualización mínima para un proyecto típico se ve así:

dotnet add package Microsoft.EntityFrameworkCore --version 9.0.0
dotnet add package Microsoft.EntityFrameworkCore.SqlServer --version 9.0.0
dotnet add package Microsoft.EntityFrameworkCore.Design --version 9.0.0
dotnet build
dotnet test

Si todo se compila y las pruebas pasan, probablemente esté en buena forma. Si tiene problemas, la documentación de cambios importantes de EF Core 9 tiene una guía de migración detallada para cada cambio.

Concluyendo

EF Core 9 no es una versión revolucionaria: es evolutiva y eso es exactamente lo que tenía que ser. Las mejoras de LINQ por sí solas justifican la actualización para la mayoría de los proyectos, y características como mejoras en las columnas JSON, tipos complejos y HierarchyId admiten patrones abiertos que antes eran incómodos o imposibles.

Si tuviera que elegir las tres características que han tenido mayor impacto en mis proyectos:

Colecciones primitivas parametrizadas: porque la eficiencia de la caché del plan de consultas es importante a escala
Mejoras en las columnas JSON: porque el patrón híbrido de documento relacional es increíblemente útil
Modelos compilados: porque el tiempo de inicio afecta directamente la productividad del desarrollador y la velocidad de implementación.El equipo de EF Core ha seguido una trayectoria sólida desde EF Core 5 y la versión 9 continúa esa tendencia. Si ya tiene EF Core 8, la actualización es de bajo riesgo y alta recompensa. Si estás en algo más antiguo, nunca ha habido un mejor momento para dar el salto.

Codificación feliz y consultas felices.

Introducción al kernel semántico: orquestación de IA en C#

Sun, 05 Oct 2025 00:00:00 +0000

Si ha estado creando aplicaciones .NET y observando la evolución del panorama de la IA, probablemente se haya preguntado: ¿cuál es la mejor manera de integrar grandes modelos de lenguaje en mis proyectos de C# sin convertir mi código base en espaguetis? Ese es exactamente el problema que resuelve el kernel semántico de Microsoft, y después de pasar el último año creando aplicaciones de producción con él, puedo decirles que se ha convertido en una de las herramientas más importantes de mi conjunto de herramientas de desarrollador.

En esta publicación, lo guiaré a través de todo lo que necesita para comenzar con Semantic Kernel, desde comprender los conceptos básicos hasta crear un asistente de IA del mundo real. Ya sea que esté inmerso en el desarrollo de IA o esté buscando una forma estructurada de organizar llamadas de LLM en sus aplicaciones .NET existentes, esta guía lo tiene cubierto.

¿Qué es el kernel semántico?

Semantic Kernel (SK) es un SDK de código abierto de Microsoft que actúa como una capa de orquestación entre el código de su aplicación y modelos de lenguaje grandes como GPT-4o, Azure OpenAI u otros servicios de IA. Piense en ello como un middleware liviano que le permite combinar código C# tradicional con capacidades de IA de una manera limpia y componible.

Pero ¿por qué no llamar directamente a la API de OpenAI? Es absolutamente posible, y para casos de uso sencillos, está bien. Pero en el momento necesitas:

Deje que la IA decida qué funciones llamar según la entrada del usuario
Combine múltiples llamadas de IA con código tradicional en una canalización
Añade memoria y contexto para que la IA recuerde interacciones anteriores.
Cree agentes de varios pasos que razonan a través de tareas complejas

…te encontrarás reinventando la rueda. Semantic Kernel le ofrece todo esto listo para usar, con soporte .NET de primera clase, integración de inyección de dependencias y una arquitectura de complementos que resulta natural para cualquier desarrollador de C#.

El proyecto se encuentra en GitHub en el repositorio microsoft/semantic-kernel y tiene SDK para C#, Python y Java. El SDK de C# es el más maduro y en el que nos centraremos aquí.

Conceptos básicos

Antes de escribir cualquier código, comprendamos los componentes básicos.

El núcleo

El Kernel es el objeto central en Semantic Kernel. Es el orquestador, lo que une sus servicios, complementos y configuración de IA. Usted crea uno, registra sus servicios y complementos en él y luego lo utiliza para ejecutar mensajes o invocar funciones. Si está familiarizado con la inyección de dependencias en ASP.NET Core, el Kernel le resultará muy familiar: es esencialmente un contenedor de servicios con superpoderes de IA.

Complementos y funciones

Un complemento es una colección de funciones relacionadas que el kernel puede invocar. Las funciones vienen en dos tipos:

Funciones de aviso: definidas como plantillas de lenguaje natural que se envían al LLM
Funciones nativas: métodos normales de C# decorados con atributos que el kernel puede descubrir y llamar

Por ejemplo, podría tener un WeatherPlugin con una función nativa GetCurrentWeather(string city) y una función de aviso que resume los datos meteorológicos de una manera amigable.### Conectores de IA

Los conectores son la forma en que Semantic Kernel se comunica con los servicios de IA. Los más comunes son:

AzureOpenAIChatCompletion — para el servicio Azure OpenAI
OpenAIChatCompletion — para la API de OpenAI directamente
Incorporación de conectores para búsqueda de vectores y memoria.

Los registra en el Kernel al inicio y todo lo demás simplemente funciona.

Configurando tu proyecto

Ensuciémonos las manos. Comience creando una nueva aplicación de consola:

dotnet new console -n SemanticKernelDemo
cd SemanticKernelDemo

Ahora agregue los paquetes Semantic Kernel NuGet:

dotnet add package Microsoft.SemanticKernel
dotnet add package Microsoft.SemanticKernel.Connectors.AzureOpenAI

Si usa OpenAI directamente en lugar de Azure OpenAI:

dotnet add package Microsoft.SemanticKernel.Connectors.OpenAI

Para compatibilidad con memoria e incrustaciones (usaremos esto más adelante):

dotnet add package Microsoft.SemanticKernel.Plugins.Memory
dotnet add package Microsoft.Extensions.VectorData.Abstractions

Su .csproj debe apuntar a .NET 8 o posterior. Las últimas versiones de Semantic Kernel aprovechan al máximo las funciones modernas de .NET.

Tu primer núcleo

Comencemos con el ejemplo más simple posible: crear un kernel, conectarlo a un servicio de inteligencia artificial y hacerle una pregunta.

using Microsoft.SemanticKernel;

// Build the kernel with Azure OpenAI
var builder = Kernel.CreateBuilder();

builder.AddAzureOpenAIChatCompletion(
 deploymentName: "gpt-4o",
 endpoint: "https://your-resource.openai.azure.com/",
 apiKey: "your-api-key"
);

var kernel = builder.Build();

// Invoke a simple prompt
var result = await kernel.InvokePromptAsync(
 "Explain dependency injection in C# in three sentences."
);

Console.WriteLine(result);

Si está utilizando OpenAI directamente, intercambie el registro del servicio:

builder.AddOpenAIChatCompletion(
 modelId: "gpt-4o",
 apiKey: "your-openai-api-key"
);

Eso es todo. Ejecútelo y obtendrá una explicación concisa sobre la inyección de dependencia. Pero esto es sólo una muestra de lo que ocurre.

Uso de plantillas de mensajes

Las plantillas de mensajes le permiten parametrizar sus mensajes con variables usando una sintaxis estilo Manillar:

var prompt = """
 You are a technical writer. Write a brief summary of {{$topic}}
 aimed at developers with {{$experienceLevel}} experience.
 Keep it under 200 words.
 """;

var function = kernel.CreateFunctionFromPrompt(prompt);

var arguments = new KernelArguments
{
 ["topic"] = "gRPC in .NET",
 ["experienceLevel"] = "intermediate"
};

var result = await kernel.InvokeAsync(function, arguments);
Console.WriteLine(result);

Aquí es donde Semantic Kernel comienza a brillar: puede definir plantillas de mensajes reutilizables, versionarlas y componerlas en flujos de trabajo más grandes.

Complementos y funciones nativas

Los complementos son donde Semantic Kernel cierra la brecha entre la IA y su código C# existente. Una función nativa es simplemente un método normal que se expone al Kernel.

using Microsoft.SemanticKernel;
using System.ComponentModel;

public class TimePlugin
{
 [KernelFunction("get_current_time")]
 [Description("Gets the current date and time in UTC")]
 public string GetCurrentTime()
 {
 return DateTime.UtcNow.ToString("yyyy-MM-dd HH:mm:ss UTC");
 }

 [KernelFunction("get_time_in_timezone")]
 [Description("Gets the current time in a specific timezone")]
 public string GetTimeInTimezone(
 [Description("The IANA timezone identifier, e.g. 'America/New_York'")] string timezone)
 {
 var tz = TimeZoneInfo.FindSystemTimeZoneById(timezone);
 var time = TimeZoneInfo.ConvertTimeFromUtc(DateTime.UtcNow, tz);
 return time.ToString("yyyy-MM-dd HH:mm:ss");
 }
}

Observe los atributos [KernelFunction] y [Description]. Estos son fundamentales: las descripciones son lo que la IA lee para comprender cuándo y cómo llamar a sus funciones. Las buenas descripciones marcan la diferencia entre una IA que utiliza sus herramientas de forma eficaz y una que está confusa.

Registre el complemento en su kernel:

var builder = Kernel.CreateBuilder();

builder.AddAzureOpenAIChatCompletion(
 deploymentName: "gpt-4o",
 endpoint: "https://your-resource.openai.azure.com/",
 apiKey: "your-api-key"
);

builder.Plugins.AddFromType<TimePlugin>();

var kernel = builder.Build();

También puede crear complementos más complejos que inyecten servicios. Dado que Semantic Kernel se integra con Microsoft.Extensions.DependencyInjection, sus complementos pueden recibir dependencias del constructor como cualquier otro servicio:

public class OrderPlugin
{
 private readonly IOrderRepository _repository;

 public OrderPlugin(IOrderRepository repository)
 {
 _repository = repository;
 }

 [KernelFunction("get_order_status")]
 [Description("Retrieves the status of an order by its ID")]
 public async Task<string> GetOrderStatus(
 [Description("The order ID to look up")] string orderId)
 {
 var order = await _repository.GetByIdAsync(orderId);
 return order is null
 ? $"No order found with ID {orderId}"
 : $"Order {orderId}: {order.Status}, placed on {order.CreatedAt:d}";
 }
}

Llamada de funciones y autoinvocación

Aquí es donde las cosas se ponen realmente interesantes. Con la llamada a función (también conocida como llamada a herramienta), permite que el modelo de IA decida a cuál de sus funciones registradas llamar según el contexto de la conversación. El modelo no ejecuta código: devuelve una solicitud estructurada que dice “Quiero llamar a la función X con estos argumentos” y el Kernel maneja la invocación real.

A continuación se explica cómo habilitar la llamada de función automática:

using Microsoft.SemanticKernel;
using Microsoft.SemanticKernel.Connectors.OpenAI;

var builder = Kernel.CreateBuilder();

builder.AddAzureOpenAIChatCompletion(
 deploymentName: "gpt-4o",
 endpoint: "https://your-resource.openai.azure.com/",
 apiKey: "your-api-key"
);

builder.Plugins.AddFromType<TimePlugin>();
builder.Plugins.AddFromType<WeatherPlugin>();

var kernel = builder.Build();

// Enable automatic function calling
var settings = new OpenAIPromptExecutionSettings
{
 FunctionChoiceBehavior = FunctionChoiceBehavior.Auto()
};

var result = await kernel.InvokePromptAsync(
 "What time is it in Tokyo and what's the weather like there?",
 new KernelArguments(settings)
);

Console.WriteLine(result);

Con FunctionChoiceBehavior.Auto(), el Kernel:

Envíe su mensaje a la IA junto con descripciones de todas las funciones disponibles.
La IA decide que necesita llamar a get_time_in_timezone y get_weather
El Kernel ejecuta automáticamente esas funciones.
Los resultados se envían a la IA.
La IA compone una respuesta en lenguaje natural utilizando los resultados de la función.Este bucle puede ocurrir varias veces en una sola invocación: la IA puede llamar a varias funciones en secuencia para recopilar toda la información que necesita. También puedes usar FunctionChoiceBehavior.Required() para obligar a la IA a llamar al menos a una función, o proporcionar una lista específica de funciones que puede usar.

Finalización del chat con historial

Para aplicaciones conversacionales, querrás usar ChatCompletionService directamente con un objeto ChatHistory:

using Microsoft.SemanticKernel.ChatCompletion;

var chatService = kernel.GetRequiredService<IChatCompletionService>();
var history = new ChatHistory();

history.AddSystemMessage("""
 You are a helpful developer assistant. You have access to tools
 for checking the time and weather. Be concise and friendly.
 """);

while (true)
{
 Console.Write("You: ");
 var input = Console.ReadLine();
 if (string.IsNullOrWhiteSpace(input)) break;

 history.AddUserMessage(input);

 var response = await chatService.GetChatMessageContentAsync(
 history,
 executionSettings: settings,
 kernel: kernel
 );

 history.AddAssistantMessage(response.Content ?? "");
 Console.WriteLine($"Assistant: {response.Content}");
}

Esto le brinda un chatbot completamente interactivo que mantiene el historial de conversaciones y puede llamar a sus complementos según sea necesario.

Memoria e incrustaciones

Uno de los patrones más poderosos en las aplicaciones de IA es la Generación aumentada de recuperación (RAG), que brinda a la IA acceso a sus propios datos incorporándolos en el espacio vectorial y recuperando fragmentos relevantes en el momento de la consulta.

Semantic Kernel proporciona abstracciones para trabajar con incrustaciones y almacenes de vectores. A continuación se explica cómo configurar un almacén de vectores en memoria para el desarrollo:

using Microsoft.Extensions.VectorData;
using Microsoft.SemanticKernel.Connectors.AzureOpenAI;
using Microsoft.SemanticKernel.Embeddings;

#pragma warning disable SKEXP0010

// Create an embedding generation service
var builder = Kernel.CreateBuilder();

builder.AddAzureOpenAITextEmbeddingGeneration(
 deploymentName: "text-embedding-ada-002",
 endpoint: "https://your-resource.openai.azure.com/",
 apiKey: "your-api-key"
);

var kernel = builder.Build();
var embeddingService = kernel.GetRequiredService<ITextEmbeddingGenerationService>();

// Generate embeddings for your documents
var documents = new[]
{
 "Semantic Kernel is an open-source SDK for AI orchestration.",
 "Azure OpenAI provides enterprise-grade AI models.",
 "Plugins in SK allow you to expose C# methods to AI models."
};

var embeddings = await embeddingService.GenerateEmbeddingsAsync(documents);

Para escenarios de producción, almacenaría estas incorporaciones en una base de datos vectorial dedicada como Azure AI Search, Qdrant o Pinecone. Semantic Kernel tiene conectores para todos estos a través de las abstracciones Microsoft.Extensions.VectorData.

Un flujo RAG típico se ve así:

Ingesta: fragmenta tus documentos, genera incrustaciones y guárdalos en una base de datos vectorial.
Recuperar: cuando un usuario hace una pregunta, incrusta la consulta y busca los documentos más similares
Generar: pasar los documentos recuperados como contexto al LLM junto con la pregunta del usuario.

[KernelFunction("search_knowledge_base")]
[Description("Searches the internal knowledge base for relevant information")]
public async Task<string> SearchKnowledgeBase(
 [Description("The search query")] string query)
{
 var queryEmbedding = await _embeddingService.GenerateEmbeddingAsync(query);

 var results = await _vectorStore.SearchAsync(queryEmbedding, limit: 3);

 return string.Join("\n\n", results.Select(r => r.Text));
}

Al exponer su canal RAG como una función del núcleo, la IA puede decidir automáticamente cuándo necesita buscar en su base de conocimientos, manteniendo limpia la orquestación y dejando que el modelo haga lo que mejor sabe hacer.

Planificadores y agentes

A medida que sus aplicaciones de IA se vuelven más complejas, necesitará la IA para planificar y ejecutar tareas de varios pasos. Aquí es donde entra en juego el marco del agente de Semantic Kernel.

Conceptos básicos: agente de finalización de chat

El tipo de agente más simple incluye un modelo de finalización de chat con instrucciones y complementos:

using Microsoft.SemanticKernel.Agents;

#pragma warning disable SKEXP0110

var agent = new ChatCompletionAgent
{
 Name = "DevAssistant",
 Instructions = """
 You are a senior .NET developer assistant. Help users with code
 reviews, architecture decisions, and debugging. Always provide
 code examples when relevant. Use your available tools to look up
 current information when needed.
 """,
 Kernel = kernel,
 Arguments = new KernelArguments(settings)
};

var history = new ChatHistory();

history.AddUserMessage("How should I structure a clean architecture project in .NET 8?");

await foreach (var message in agent.InvokeAsync(history))
{
 Console.WriteLine(message.Content);
 history.Add(message);
}

Colaboración entre múltiples agentes

Cuando las cosas se vuelven realmente poderosas es cuando tienes varios agentes trabajando juntos. Semantic Kernel admite patrones de chat grupal donde colaboran agentes con diferentes especializaciones:

#pragma warning disable SKEXP0110

var codeReviewer = new ChatCompletionAgent
{
 Name = "CodeReviewer",
 Instructions = """
 You review C# code for bugs, performance issues, and best practices.
 Be specific about what you find and suggest concrete fixes.
 """,
 Kernel = kernel
};

var securityAuditor = new ChatCompletionAgent
{
 Name = "SecurityAuditor",
 Instructions = """
 You focus exclusively on security vulnerabilities in code.
 Look for injection attacks, authentication issues, data exposure,
 and OWASP Top 10 violations.
 """,
 Kernel = kernel
};

var groupChat = new AgentGroupChat(codeReviewer, securityAuditor)
{
 ExecutionSettings = new AgentGroupChatSettings
 {
 TerminationStrategy = new MaximumIterationTerminationStrategy(4)
 }
};

groupChat.AddChatMessage(
 new ChatMessageContent(AuthorRole.User, "Review this code: ...")
);

await foreach (var message in groupChat.InvokeAsync())
{
 Console.WriteLine($"[{message.AuthorName}]: {message.Content}");
}

Este patrón es increíblemente útil para tareas complejas en las que deben influir diferentes perspectivas o áreas de experiencia. Cada agente opera con su propio indicador del sistema y puede tener su propio conjunto de complementos.

Ejemplo del mundo real: creación de un asistente de documentación de proyectos

Unamos todo con un ejemplo práctico: un asistente de IA que ayuda a los desarrolladores a comprender una base de código leyendo archivos y respondiendo preguntas.

using Microsoft.SemanticKernel;
using Microsoft.SemanticKernel.ChatCompletion;
using Microsoft.SemanticKernel.Connectors.OpenAI;
using System.ComponentModel;

// Define our plugins
public class FileSystemPlugin
{
 private readonly string _rootPath;

 public FileSystemPlugin(string rootPath)
 {
 _rootPath = rootPath;
 }

 [KernelFunction("read_file")]
 [Description("Reads the contents of a file from the project directory")]
 public async Task<string> ReadFile(
 [Description("Relative path to the file")] string path)
 {
 var fullPath = Path.Combine(_rootPath, path);

 if (!File.Exists(fullPath))
 return $"File not found: {path}";

 var content = await File.ReadAllTextAsync(fullPath);

 // Truncate very large files
 if (content.Length > 8000)
 content = content[..8000] + "\n... [truncated]";

 return content;
 }

 [KernelFunction("list_files")]
 [Description("Lists files in a directory, optionally filtered by extension")]
 public string ListFiles(
 [Description("Relative directory path")] string directory,
 [Description("File extension filter like '.cs' or '.json'")] string? extension = null)
 {
 var fullPath = Path.Combine(_rootPath, directory);

 if (!Directory.Exists(fullPath))
 return $"Directory not found: {directory}";

 var files = Directory.GetFiles(fullPath, "*.*", SearchOption.AllDirectories)
 .Select(f => Path.GetRelativePath(_rootPath, f))
 .Where(f => extension is null || f.EndsWith(extension))
 .Take(50);

 return string.Join("\n", files);
 }
}

public class DocumentationPlugin
{
 [KernelFunction("generate_summary")]
 [Description("Generates a structured markdown summary for documentation")]
 public string GenerateSummaryTemplate(
 [Description("Name of the component")] string componentName,
 [Description("Brief description")] string description,
 [Description("Key responsibilities as comma-separated values")] string responsibilities)
 {
 var items = responsibilities.Split(',', StringSplitOptions.TrimEntries);
 var bullets = string.Join("\n", items.Select(r => $"- {r}"));

 return $"""
 ## {componentName}

 {description}

 ### Responsibilities
 {bullets}

 ---
 *Generated documentation — review and expand as needed.*
 """;
 }
}

// Wire it all up
var builder = Kernel.CreateBuilder();

builder.AddAzureOpenAIChatCompletion(
 deploymentName: "gpt-4o",
 endpoint: "https://your-resource.openai.azure.com/",
 apiKey: "your-api-key"
);

builder.Plugins.AddFromObject(new FileSystemPlugin("./src"));
builder.Plugins.AddFromType<DocumentationPlugin>();

var kernel = builder.Build();

var chatService = kernel.GetRequiredService<IChatCompletionService>();
var history = new ChatHistory();

history.AddSystemMessage("""
 You are a codebase documentation assistant. You help developers understand
 projects by reading source files and explaining architecture, patterns,
 and design decisions.

 When asked about code, use your tools to read the actual files rather
 than guessing. Be specific and reference actual code when possible.
 Generate documentation artifacts when asked.
 """);

var settings = new OpenAIPromptExecutionSettings
{
 FunctionChoiceBehavior = FunctionChoiceBehavior.Auto()
};

Console.WriteLine("Documentation Assistant ready. Ask me about your codebase!");
Console.WriteLine("Type 'exit' to quit.\n");

while (true)
{
 Console.Write("You: ");
 var input = Console.ReadLine();

 if (string.IsNullOrWhiteSpace(input) || input.Equals("exit", StringComparison.OrdinalIgnoreCase))
 break;

 history.AddUserMessage(input);

 var response = await chatService.GetChatMessageContentAsync(
 history,
 executionSettings: settings,
 kernel: kernel
 );

 Console.WriteLine($"\nAssistant: {response.Content}\n");
 history.AddAssistantMessage(response.Content ?? "");
}

Este asistente puede:- Listar y leer archivos desde el directorio de su proyecto

Responder preguntas sobre el código base leyendo archivos fuente reales
Generar documentación en formato Markdown
Mantener el contexto de la conversación para que las preguntas de seguimiento funcionen de forma natural

La IA decide automáticamente cuándo llamar a read_file, list_files o generate_summary según lo que le pidas. Pregúntele “¿Qué hace OrderService?” y leerá el archivo, lo analizará y lo explicará. Pídale que “Genere documentación para el módulo de autenticación” y explorará los archivos, comprenderá la estructura y producirá un resumen formateado.

Consejos para la producción

Antes de enviar su aplicación Semantic Kernel, he aprendido algunas cosas por las malas:

Utilice la inyección de dependencias correctamente. En las aplicaciones ASP.NET Core, registre el kernel y los servicios en su contenedor DI en lugar de crearlos en línea:

builder.Services.AddKernel()
 .AddAzureOpenAIChatCompletion(
 deploymentName: "gpt-4o",
 endpoint: configuration["AzureOpenAI:Endpoint"]!,
 apiKey: configuration["AzureOpenAI:ApiKey"]!
 )
 .Plugins.AddFromType<TimePlugin>()
 .AddFromType<OrderPlugin>();

Maneje los errores con elegancia. Las llamadas de LLM pueden fallar, expirar o devolver resultados inesperados. Envuelva sus invocaciones en bloques try-catch e implemente políticas de reintento con Polly o las funciones de resiliencia integradas.

Supervise el uso de tokens. Cada mensaje, cada descripción de función y cada parte del historial de chat consume tokens. Utilice filtros para registrar y realizar un seguimiento del uso:

kernel.FunctionInvocationFilters.Add(new LoggingFilter());

Mantenga las descripciones de sus funciones precisas. Las descripciones vagas hacen que la IA llame a las funciones de manera incorrecta. Pruebe sus descripciones preguntando: “Si solo leo la descripción, ¿sabría exactamente cuándo y cómo usar esta función?”

Conclusión

Semantic Kernel es una de esas bibliotecas que cambia fundamentalmente la forma de pensar sobre la creación de aplicaciones. No es solo un contenedor de API: es un marco de orquestación que le permite componer capacidades de IA con código tradicional de una manera que sea mantenible, comprobable y lista para producción.

Lo que más me gusta de él es que respeta el ecosistema .NET. Utiliza patrones que ya conoce (inyección de dependencia, atributos, asíncrono/espera, interfaces) y los extiende al mundo de la IA. No es necesario aprender un paradigma completamente nuevo; simplemente agrega IA como otra capacidad en su conjunto de herramientas.

Si está creando aplicaciones .NET y aún no ha explorado el kernel semántico, ahora es el momento. El SDK es estable, la comunidad está activa y los patrones que permite (desde una simple orquestación rápida hasta la colaboración entre múltiples agentes) se están convirtiendo en habilidades esenciales para los desarrolladores modernos.

Empiece poco a poco. Cree un kernel, registre un complemento y observe cómo la IA llama a su código. Una vez que haga clic, comenzará a ver oportunidades para agregar inteligencia en todas partes de sus aplicaciones.

La documentación oficial y el repositorio de GitHub son recursos excelentes para continuar su viaje. ¡Feliz edificio!

Heredar componentes en Blazor

Thu, 04 Sep 2025 00:00:00 +0000

Estaba creando un proyecto que tenía un montón de páginas de formulario y cada una tenía la misma lógica de estado de carga, el mismo manejo de errores y las mismas notificaciones del sistema. Copiar y pegar todo eso me pareció incorrecto, así que analicé la herencia de componentes en Blazor. Resulta que es bastante sencillo ya que los componentes de Blazor son solo clases de C#.

Lo básico

Cada componente de Blazor hereda de ComponentBase de forma predeterminada. Puede crear su propia clase base que extienda ComponentBase y luego hacer que sus componentes hereden de ella.

Digamos que la mayoría de nuestras páginas necesitan estado de carga y manejo de errores. Podemos crear una clase base:

using Microsoft.AspNetCore.Components;

public abstract class PageBase : ComponentBase
{
 protected bool IsLoading { get; set; } = true;
 protected string? ErrorMessage { get; set; }

 protected async Task LoadDataAsync(Func<Task> action)
 {
 try
 {
 IsLoading = true;
 ErrorMessage = null;
 await action();
 }
 catch (Exception ex)
 {
 ErrorMessage = ex.Message;
 }
 finally
 {
 IsLoading = false;
 StateHasChanged();
 }
 }
}

Usando la clase base

Ahora en cualquier componente de la página, en lugar de heredar de ComponentBase, heredamos de nuestro PageBase:

@page "/users"
@inherits PageBase

@if (IsLoading)
{
 <div class="spinner"></div>
}
else if (ErrorMessage is not null)
{
 <div class="alert alert-danger">@ErrorMessage</div>
}
else
{
 <ul>
 @foreach (var user in users)
 {
 <li>@user.Name</li>
 }
 </ul>
}

@code {
 private List<User> users = new();

 protected override async Task OnInitializedAsync()
 {
 await LoadDataAsync(async () =>
 {
 users = await Http.GetFromJsonAsync<List<User>>("api/users");
 });
 }
}

La directiva @inherits PageBase es la clave. Le dice a Blazor que use nuestra clase base en lugar de la [[[TOK_7]] predeterminada. Ahora obtenemos IsLoading, ErrorMessage y LoadDataAsync() gratis en cada página que hereda de él.

Inyectar servicios en la clase base.

También puede inyectar servicios en la clase base para que estén disponibles para todos los componentes secundarios:

public abstract class PageBase : ComponentBase
{
 [Inject]
 protected NavigationManager Navigation { get; set; } = default!;

 [Inject]
 protected IToastService Toast { get; set; } = default!;

 protected bool IsLoading { get; set; } = true;
 protected string? ErrorMessage { get; set; }

 protected void NavigateBack() => Navigation.NavigateTo("javascript:history.back()");

 protected void ShowSuccess(string message) => Toast.ShowSuccess(message);
}

Cada componente que hereda de PageBase ahora tiene acceso a Navigation, Toast, NavigateBack() y ShowSuccess() sin tener que inyectar nada.

Profundizando con clases base genéricas

Incluso puedes crear clases base genéricas para patrones CRUD comunes:

public abstract class CrudPageBase<T> : PageBase
{
 protected List<T> Items { get; set; } = new();
 protected T? SelectedItem { get; set; }

 protected abstract Task<List<T>> FetchItems();
 protected abstract Task DeleteItem(T item);

 protected override async Task OnInitializedAsync()
 {
 await LoadDataAsync(async () =>
 {
 Items = await FetchItems();
 });
 }

 protected async Task OnDelete(T item)
 {
 await LoadDataAsync(async () =>
 {
 await DeleteItem(item);
 Items = await FetchItems();
 ShowSuccess("Item deleted.");
 });
 }
}

Entonces tu página real se vuelve súper limpia:

@page "/products"
@inherits CrudPageBase<Product>

@* just the markup, all logic lives in the base class *@

@code {
 protected override Task<List<Product>> FetchItems()
 => Http.GetFromJsonAsync<List<Product>>("api/products");

 protected override Task DeleteItem(Product item)
 => Http.DeleteAsync($"api/products/{item.Id}");
}

Cuándo usarlo y cuándo no

La herencia de componentes es excelente para comportamientos compartidos como estados de carga, manejo de errores, comprobaciones de autenticación o patrones CRUD. Pero no se exceda con las jerarquías de herencia profundas: si se encuentra profundizando más de dos niveles, probablemente esté mejor con la composición (como el enfoque LoadingComponent de una publicación anterior).

Normalmente lo mantengo en una clase base por “tipo” de página: PageBase para páginas normales, FormPageBase para formularios, y eso es todo.

Espero que os haya gustado el post! No dudes en contactarme en cualquier red social en @emimontesdeoca.

Recursos

Herencia del componente ASP.NET Core Razor

.NET Aspire: creación de aplicaciones nativas de la nube de la manera correcta

Wed, 20 Aug 2025 00:00:00 +0000

Si alguna vez ha creado una aplicación distribuida en .NET, ya conoce el procedimiento. Activa una API web, agrega un trabajador en segundo plano, agrega Redis para almacenamiento en caché, PostgreSQL para persistencia, tal vez RabbitMQ para mensajería y, de repente, pasa más tiempo cableando infraestructura que escribiendo lógica de negocios. Cadenas de conexión dispersas en archivos appsettings.json, comprobaciones de estado que olvidaste configurar, observabilidad que siempre es “el problema del próximo sprint”.

He estado allí. Más veces de las que me gustaría admitir.

Ese es exactamente el problema para el cual .NET Aspire fue diseñado. Después de ejecutarlo en producción durante varios meses, quiero compartir lo que he aprendido: lo bueno, lo excelente y las trampas.

¿Qué es .NET Aspire?

.NET Aspire es una pila obstinada para crear aplicaciones distribuidas, observables y listas para producción con .NET. No es un marco en el sentido tradicional: no reemplaza ASP.NET Core ni lo obliga a adoptar un nuevo modelo de programación. En cambio, se basa en lo que ya sabe y llena los vacíos que siempre han existido al crear aplicaciones nativas de la nube.

Básicamente, Aspire le ofrece cuatro cosas:

AppHost: un proyecto que define toda la topología de su aplicación distribuida. Qué servicios existen, de qué dependen y cómo se conectan.
Valores predeterminados del servicio: un proyecto compartido que configura preocupaciones transversales como controles de estado, políticas de resiliencia y OpenTelemetry, una vez, para todos sus servicios.
Componentes: paquetes NuGet que brindan integraciones estandarizadas con servicios de respaldo como Redis, PostgreSQL, RabbitMQ, Azure Storage y más.
Panel de desarrollador: una interfaz de usuario en tiempo real que muestra registros, seguimientos y métricas de toda su aplicación distribuida durante el desarrollo local.

La filosofía es simple: si cada aplicación de nube .NET necesita estas cosas, ¿por qué las implementamos desde cero cada vez?

Configuración de su primer proyecto Aspire

Comenzar es sencillo. Necesitará .NET 8 o posterior y la carga de trabajo de Aspire instalada:

dotnet workload update
dotnet workload install aspire

Ahora cree un nuevo proyecto inicial de Aspire:

dotnet new aspire-starter -n MyCloudApp

Esto genera una solución con cuatro proyectos:

MyCloudApp.AppHost — El orquestador
MyCloudApp.ServiceDefaults — Configuración compartida
MyCloudApp.ApiService — Una API web de muestra
MyCloudApp.Web — Una interfaz de Blazor

Ejecute AppHost e inmediatamente verá el panel de Aspire abierto en su navegador, mostrando todos sus servicios, sus registros y su estado. No hay archivo Docker Compose. Sin gestión manual de puertos. Simplemente funciona.

dotnet run --project MyCloudApp.AppHost

Esa primera experiencia es la que me enganchó. En menos de un minuto, tendrá una aplicación distribuida totalmente orquestada con observabilidad incorporada.

El patrón AppHost

AppHost es donde vive la magia. Es una pequeña aplicación de consola que utiliza un patrón de creación para definir la topología de su aplicación distribuida: qué recursos existen y cómo se conectan los servicios a ellos.

Así es como se ve un AppHost realista:

var builder = DistributedApplication.CreateBuilder(args);

// Infrastructure resources
var postgres = builder.AddPostgres("postgres")
 .WithPgAdmin()
 .AddDatabase("catalogdb");

var redis = builder.AddRedis("cache");

var rabbitmq = builder.AddRabbitMQ("messaging")
 .WithManagementPlugin();

// Application services
var catalogApi = builder.AddProject<Projects.CatalogApi>("catalog-api")
 .WithReference(postgres)
 .WithReference(redis)
 .WithReference(rabbitmq);

var orderApi = builder.AddProject<Projects.OrderApi>("order-api")
 .WithReference(postgres)
 .WithReference(rabbitmq);

var frontend = builder.AddProject<Projects.WebFrontend>("frontend")
 .WithExternalHttpEndpoints()
 .WithReference(catalogApi)
 .WithReference(orderApi);

builder.Build().Run();
```Lea ese código en voz alta. Prácticamente se documenta a sí mismo. "La API del catálogo hace referencia a PostgreSQL, Redis y RabbitMQ. La interfaz hace referencia a la API del catálogo y a la API de pedidos". Esa es su arquitectura, expresada en código.

Algunas cosas que vale la pena señalar:

- **`WithReference`** hace el trabajo pesado. Inyecta automáticamente cadenas de conexión y URL de servicio en el proyecto consumidor a través de variables de entorno y configuración. Sus servicios no necesitan saber *dónde* se está ejecutando Redis: Aspire se encarga de ello.
- **`WithPgAdmin()`** y **`WithManagementPlugin()`** activan las IU de administración para PostgreSQL y RabbitMQ junto con los servicios reales. Durante el desarrollo, estos son invaluables.
- **`WithExternalHttpEndpoints()`** marca un servicio como accesible externamente, lo cual es importante en el momento de la implementación.

### Configuración de recursos

Puede configurar recursos con control detallado:

```csharp
var postgres = builder.AddPostgres("postgres")
 .WithEnvironment("POSTGRES_MAX_CONNECTIONS", "200")
 .WithDataVolume("postgres-data")
 .AddDatabase("catalogdb");

var redis = builder.AddRedis("cache")
 .WithDataVolume("redis-data");

Los volúmenes de datos garantizan que sus datos de desarrollo local sobrevivan a los reinicios de contenedores. Pequeño detalle, gran mejora en la calidad de vida.

Valores predeterminados del servicio: el héroe anónimo

El proyecto ServiceDefaults es la parte más subestimada de Aspire. Es una biblioteca compartida a la que hace referencia cada servicio de su solución y configura todas las preocupaciones transversales que de otro modo olvidaría o implementaría de manera inconsistente.

Así es como se ve un Extensions.cs típico en ServiceDefaults:

public static class Extensions
{
 public static IHostApplicationBuilder AddServiceDefaults(
 this IHostApplicationBuilder builder)
 {
 builder.ConfigureOpenTelemetry();
 builder.AddDefaultHealthChecks();
 builder.Services.AddServiceDiscovery();

 builder.Services.ConfigureHttpClientDefaults(http =>
 {
 http.AddStandardResilienceHandler();
 http.AddServiceDiscovery();
 });

 return builder;
 }

 public static IHostApplicationBuilder ConfigureOpenTelemetry(
 this IHostApplicationBuilder builder)
 {
 builder.Logging.AddOpenTelemetry(logging =>
 {
 logging.IncludeFormattedMessage = true;
 logging.IncludeScopes = true;
 });

 builder.Services.AddOpenTelemetry()
 .WithMetrics(metrics =>
 {
 metrics.AddAspNetCoreInstrumentation()
 .AddHttpClientInstrumentation()
 .AddRuntimeInstrumentation();
 })
 .WithTracing(tracing =>
 {
 tracing.AddAspNetCoreInstrumentation()
 .AddHttpClientInstrumentation()
 .AddGrpcClientInstrumentation();
 });

 builder.AddOpenTelemetryExporters();
 return builder;
 }

 public static IHostApplicationBuilder AddDefaultHealthChecks(
 this IHostApplicationBuilder builder)
 {
 builder.Services.AddHealthChecks()
 .AddCheck("self", () => HealthCheckResult.Healthy(),
 ["live"]);

 return builder;
 }
}

Luego, en el Program.cs de cada servicio, una línea lo hace todo:

var builder = WebApplication.CreateBuilder(args);
builder.AddServiceDefaults();

// Your service-specific configuration...

var app = builder.Build();
app.MapDefaultEndpoints();
app.Run();

Esa única llamada AddServiceDefaults() te brinda:

OpenTelemetry con registro estructurado, métricas y seguimiento distribuido
Controles de estado con criterios de valoración de vida y preparación
Descubrimiento de servicios para que los servicios puedan encontrarse entre sí por nombre
Políticas de resiliencia en todas las llamadas HTTP salientes (reintentos, disyuntores, tiempos de espera)

Esto es lo que separa una demostración “funciona en mi máquina” de un sistema listo para producción. Y Aspire lo convierte en el valor predeterminado, no en una idea de último momento.

Componentes de Aspire

Los componentes de Aspire son paquetes NuGet que estandarizan la forma en que sus servicios se conectan a la infraestructura de respaldo. Son más que simples bibliotecas de clientes: incluyen controles de estado, registros, rastreo y resiliencia configurable listos para usar.

Redis

var builder = WebApplication.CreateBuilder(args);
builder.AddServiceDefaults();
builder.AddRedisDistributedCache("cache");

Eso es todo. La cadena de conexión proviene de AppHost a través de WithReference. El componente registra un IDistributedCache respaldado por Redis, con controles de estado e instrumentación OpenTelemetry ya conectados.

También puedes usar Redis para el almacenamiento en caché de resultados:

builder.AddRedisOutputCache("cache");

PostgreSQL con Entity Framework Core

builder.AddNpgsqlDbContext<CatalogDbContext>("catalogdb", settings =>
{
 settings.DisableRetry = false;
});

Esto registra tu DbContext con una conexión a la base de datos catalogdb definida en AppHost. Incluye agrupación de conexiones, comprobaciones de estado y políticas de reintento.

ConejoMQ

builder.AddRabbitMQClient("messaging");

Registra un IConnection de la biblioteca cliente RabbitMQ, completamente configurado y con control de estado.

Integraciones de Azure

Aspire también cuenta con componentes de primera clase para servicios de Azure:

// Azure Blob Storage
builder.AddAzureBlobClient("blobs");

// Azure Service Bus
builder.AddAzureServiceBusClient("servicebus");

// Azure Key Vault
builder.AddAzureKeyVaultClient("secrets");
```El patrón es siempre el mismo: una línea en AppHost para definir el recurso, una línea en el servicio consumidor para usarlo. Los detalles de la conexión fluyen automáticamente.

## El panel de desarrollador

El panel de Aspire es una de esas características que parece agradable tener hasta que realmente lo usas; entonces no puedes imaginarte trabajando sin él.

Cuando ejecuta su AppHost localmente, el panel se inicia y le brinda:

- **Resumen de recursos**: todos sus servicios e infraestructura de un vistazo, con indicadores de estado
- **Registros estructurados**: transmisión de registros en tiempo real desde cada servicio, filtrable y con capacidad de búsqueda
- **Seguimientos distribuidos**: seguimientos de solicitudes de un extremo a otro que abarcan múltiples servicios, visualizados como gráficos de llamas
- **Métricas**: tasas de solicitudes HTTP, tasas de error, latencias y métricas personalizadas en tiempo real
- **Registros de consola**: salida estándar/stderr sin procesar de cada contenedor y proyecto

El rastreo distribuido es particularmente valioso. Cuando una solicitud llega a su interfaz, fluye a través de la API del catálogo, toca Redis y PostgreSQL: ve la cadena completa con el tiempo para cada salto. Ya no tendrás que adivinar dónde está el cuello de botella.

El panel de control me resultó más útil durante la depuración. En lugar de seguir varias ventanas de terminal o saltar entre archivos de registro, todo está en un solo lugar con ID de correlación que vinculan eventos relacionados entre servicios.

El panel también está disponible como contenedor independiente, lo que significa que puede usarlo en entornos de prueba o canalizaciones de CI:

```bash
docker run --rm -p 18888:18888 \
 mcr.microsoft.com/dotnet/aspire-dashboard:latest

Implementación

Aspire ayuda durante el desarrollo, pero ¿qué pasa con la producción? Aquí es donde las cosas se vuelven prácticas.

Aplicaciones de contenedor de Azure

La ruta de implementación más sencilla es Azure Container Apps (ACA), que cuenta con soporte Aspire de primera clase. Puede implementar directamente mediante la CLI de desarrollador de Azure:

azd init
azd up

El comando azd init detecta su Aspire AppHost y genera la infraestructura como código necesaria. azd up aprovisiona todo (registro de contenedores, aplicaciones de contenedores, bases de datos, instancias de Redis) en función de su topología de AppHost.

Su AppHost esencialmente se convierte en su manifiesto de implementación. El mismo código que define “catalog-api depende de PostgreSQL y Redis” impulsa el aprovisionamiento de la infraestructura.

Kubernetes

Para las implementaciones de Kubernetes, Aspire no genera manifiestos directamente, pero su topología de AppHost se asigna claramente a los recursos de Kubernetes. La herramienta comunitaria aspirate (Aspir8) puede generar gráficos de Helm o manifiestos de Kubernetes desde su AppHost:

dotnet tool install -g aspirate
aspirate generate
aspirate apply

Consideraciones de implementación

Algunas cosas a tener en cuenta:- Las cadenas de conexión cambian entre entornos. Localmente, Aspire activa contenedores e inyecta cadenas de conexión automáticamente. En producción, señalará los servicios administrados. Aspire utiliza la configuración .NET estándar, por lo que las variables de entorno y Azure Key Vault funcionan según lo esperado.

AppHost no se ejecuta en producción. Es una herramienta de orquestación de desarrollo e implementación. En producción, sus servicios se ejecutan de forma independiente, configurados a través de variables de entorno y orquestadores.
Los recursos de infraestructura se convierten en servicios administrados. Su contenedor de PostgreSQL local se convierte en Azure Database para PostgreSQL. Su contenedor de Redis local se convierte en Azure Cache para Redis. El código de consumo no cambia.

Consejos del mundo real

Después de ejecutar Aspire en producción por un tiempo, estas son las lecciones que nos ahorraron tiempo:

1. Utilice comprobaciones personalizadas del ciclo de vida de los recursos

No confíe únicamente en el inicio del contenedor para determinar si un recurso está listo. PostgreSQL podría aceptar conexiones TCP antes de estar realmente listo para atender consultas.

var postgres = builder.AddPostgres("postgres")
 .AddDatabase("catalogdb")
 .WithHealthCheck();

Aspire puede ejecutar controles de estado de los recursos y mantener los servicios dependientes hasta que estén realmente listos.

2. Extraiga patrones comunes en extensiones

Si varios servicios comparten configuraciones similares, cree métodos de extensión:

public static class AppHostExtensions
{
 public static IResourceBuilder<ProjectResource> AddWorkerService(
 this IDistributedApplicationBuilder builder,
 string name,
 IResourceBuilder<IResourceWithConnectionString> db,
 IResourceBuilder<IResourceWithConnectionString> messaging)
 {
 return builder.AddProject<Projects.WorkerService>(name)
 .WithReference(db)
 .WithReference(messaging)
 .WithReplicas(3);
 }
}

3. Aproveche WithReplicas para pruebas de carga

var catalogApi = builder.AddProject<Projects.CatalogApi>("catalog-api")
 .WithReference(postgres)
 .WithReference(redis)
 .WithReplicas(5);

WithReplicas activa múltiples instancias de un servicio localmente. Esto es excelente para probar el equilibrio de carga, los errores de concurrencia y el comportamiento del almacenamiento en caché distribuido sin implementar en un clúster.

4. Utilice parámetros para valores sensibles

No codifique las credenciales, ni siquiera para el desarrollo local:

var dbPassword = builder.AddParameter("db-password", secret: true);

var postgres = builder.AddPostgres("postgres", password: dbPassword)
 .AddDatabase("catalogdb");

Cuando se ejecuta localmente, Aspire solicitará el valor o lo leerá de los secretos del usuario. En CI/CD, proviene de variables de entorno.

5. Las pruebas de integración se vuelven triviales

Aspire incluye un paquete de pruebas que hace que las pruebas de integración de aplicaciones distribuidas sean notablemente fáciles:

[Fact]
public async Task CatalogApiReturnsProducts()
{
 var appHost = await DistributedApplicationTestingBuilder
 .CreateAsync<Projects.MyCloudApp_AppHost>();

 await using var app = await appHost.BuildAsync();
 await app.StartAsync();

 var httpClient = app.CreateHttpClient("catalog-api");
 var response = await httpClient.GetAsync("/api/products");

 response.EnsureSuccessStatusCode();

 var products = await response.Content
 .ReadFromJsonAsync<List<Product>>();
 Assert.NotEmpty(products);
}

Esto pone en marcha su aplicación distribuida completa, incluidas las bases de datos y los intermediarios de mensajes, ejecuta su prueba y la derriba. Pruebas de integración reales contra infraestructura real, en su canal de CI. Sin burlas.

6. Supervisar el uso de recursos localmente

Cuando ejecute varios contenedores localmente, esté atento al consumo de recursos. Una instancia de PostgreSQL, Redis y RabbitMQ con interfaz de usuario de administración puede consumir fácilmente entre 2 y 3 GB de RAM. Si está en una máquina restringida, considere usar configuraciones de recursos más livianas:

var redis = builder.AddRedis("cache")
 .WithContainerRuntimeArgs("--memory=256m");

Conclusión

.NET Aspire ha cambiado fundamentalmente la forma en que construyo aplicaciones distribuidas. No porque introduzca conceptos revolucionarios: los controles de estado, OpenTelemetry y la orquestación de contenedores no son nuevos. Sino porque los convierte en predeterminados. Toma las cien pequeñas decisiones que normalmente tendría que tomar, las implementa con valores predeterminados sensatos y le permite anularlas cuando sea necesario.El patrón AppHost es, en mi opinión, la mayor ventaja. Tener la topología de su aplicación distribuida expresada como código (no dispersada en archivos Docker Compose, manifiestos de Kubernetes y documentos README) hace que el sistema sea comprensible. Los nuevos miembros del equipo pueden abrir Program.cs en AppHost y comprender toda la arquitectura en minutos.

Si está creando aplicaciones distribuidas con .NET, eche un vistazo serio a Aspire. Comience con la plantilla aspire-starter, explore el panel y adopte gradualmente los componentes a medida que los necesite. No es necesario que haga todo lo posible desde el primer día: Aspire es aditivo por diseño.

Se acabaron los días en los que pasabas el primer sprint cableando la infraestructura estándar. Deje que Aspire se encargue de la plomería para que usted pueda concentrarse en lo que realmente importa: su aplicación.

Autenticación y autorización en Blazor: una guía práctica

Sat, 12 Jul 2025 00:00:00 +0000

Si ha trabajado con ASP.NET MVC o Razor Pages, probablemente tenga un modelo mental de cómo funciona la autenticación: el middleware intercepta la solicitud, verifica una cookie o token, completa HttpContext.User y listo. Blazor cambia ese modelo mental de maneras sutiles pero importantes, y si no comprende esas diferencias temprano, terminará depurando problemas de autenticación que parecen imposibles.

En esta publicación, quiero explicar cómo funcionan realmente la autenticación y la autorización en Blazor, cubriendo los modelos de alojamiento de servidor y WebAssembly. Iremos desde los fundamentos hasta los proveedores personalizados, OAuth externo y los obstáculos que he visto que hacen tropezar incluso a los desarrolladores .NET experimentados.

Por qué la autenticación en Blazor es diferente

En ASP.NET tradicional, cada interacción del usuario es una solicitud HTTP. El servidor valida las credenciales, establece una cookie y cada solicitud posterior transporta esa cookie. El proceso de autenticación es lineal y predecible.

Blazor Server funciona a través de una conexión SignalR persistente. Después de que la solicitud HTTP inicial carga la página, todas las interacciones posteriores se realizan a través de WebSockets. No hay una nueva solicitud HTTP por cada clic en un botón, por lo que el middleware no se vuelve a ejecutar en cada interacción. El HttpContext está disponible durante la conexión inicial, pero depender de él durante toda la vida útil de un circuito es una receta para errores.

Blazor WebAssembly se ejecuta completamente en el navegador. No hay ningún HttpContext del lado del servidor en absoluto. El estado de autenticación debe obtenerse de una API, almacenarse en el lado del cliente y administrarse mediante tokens, normalmente JWT. El servidor confía en el cliente sólo en lo que respecta a la validación del token.

Esto significa que Blazor necesita su propia abstracción para el estado de autenticación, una que funcione independientemente del modelo de alojamiento. Esa abstracción es el AuthenticationStateProvider.

Estado de autenticación: La Fundación

En el corazón del sistema de autenticación de Blazor se encuentra AuthenticationStateProvider. Esta es una clase abstracta que expone un único método crítico:

public abstract Task<AuthenticationState> GetAuthenticationStateAsync();

El objeto AuthenticationState envuelve un ClaimsPrincipal, el mismo modelo de identidad utilizado en todo .NET. Los componentes no se comunican directamente con cookies o tokens; preguntan al AuthenticationStateProvider el estado actual.

Para que este estado esté disponible para todo su árbol de componentes, Blazor proporciona CascadingAuthenticationState. Normalmente envuelves tu enrutador con él en App.razor o tu diseño:

<CascadingAuthenticationState>
 <Router AppAssembly="@typeof(App).Assembly">
 <Found Context="routeData">
 <AuthorizeRouteView RouteData="@routeData"
 DefaultLayout="@typeof(MainLayout)">
 <NotAuthorized>
 <p>You're not authorized to view this page.</p>
 </NotAuthorized>
 </AuthorizeRouteView>
 </Found>
 <NotFound>
 <LayoutView Layout="@typeof(MainLayout)">
 <p>Page not found.</p>
 </LayoutView>
 </NotFound>
 </Router>
</CascadingAuthenticationState>

El AuthorizeRouteView cumple una doble función aquí: verifica si el usuario está autenticado y autorizado antes de representar el componente de página coincidente, y proporciona una interfaz de usuario alternativa cuando no lo está.

En .NET 8 y versiones posteriores con el modelo Blazor unificado, configurará esto en su App.razor y el marco maneja el parámetro en cascada automáticamente cuando usa AddCascadingAuthenticationState() en su registro de servicio.

Integración de identidad ASP.NET

Para la mayoría de los proyectos, no es necesario crear la autenticación desde cero. ASP.NET Identity le brinda administración de usuarios, hash de contraseñas, autenticación de dos factores y confirmación de cuenta lista para usar.La configuración con Blazor comienza en Program.cs:

builder.Services.AddDbContext<ApplicationDbContext>(options =>
 options.UseSqlServer(builder.Configuration.GetConnectionString("DefaultConnection")));

builder.Services.AddDefaultIdentity<IdentityUser>(options =>
 {
 options.SignIn.RequireConfirmedAccount = true;
 options.Password.RequireDigit = true;
 options.Password.RequiredLength = 8;
 })
 .AddRoles<IdentityRole>()
 .AddEntityFrameworkStores<ApplicationDbContext>();

builder.Services.AddAuthentication(options =>
 {
 options.DefaultScheme = IdentityConstants.ApplicationScheme;
 options.DefaultSignInScheme = IdentityConstants.ExternalScheme;
 });

Con la plantilla de Blazor Web App en .NET 8+, la interfaz de usuario de identidad con scaffolding utiliza componentes de Razor directamente. Obtiene páginas de inicio de sesión, registro y administración de cuentas que se integran naturalmente con el resto de su aplicación Blazor: no más mezclas incómodas de Razor Pages y componentes Blazor.

El ApplicationDbContext hereda de IdentityDbContext y necesitarás ejecutar migraciones para crear las tablas de identidad:

public class ApplicationDbContext : IdentityDbContext<IdentityUser>
{
 public ApplicationDbContext(DbContextOptions<ApplicationDbContext> options)
 : base(options) { }
}

dotnet ef migrations add InitialIdentity
dotnet ef database update

El componente AuthorizeView

Una vez que el estado de autenticación fluye a través de su árbol de componentes, AuthorizeView le permite representar la interfaz de usuario de forma condicional:

<AuthorizeView>
 <Authorized>
 <p>Welcome, @context.User.Identity?.Name!</p>
 <a href="/account/manage">Manage Account</a>
 <form method="post" action="/account/logout">
 <button type="submit">Log Out</button>
 </form>
 </Authorized>
 <NotAuthorized>
 <a href="/account/login">Log In</a>
 <a href="/account/register">Register</a>
 </NotAuthorized>
</AuthorizeView>

El parámetro context dentro de <Authorized> le brinda acceso a AuthenticationState, para que pueda inspeccionar reclamos, roles y la identidad del usuario directamente en su marcado.

También puedes usar AuthorizeView con roles y políticas:

<AuthorizeView Roles="Admin,Moderator">
 <Authorized>
 <button @onclick="DeletePost">Delete Post</button>
 </Authorized>
</AuthorizeView>

<AuthorizeView Policy="CanEditArticles">
 <Authorized>
 <button @onclick="EditArticle">Edit</button>
 </Authorized>
</AuthorizeView>

Una cosa a tener en cuenta: AuthorizeView es un problema de interfaz de usuario. Oculta o muestra elementos, pero no protege la lógica subyacente. Si alguien puede llamar a su punto final API o invocar su método directamente, omitirá AuthorizeView por completo. Aplique siempre la autorización también en el lado del servidor.

El atributo [Autorizar]

Para proteger una página completa, aplique el atributo [Authorize]:

@page "/admin/dashboard"
@attribute [Authorize(Roles = "Admin")]

<h1>Admin Dashboard</h1>
<p>Only administrators can see this page.</p>

Cuando un usuario no autenticado navega a esta página, AuthorizeRouteView se activa y representa la plantilla <NotAuthorized> que definiste anteriormente. Puedes redirigir a una página de inicio de sesión manejando el caso NotAuthorized con navegación:

<NotAuthorized>
 @if (!context.User.Identity?.IsAuthenticated ?? true)
 {
 <RedirectToLogin />
 }
 else
 {
 <p>You don't have permission to access this page.</p>
 }
</NotAuthorized>

Un componente RedirectToLogin simple podría verse así:

@inject NavigationManager Navigation

@code {
 protected override void OnInitialized()
 {
 var returnUrl = Uri.EscapeDataString(Navigation.Uri);
 Navigation.NavigateTo($"/account/login?returnUrl={returnUrl}", forceLoad: true);
 }
}

El forceLoad: true es importante aquí: desea una navegación HTTP real para que el middleware de autenticación del lado del servidor pueda manejar el flujo de inicio de sesión correctamente.

Autorización basada en roles y políticas

Los roles son el modelo más simple: asigne usuarios a grupos como “Administrador” o “Editor” y luego verifique la membresía. Pero las políticas le brindan mucha más flexibilidad.

Registrar políticas en Program.cs:

builder.Services.AddAuthorizationCore(options =>
{
 options.AddPolicy("CanPublish", policy =>
 policy.RequireClaim("Permission", "Publish"));

 options.AddPolicy("MinimumAge", policy =>
 policy.Requirements.Add(new MinimumAgeRequirement(18)));

 options.AddPolicy("PremiumUser", policy =>
 policy.RequireRole("Premium")
 .RequireClaim("Subscription", "Active"));
});

Los requisitos personalizados necesitan un controlador:

public class MinimumAgeRequirement : IAuthorizationRequirement
{
 public int MinimumAge { get; }
 public MinimumAgeRequirement(int minimumAge) => MinimumAge = minimumAge;
}

public class MinimumAgeHandler : AuthorizationHandler<MinimumAgeRequirement>
{
 protected override Task HandleRequirementAsync(
 AuthorizationHandlerContext context,
 MinimumAgeRequirement requirement)
 {
 var dateOfBirthClaim = context.User.FindFirst("DateOfBirth");

 if (dateOfBirthClaim is null)
 return Task.CompletedTask;

 var dateOfBirth = DateOnly.Parse(dateOfBirthClaim.Value);
 var age = DateOnly.FromDateTime(DateTime.Today).Year - dateOfBirth.Year;

 if (age >= requirement.MinimumAge)
 context.Succeed(requirement);

 return Task.CompletedTask;
 }
}

Registre el controlador:

builder.Services.AddSingleton<IAuthorizationHandler, MinimumAgeHandler>();

En los componentes, también puede verificar la autorización mediante programación cuando necesite lógica dinámica:

@inject IAuthorizationService AuthorizationService
@inject AuthenticationStateProvider AuthStateProvider

@code {
 private bool canPublish;

 protected override async Task OnInitializedAsync()
 {
 var authState = await AuthStateProvider.GetAuthenticationStateAsync();
 var result = await AuthorizationService.AuthorizeAsync(
 authState.User, "CanPublish");
 canPublish = result.Succeeded;
 }
}

Proveedores externos de OAuth

Admitir “Iniciar sesión con Google” o “Iniciar sesión con GitHub” es sencillo con el middleware de autenticación ASP.NET. Estos se configuran en el lado del servidor, ya que el flujo de OAuth requiere redireccionamientos HTTP.

builder.Services.AddAuthentication()
 .AddGoogle(options =>
 {
 options.ClientId = builder.Configuration["Auth:Google:ClientId"]!;
 options.ClientSecret = builder.Configuration["Auth:Google:ClientSecret"]!;
 options.Scope.Add("profile");
 })
 .AddMicrosoftAccount(options =>
 {
 options.ClientId = builder.Configuration["Auth:Microsoft:ClientId"]!;
 options.ClientSecret = builder.Configuration["Auth:Microsoft:ClientSecret"]!;
 })
 .AddGitHub(options =>
 {
 options.ClientId = builder.Configuration["Auth:GitHub:ClientId"]!;
 options.ClientSecret = builder.Configuration["Auth:GitHub:ClientSecret"]!;
 });

Para GitHub, necesitará el paquete NuGet AspNet.Security.OAuth.GitHub, ya que no está incluido en las bibliotecas ASP.NET predeterminadas.

Luego, la interfaz de usuario de inicio de sesión proporciona enlaces que activan el desafío externo:

@page "/account/external-login"

<h2>Sign in with an external provider</h2>

<form method="post" action="/api/auth/external-login">
 <button type="submit" name="provider" value="Google">
 Sign in with Google
 </button>
 <button type="submit" name="provider" value="Microsoft">
 Sign in with Microsoft
 </button>
 <button type="submit" name="provider" value="GitHub">
 Sign in with GitHub
 </button>
</form>

El punto final de API desencadena el desafío y maneja la devolución de llamada:

app.MapPost("/api/auth/external-login", (string provider, HttpContext context) =>
{
 var properties = new AuthenticationProperties
 {
 RedirectUri = "/api/auth/external-callback"
 };
 return Results.Challenge(properties, [provider]);
});

La autenticación externa en Blazor siempre requiere una navegación de página completa; no se puede completar una redirección de OAuth dentro de un circuito SignalR o una aplicación WebAssembly sin pasar por el servidor.

Autenticación basada en tokens en Blazor WebAssemblyBlazor WebAssembly se ejecuta en el cliente, por lo que la autenticación basada en cookies no se aplica de la misma manera. En su lugar, normalmente se utilizan JWT almacenados en la memoria y adjuntos a las solicitudes HTTP salientes.

El marco proporciona AuthorizationMessageHandler para adjuntar tokens automáticamente:

builder.Services.AddHttpClient("API",
 client => client.BaseAddress = new Uri("https://api.example.com"))
 .AddHttpMessageHandler<AuthorizationMessageHandler>();

builder.Services.AddScoped(sp =>
 sp.GetRequiredService<IHttpClientFactory>().CreateClient("API"));

Para aplicaciones Blazor WASM independientes que se autentican con su propia API, implementará un AuthenticationStateProvider personalizado que analiza el JWT:

public class JwtAuthenticationStateProvider : AuthenticationStateProvider
{
 private readonly ILocalStorageService _localStorage;
 private readonly HttpClient _httpClient;

 public JwtAuthenticationStateProvider(
 ILocalStorageService localStorage,
 HttpClient httpClient)
 {
 _localStorage = localStorage;
 _httpClient = httpClient;
 }

 public override async Task<AuthenticationState> GetAuthenticationStateAsync()
 {
 var token = await _localStorage.GetItemAsync<string>("authToken");

 if (string.IsNullOrWhiteSpace(token))
 return new AuthenticationState(new ClaimsPrincipal(new ClaimsIdentity()));

 _httpClient.DefaultRequestHeaders.Authorization =
 new AuthenticationHeaderValue("Bearer", token);

 var claims = ParseClaimsFromJwt(token);
 var identity = new ClaimsIdentity(claims, "jwt");

 return new AuthenticationState(new ClaimsPrincipal(identity));
 }

 public void NotifyAuthStateChanged()
 {
 NotifyAuthenticationStateChanged(GetAuthenticationStateAsync());
 }

 private IEnumerable<Claim> ParseClaimsFromJwt(string jwt)
 {
 var payload = jwt.Split('.')[1];

 var padded = payload.Length % 4 switch
 {
 2 => payload + "==",
 3 => payload + "=",
 _ => payload
 };

 var bytes = Convert.FromBase64String(padded);
 var json = JsonSerializer.Deserialize<Dictionary<string, JsonElement>>(bytes);

 return json?.Select(kvp => new Claim(kvp.Key, kvp.Value.ToString()))
 ?? Enumerable.Empty<Claim>();
 }
}

Después de iniciar sesión correctamente, almacena el token y notifica el estado de autenticación:

public class AuthService
{
 private readonly HttpClient _httpClient;
 private readonly ILocalStorageService _localStorage;
 private readonly JwtAuthenticationStateProvider _authStateProvider;

 public AuthService(
 HttpClient httpClient,
 ILocalStorageService localStorage,
 AuthenticationStateProvider authStateProvider)
 {
 _httpClient = httpClient;
 _localStorage = localStorage;
 _authStateProvider = (JwtAuthenticationStateProvider)authStateProvider;
 }

 public async Task<bool> LoginAsync(string email, string password)
 {
 var response = await _httpClient.PostAsJsonAsync("/api/auth/login",
 new { Email = email, Password = password });

 if (!response.IsSuccessStatusCode)
 return false;

 var result = await response.Content
 .ReadFromJsonAsync<LoginResponse>();

 await _localStorage.SetItemAsync("authToken", result!.Token);
 _authStateProvider.NotifyAuthStateChanged();

 return true;
 }

 public async Task LogoutAsync()
 {
 await _localStorage.RemoveItemAsync("authToken");
 _authStateProvider.NotifyAuthStateChanged();
 }
}

Una advertencia: almacenar JWT en localStorage los expone a ataques XSS. Para aplicaciones de mayor seguridad, considere mantener los tokens solo en la memoria y usar tokens de actualización, o adoptar el patrón Backend-for-Frontend (BFF) donde el servidor administra los tokens y el cliente usa cookies solo HTTP.

Blazor Server frente a WebAssembly: consideraciones de seguridad

El modelo de alojamiento cambia fundamentalmente su postura de seguridad.

Blazor Server mantiene toda la lógica de sus componentes en el servidor. El cliente solo ve diferencias HTML renderizadas en SignalR. Esto significa:

La lógica sensible nunca abandona el servidor.
Puede acceder a bases de datos y servicios internos directamente desde los componentes.
El estado de autenticación proviene del HttpContext del servidor en la conexión inicial.
El circuito puede sobrevivir a la cookie de autenticación: si la cookie de un usuario caduca, el circuito permanece activo hasta que se desconecta.
Debe manejar la desconexión del circuito con elegancia y volver a validar el estado de autenticación al volver a conectarse.

Blazor WebAssembly se ejecuta completamente en el navegador. Esto significa:

Todo el código de su componente se puede descargar e inspeccionar.
Nunca coloque secretos, cadenas de conexión o lógica empresarial confidencial en componentes WASM
La autenticación solo se aplica al cliente para UX; la aplicación real debe ocurrir en su capa API
La gestión de tokens es tu responsabilidad.
Considere usar el modelo alojado donde un proyecto de servidor maneja la autenticación y sirve la aplicación WASM.

Un patrón que recomiendo para las aplicaciones WebAssembly es tratar cada componente como si fuera una “IU no confiable” y cada punto final de API como si lo llamara un cliente desconocido. Valide todo del lado del servidor independientemente de lo que verifique el cliente.

Creación de un proveedor de estado de autenticación personalizado

A veces, los proveedores integrados no se ajustan a su arquitectura. Tal vez se esté integrando con un sistema de autenticación heredado o necesite realizar una encuesta para detectar cambios en el estado de autenticación. Aquí hay un proveedor personalizado más completo para Blazor Server:

public class CustomAuthStateProvider : AuthenticationStateProvider
{
 private readonly IHttpContextAccessor _httpContextAccessor;
 private readonly IUserService _userService;

 public CustomAuthStateProvider(
 IHttpContextAccessor httpContextAccessor,
 IUserService userService)
 {
 _httpContextAccessor = httpContextAccessor;
 _userService = userService;
 }

 public override async Task<AuthenticationState> GetAuthenticationStateAsync()
 {
 var httpContext = _httpContextAccessor.HttpContext;

 if (httpContext?.User?.Identity?.IsAuthenticated != true)
 return new AuthenticationState(
 new ClaimsPrincipal(new ClaimsIdentity()));

 var userId = httpContext.User.FindFirstValue(ClaimTypes.NameIdentifier);

 if (userId is null)
 return new AuthenticationState(
 new ClaimsPrincipal(new ClaimsIdentity()));

 var user = await _userService.GetUserWithClaimsAsync(userId);

 if (user is null)
 return new AuthenticationState(
 new ClaimsPrincipal(new ClaimsIdentity()));

 var claims = new List<Claim>
 {
 new(ClaimTypes.NameIdentifier, user.Id),
 new(ClaimTypes.Name, user.DisplayName),
 new(ClaimTypes.Email, user.Email)
 };

 claims.AddRange(user.Roles.Select(r => new Claim(ClaimTypes.Role, r)));
 claims.AddRange(user.Permissions.Select(p => new Claim("Permission", p)));

 var identity = new ClaimsIdentity(claims, "Custom");
 return new AuthenticationState(new ClaimsPrincipal(identity));
 }

 public void MarkUserAsAuthenticated(string userId)
 {
 NotifyAuthenticationStateChanged(GetAuthenticationStateAsync());
 }

 public void MarkUserAsLoggedOut()
 {
 var anonymous = new ClaimsPrincipal(new ClaimsIdentity());
 var authState = Task.FromResult(new AuthenticationState(anonymous));
 NotifyAuthenticationStateChanged(authState);
 }
}

Regístrelo en Program.cs:

builder.Services.AddScoped<AuthenticationStateProvider, CustomAuthStateProvider>();
builder.Services.AddScoped<CustomAuthStateProvider>();

La idea clave aquí es NotifyAuthenticationStateChanged: llamarlo activa el parámetro en cascada para actualizarlo, lo que reevalúa cada AuthorizeView y AuthorizeRouteView en su árbol de componentes. Así es como hace que la interfaz de usuario reaccione a los eventos de inicio/cierre de sesión sin una actualización completa de la página.

Errores y soluciones comunes

Después de trabajar con la autenticación de Blazor en muchos proyectos, estos son los problemas que veo con más frecuencia:

1. Uso de HttpContext en los componentes del servidor Blazor`HttpContext` está disponible durante la solicitud HTTP inicial, pero está `null` o obsoleto durante las interacciones de SignalR. No inyecte `IHttpContextAccessor` en componentes que se ejecutan después del renderizado inicial.

Solución: Capture lo que necesita de HttpContext durante la inicialización y guárdelo en un servicio con alcance:

public class UserContext
{
 public string? UserId { get; set; }
 public string? AccessToken { get; set; }
}

// In a component that renders during the initial HTTP request:
@inject IHttpContextAccessor HttpContextAccessor
@inject UserContext UserContext

@code {
 protected override void OnInitialized()
 {
 var context = HttpContextAccessor.HttpContext;
 UserContext.UserId = context?.User.FindFirstValue(ClaimTypes.NameIdentifier);
 UserContext.AccessToken = context?.Request.Headers.Authorization
 .ToString().Replace("Bearer ", "");
 }
}

2. El estado de autenticación no se actualiza después de iniciar sesión

Llamas a tu API de inicio de sesión, tiene éxito, pero la interfaz de usuario todavía muestra “Iniciar sesión”.

Solución: Debes llamar a NotifyAuthenticationStateChanged en tu AuthenticationStateProvider después de que cambie el estado de autenticación. El marco no detecta mágicamente que se almacenó un token o se configuró una cookie.

3. El atributo de autorización no funciona en los componentes

Agrega [Authorize] a un componente pero no bloquea a los usuarios no autenticados.

Solución: Asegúrate de usar AuthorizeRouteView en lugar de RouteView simple en tu App.razor. El estándar RouteView ignora por completo los atributos de autorización.

4. La representación previa interrumpe el estado de autenticación

Durante la representación previa del lado del servidor en Blazor WebAssembly, no hay ningún token de autenticación disponible. Los componentes se muestran como no autenticados y luego parpadean al estado autenticado después de que se carga WASM.

Solución: Desactive la renderización previa para páginas sensibles a la autenticación con @rendermode InteractiveWebAssembly (sin renderización previa) o maneje el estado de carga con elegancia:

<AuthorizeView>
 <Authorized>
 <p>Welcome back, @context.User.Identity?.Name</p>
 </Authorized>
 <Authorizing>
 <p>Loading...</p>
 </Authorizing>
 <NotAuthorized>
 <a href="/login">Sign in</a>
 </NotAuthorized>
</AuthorizeView>

5. Caducidad del token en circuitos de larga duración

Los circuitos de Blazor Server pueden permanecer activos durante horas. Si su token o sesión caduca, el usuario permanece “autenticado” en la interfaz de usuario, pero las llamadas a la API comienzan a fallar.

Solución: Implemente una verificación periódica o use un RevalidatingServerAuthenticationStateProvider:

public class RevalidatingAuthStateProvider
 : RevalidatingServerAuthenticationStateProvider
{
 private readonly IServiceScopeFactory _scopeFactory;

 public RevalidatingAuthStateProvider(
 ILoggerFactory loggerFactory,
 IServiceScopeFactory scopeFactory)
 : base(loggerFactory)
 {
 _scopeFactory = scopeFactory;
 }

 protected override TimeSpan RevalidationInterval => TimeSpan.FromMinutes(30);

 protected override async Task<bool> ValidateAuthenticationStateAsync(
 AuthenticationState authenticationState, CancellationToken cancellationToken)
 {
 await using var scope = _scopeFactory.CreateAsyncScope();
 var userManager = scope.ServiceProvider
 .GetRequiredService<UserManager<IdentityUser>>();

 var user = await userManager.GetUserAsync(authenticationState.User);
 return user is not null;
 }
}

Esto valida que el usuario todavía existe (y que su sello de seguridad no ha cambiado) cada 30 minutos.

Conclusión

La autenticación y autorización en Blazor requieren un cambio de mentalidad respecto del tradicional ASP.NET de solicitud-respuesta. La abstracción AuthenticationStateProvider es la clave para comprender cómo encaja todo; una vez que lo interiorizas, el resto sigue de forma natural.

Para la mayoría de las aplicaciones, comience con ASP.NET Identity y las plantillas integradas. Se encargan del trabajo pesado de la administración de usuarios, el hash de contraseñas y la generación de tokens. Aumente las políticas y la autorización basada en reclamos a medida que crezcan sus requisitos. Agregue proveedores de OAuth externos cuando sus usuarios los esperen.

El modelo de alojamiento es importante: Blazor Server le ofrece una postura de seguridad más tradicional en la que el código permanece en el servidor, mientras que WebAssembly le impulsa a pensar primero en API, donde el cliente no es de confianza por diseño. Ninguno de los dos es intrínsecamente más seguro; simplemente tienen diferentes modelos de amenaza.

Cualquiera que sea el enfoque que elija, recuerde la regla de oro: la autorización en la interfaz de usuario es para la experiencia del usuario, la autorización en el servidor es para la seguridad. Siempre aplique ambas.

JavaScript aislado en Blazor con archivos JS colocados

Wed, 18 Jun 2025 00:00:00 +0000

Si ha trabajado con Blazor y JS Interop antes, probablemente haya terminado con un archivo app.js masivo lleno de funciones aleatorias para diferentes componentes. Funciona, pero se complica rápidamente. Afortunadamente, existe un enfoque mucho más claro: archivos JavaScript colocados.

La idea

Al igual que el aislamiento de CSS, Blazor le permite colocar un archivo .razor.js junto a su componente. El módulo JavaScript se carga según demanda, sólo cuando el componente realmente lo necesita. Sin guiones globales, sin contaminación.

Configurarlo

Digamos que tenemos un componente Clipboard.razor que copia texto al portapapeles. Crea un archivo llamado Clipboard.razor.js justo al lado:

export function copyToClipboard(text) {
 navigator.clipboard.writeText(text).then(() => {
 console.log("Copied to clipboard!");
 });
}

Observe la palabra clave export: esto es importante. Blazor lo carga como un módulo ES estándar.

Cargando el módulo en Blazor

En su componente, utiliza IJSRuntime para importar el módulo. La ruta sigue una convención: ./_content/{ASSEMBLY_NAME}/{COMPONENT_PATH}.razor.js para bibliotecas, o simplemente la ruta relativa para el proyecto actual.

@inject IJSRuntime JS
@implements IAsyncDisposable

<button @onclick="Copy">Copy to clipboard</button>

@code {
 [Parameter]
 public string Text { get; set; }

 private IJSObjectReference? module;

 protected override async Task OnAfterRenderAsync(bool firstRender)
 {
 if (firstRender)
 {
 module = await JS.InvokeAsync<IJSObjectReference>(
 "import", "./Components/Clipboard.razor.js");
 }
 }

 private async Task Copy()
 {
 if (module is not null)
 {
 await module.InvokeVoidAsync("copyToClipboard", Text);
 }
 }

 public async ValueTask DisposeAsync()
 {
 if (module is not null)
 {
 await module.DisposeAsync();
 }
 }
}

Algunas cosas a tener en cuenta aquí:

Cargamos el módulo en OnAfterRenderAsync porque JS Interop no está disponible durante la renderización previa del lado del servidor.
Mantenemos una referencia al módulo con IJSObjectReference
Implementamos IAsyncDisposable para limpiar el módulo cuando se destruye el componente.

Por qué esto es mejor

Antes, solía volcar todo en un solo wwwroot/js/app.js. Funcionó, pero encontrar funciones fue complicado y cada página cargaba JavaScript que no necesitaba. Con archivos JS colocados:

Cada componente posee su propio JavaScript
Los módulos se cargan de forma diferida, sólo cuando es necesario
No hay conflictos de nombres de funciones globales
Más fácil de mantener y eliminar: cuando elimina el componente, elimina el JS con él.

Un problema con el camino

La ruta que pasa a import depende de si está en una aplicación Blazor independiente o en una biblioteca de clases de Razor. Para una aplicación Blazor normal, la ruta es relativa a wwwroot. El archivo .razor.js se copia allí en el momento de la compilación, por lo que puede hacer referencia a él desde la ubicación del componente en el proyecto.

Si obtiene un error 404 al cargar el módulo, verifique la ruta y asegúrese de que el archivo termine en .razor.js, no solo en .js.

Espero que os haya gustado el post! No dudes en contactarme en cualquier red social en @emimontesdeoca.

Recursos

ASP.NET Core Blazor JavaScript con JS colocado

Interactividad Blazor en .NET 9 y .NET 10: una guía completa

Sun, 15 Jun 2025 00:00:00 +0000

Si ha estado creando aplicaciones web con Blazor durante los últimos años, sabrá que el marco ha recorrido un largo camino. Lo que comenzó como una elección entre Blazor Server y Blazor WebAssembly ha evolucionado hasta convertirse en un modelo de representación unificado y flexible que le permite elegir la estrategia de interactividad adecuada para cada componente de su aplicación.

Con .NET 8 obtuvimos el cambio fundamental: la introducción de modos de renderizado y renderizado estático del lado del servidor (SSR) como predeterminados. Ahora, .NET 9 y .NET 10 se basan en esa base con mejoras que hacen que la experiencia del desarrollador sea más fluida y la del usuario final más rápida.

En esta publicación, quiero mostrarle la imagen completa de la interactividad de Blazor tal como está hoy: cómo funcionan los modos de renderizado, qué aporta la transmisión SSR, cómo la navegación mejorada y el manejo de formularios cambian el juego, y qué hay de nuevo en los últimos lanzamientos. Si está planeando un nuevo proyecto Blazor o pensando en actualizarlo, esta es la guía que desearía tener cuando comencé a profundizar en todo esto.

Una mirada retrospectiva: cómo llegamos hasta aquí

Antes de .NET 8, había que comprometerse con un modelo de alojamiento a nivel de proyecto. Blazor Server significaba que todo se ejecutaba en el servidor a través de una conexión SignalR. Blazor WebAssembly significó que todo se ejecutara en el navegador. Cada uno tenía sus compensaciones y mezclarlas fue doloroso.

.NET 8 cambió las reglas del juego al introducir una única plantilla de proyecto (la aplicación web Blazor) que unifica ambos modelos. El concepto clave es modos de renderizado: usted decide por componente cómo debe renderizarse y dónde ocurre la interactividad. El valor predeterminado se convirtió en SSR estático, lo que significa que los componentes se procesan en el servidor y envían HTML simple al navegador: sin SignalR, sin WebAssembly, solo HTML rápido.

.NET 9 pulió estos conceptos, mejoró la experiencia del desarrollador y optimizó el rendimiento. .NET 10 va más allá con un mejor manejo de la reconexión, estado persistente de los componentes en todos los modos de renderizado y mejoras en la forma en que se entrega el script Blazor.

Analicémoslo todo.

Modos de renderizado en .NET 9

En el corazón del Blazor moderno se encuentra el concepto de modos de renderizado. Hay cuatro modos que debes conocer:

1. SSR estático (el valor predeterminado)

Cuando crea una nueva aplicación web Blazor, los componentes se representan estáticamente en el servidor de forma predeterminada. El servidor procesa el componente Razor, genera HTML y lo envía al navegador. No hay conexión persistente ni tiempo de ejecución de WebAssembly, solo solicitud/respuesta tradicional.

Esto es perfecto para páginas con mucho contenido, paneles que muestran principalmente datos o cualquier página donde no necesite interacción en tiempo real.

@page "/products"

<h1>Our Products</h1>

@foreach (var product in products)
{
 <div class="product-card">
 <h3>@product.Name</h3>
 <p>@product.Description</p>
 <span class="price">@product.Price.ToString("C")</span>
 </div>
}

@code {
 private List<Product> products = new();

 protected override async Task OnInitializedAsync()
 {
 products = await ProductService.GetAllAsync();
 }
}

Este componente se representa en el servidor, produce HTML y eso es todo. No hay conexión continua. Carga inicial rápida, excelente para SEO, uso mínimo de recursos del servidor.

2. Servidor interactivoCuando necesite interactividad en tiempo real (manejar clics en botones, procesar entradas del usuario, actualizar la interfaz de usuario dinámicamente), puede optar por el modo de servidor interactivo. Esto establece una conexión SignalR entre el navegador y el servidor, y las actualizaciones de la interfaz de usuario se realizan a través de esa conexión.

@page "/counter"
@rendermode InteractiveServer

<h1>Counter</h1>

<p>Current count: @currentCount</p>

<button class="btn btn-primary" @onclick="IncrementCount">Click me</button>

@code {
 private int currentCount = 0;

 private void IncrementCount()
 {
 currentCount++;
 }
}

La directiva @rendermode InteractiveServer es todo lo que se necesita. El componente se representa inicialmente en el servidor y luego se establece una conexión SignalR para manejar las interacciones posteriores. Sus controladores de eventos de C# se ejecutan en el servidor y las diferencias de la interfaz de usuario se envían al navegador.

Cuándo usarlo: Cuando necesita interactividad, sus componentes necesitan acceso a recursos del lado del servidor (bases de datos, API, sistemas de archivos) y desea una carga inicial rápida sin esperar a que se descargue WebAssembly.

3. Asamblea web interactiva

Si desea interactividad sin mantener una conexión al servidor, Interactive WebAssembly ejecuta la lógica de su componente directamente en el navegador utilizando el tiempo de ejecución de .NET WebAssembly.

@page "/search"
@rendermode InteractiveWebAssembly

<h1>Product Search</h1>

<input @bind="searchTerm" @bind:event="oninput" placeholder="Search products..." />

@if (filteredProducts.Any())
{
 <ul>
 @foreach (var product in filteredProducts)
 {
 <li>@product.Name — @product.Price.ToString("C")</li>
 }
 </ul>
}

@code {
 private string searchTerm = string.Empty;
 private List<Product> allProducts = new();
 private IEnumerable<Product> filteredProducts => allProducts
 .Where(p => p.Name.Contains(searchTerm, StringComparison.OrdinalIgnoreCase));

 protected override async Task OnInitializedAsync()
 {
 allProducts = await Http.GetFromJsonAsync<List<Product>>("api/products") ?? new();
 }
}

La compensación: hay un costo de descarga inicial para el tiempo de ejecución de .NET y sus ensamblados. Pero una vez cargado, el componente se ejecuta completamente en el navegador sin viajes de ida y vuelta al servidor para las interacciones de la interfaz de usuario.

Cuándo usarlo: para componentes altamente interactivos donde la latencia importa (piense: editores de texto enriquecido, herramientas de dibujo, filtrado en tiempo real), cuando desea reducir la carga del servidor o cuando está creando una aplicación web progresiva (PWA).

4. Auto interactivo

Este es el punto medio pragmático y una de mis características favoritas. Interactive Auto comienza con la representación del lado del servidor a través de SignalR para la primera carga y luego descarga silenciosamente el tiempo de ejecución de WebAssembly en segundo plano. En visitas posteriores, el componente se ejecuta en WebAssembly.

@page "/dashboard"
@rendermode InteractiveAuto

<h1>Dashboard</h1>

<DashboardWidget Title="Sales" Value="@salesTotal" />
<DashboardWidget Title="Users" Value="@activeUsers" />

<button @onclick="RefreshData">Refresh</button>

@code {
 private decimal salesTotal;
 private int activeUsers;

 protected override async Task OnInitializedAsync()
 {
 await RefreshData();
 }

 private async Task RefreshData()
 {
 var data = await DashboardService.GetSummaryAsync();
 salesTotal = data.SalesTotal;
 activeUsers = data.ActiveUsers;
 }
}

Esto le brinda lo mejor de ambos mundos: primer renderizado rápido (sin esperar la descarga de WASM) y, finalmente, el componente se ejecuta en el lado del cliente. El usuario no nota la transición.

Cuándo usarlo: Cuando desee cargas iniciales rápidas y una eventual ejecución del lado del cliente. Es una excelente opción predeterminada para muchos componentes interactivos.

Streaming SSR: Lo mejor de ambos mundos

Streaming SSR es una de esas características que suena simple pero marca una gran diferencia en el rendimiento percibido. Esta es la idea: en lugar de esperar a que se carguen todos los datos antes de enviar cualquier HTML, el servidor envía el shell de la página inmediatamente y luego transmite actualizaciones de contenido a medida que los datos están disponibles.

@page "/reports"
@attribute [StreamRendering]

<h1>Monthly Reports</h1>

@if (reports is null)
{
 <div class="loading-spinner">
 <p>Loading reports...</p>
 </div>
}
else
{
 <table class="table">
 <thead>
 <tr>
 <th>Month</th>
 <th>Revenue</th>
 <th>Growth</th>
 </tr>
 </thead>
 <tbody>
 @foreach (var report in reports)
 {
 <tr>
 <td>@report.Month</td>
 <td>@report.Revenue.ToString("C")</td>
 <td class="@(report.Growth >= 0 ? "text-success" : "text-danger")">
 @report.Growth.ToString("P1")
 </td>
 </tr>
 }
 </tbody>
 </table>
}

@code {
 private List<MonthlyReport>? reports;

 protected override async Task OnInitializedAsync()
 {
 // This might take a couple of seconds
 reports = await ReportService.GetMonthlyReportsAsync();
 }
}

Con el atributo [StreamRendering], esto es lo que sucede:

El servidor envía inmediatamente el HTML con el control giratorio de carga.
OnInitializedAsync se ejecuta y recupera los datos.
Cuando llegan los datos, el servidor transmite el HTML actualizado (la tabla) al navegador.
El navegador parchea el DOM sin recargar la página completa.

El usuario ve la página instantáneamente con un indicador de carga, luego el contenido se completa. No se necesita un marco de JavaScript. Sin conexión WebSocket. Simplemente uso inteligente de la transmisión HTTP.Cuándo usarlo: Cualquier página SSR estática que obtenga datos durante la renderización. Páginas de listado de productos, paneles de control, informes… en cualquier lugar donde la carga inicial de datos pueda tardar más de unos pocos cientos de milisegundos.

Cuándo NO usarlo: Si los datos se cargan extremadamente rápido (menos de 100 ms), la sobrecarga de transmisión no vale la pena. Además, la transmisión SSR no le brinda interactividad continua; para eso, aún necesita un modo de renderizado interactivo.

Navegación y manejo de formularios mejorados

Una de las mejoras sutiles pero poderosas del Blazor moderno es la navegación mejorada. De forma predeterminada, Blazor intercepta los clics en enlaces internos y los envíos de formularios, obteniendo el contenido de la nueva página a través de fetch y parcheando el DOM en lugar de realizar una navegación completa en el navegador.

Esto significa que navegar entre páginas SSR estáticas se siente como un SPA: no hay flash de página completa, se puede conservar la posición de desplazamiento y la experiencia es fluida como la seda.

Cómo funciona

Cuando se carga el script Blazor (blazor.web.js), intercepta automáticamente los clics en enlaces internos. En lugar de una navegación de navegador tradicional,:

Realiza una solicitud fetch a la URL de destino.
Recibe la respuesta HTML.
Fusiona el nuevo contenido en el DOM existente.
Actualiza la URL y el historial del navegador.

No tienes que hacer nada para habilitar esto; está activado de forma predeterminada. Pero puedes controlarlo:

<!-- Disable enhanced navigation for a specific link -->
<a href="/legacy-page" data-enhance-nav="false">Legacy Page</a>

<!-- Force a full page reload for external-like behavior -->
<a href="/downloads/report.pdf" data-enhance-nav="false">Download Report</a>

Manejo de formularios mejorado

Los formularios reciben el mismo tratamiento. Cuando usas EditForm o el elemento estándar <form> con el manejo de formularios de Blazor, los envíos se interceptan y manejan a través de fetch:

@page "/contact"

<EditForm Model="contactModel" OnValidSubmit="HandleSubmit" FormName="contact" Enhance>
 <DataAnnotationsValidator />

 <div class="mb-3">
 <label for="name">Name</label>
 <InputText id="name" @bind-Value="contactModel.Name" class="form-control" />
 <ValidationMessage For="() => contactModel.Name" />
 </div>

 <div class="mb-3">
 <label for="email">Email</label>
 <InputText id="email" @bind-Value="contactModel.Email" class="form-control" />
 <ValidationMessage For="() => contactModel.Email" />
 </div>

 <div class="mb-3">
 <label for="message">Message</label>
 <InputTextArea id="message" @bind-Value="contactModel.Message" class="form-control" />
 <ValidationMessage For="() => contactModel.Message" />
 </div>

 <button type="submit" class="btn btn-primary">Send</button>
</EditForm>

@code {
 [SupplyParameterFromForm]
 private ContactModel contactModel { get; set; } = new();

 private async Task HandleSubmit()
 {
 await ContactService.SubmitAsync(contactModel);
 contactModel = new ContactModel();
 }
}

El atributo Enhance en EditForm le dice a Blazor que intercepte el envío del formulario. El formulario se publica en el servidor, el servidor lo procesa y vuelve a representar la página, y el HTML actualizado se transmite, todo sin una navegación completa de la página. Parece interactivo, pero está completamente renderizado por el servidor.

Observe el atributo [SupplyParameterFromForm]: así es como Blazor vincula los datos del formulario publicados a su modelo en escenarios de SSR estáticos. Es el puente entre los postes de forma tradicionales y el modelo de componentes de Blazor.

Interactividad por página y por componente

Uno de los aspectos más poderosos del nuevo modelo es que puedes combinar modos de renderizado dentro de una sola aplicación. Su página de listado de productos puede ser SSR estática, su carrito de compras puede ser Interactive Server y su configurador de productos puede ser Interactive WebAssembly, todo en la misma aplicación.

Configuración de modos de renderizado a nivel de componente

Puede configurar el modo de renderizado directamente en un componente usando la directiva @rendermode:

@* This component is interactive via Server *@
@rendermode InteractiveServer

<h3>Live Chat</h3>
<!-- chat UI here -->

O puede configurarlo cuando utilice un componente de un padre:

@page "/product/{Id:int}"

<h1>@product?.Name</h1>
<p>@product?.Description</p>

<!-- This child component gets its own interactive render mode -->
<ProductConfigurator Product="product" @rendermode="InteractiveWebAssembly" />

<!-- This stays static -->
<ProductReviews ProductId="Id" />

@code {
 [Parameter] public int Id { get; set; }
 private Product? product;

 protected override async Task OnInitializedAsync()
 {
 product = await ProductService.GetByIdAsync(Id);
 }
}

En este ejemplo, la página en sí es SSR estática. El componente ProductConfigurator se ejecuta en WebAssembly para una rica interactividad del lado del cliente. El componente ProductReviews permanece estático porque solo muestra datos.

Configuración de modos de renderizado globalmente

Si desea que todas las páginas sean interactivas de forma predeterminada, puede configurar el modo de renderizado en el nivel raíz en App.razor:

<Routes @rendermode="InteractiveServer" />
```Esto hace que cada página sea interactiva a través de la representación del servidor. Los componentes individuales aún pueden anular esto si es necesario.

### Reglas importantes para recordar

Hay algunas limitaciones a tener en cuenta al mezclar modos de renderizado:

- **Un componente hijo no puede tener un modo de renderizado "más interactivo" que su padre.** Si un componente padre es estático, los hijos pueden ser estáticos o interactivos. Pero si un padre es Interactive Server, un hijo no puede ser Interactive WebAssembly (tendría que ser Server o Auto).
- **Los componentes interactivos no pueden usar directamente servicios con alcance de padres estáticos.** Si un componente se ejecuta en WebAssembly, no puede acceder directamente a las instancias `DbContext` del lado del servidor; necesitará una capa API.
- **El estado no se transfiere automáticamente entre modos de renderizado.** Si un componente se prerenderiza en el servidor y luego cambia a WebAssembly, debe manejar la persistencia del estado explícitamente; más sobre esto en la sección .NET 10.

## Novedades de .NET 10

.NET 10 continúa con el enfoque de mejora incremental, centrándose en la confiabilidad y la experiencia del desarrollador. Estos son los aspectos más destacados de la interactividad de Blazor:

### Experiencia de reconexión mejorada

Si ha utilizado el modo de servidor interactivo en producción, probablemente haya encontrado la superposición de reconexión: ese momento en el que se interrumpe la conexión de SignalR y el usuario ve el mensaje "Reconectando...". En .NET 10, esta experiencia mejora significativamente.

La lógica de reconexión ahora es más inteligente en cuanto a reintentar. En lugar de un intervalo de reintento fijo, utiliza una estrategia de retroceso que se adapta a la situación. La interfaz de usuario durante la reconexión también está más pulida y tienes mejores opciones para personalizar la experiencia:

```razor
<!-- In your App.razor or layout -->
<div id="components-reconnect-modal">
 <div class="reconnect-visible">
 <p>Connection lost. Attempting to reconnect...</p>
 <div class="spinner"></div>
 </div>
 <div class="reconnect-failed">
 <p>Could not reconnect to the server.</p>
 <button onclick="location.reload()">Reload</button>
 </div>
 <div class="reconnect-rejected">
 <p>Your session has expired.</p>
 <a href="/">Return to Home</a>
 </div>
</div>

El marco ahora también intenta la reconexión de manera más agresiva en caso de fallas transitorias y puede restaurar el estado del circuito de manera más confiable. Esto significa menos momentos de “recargar la página” para sus usuarios.

Estado de componente persistente en todos los modos de renderizado

Este es uno grande. En .NET 9, cuando un componente se renderiza previamente en el servidor y luego pasa a WebAssembly (o cambia entre modos de renderizado), el estado del componente se pierde. El componente se reinicia de manera efectiva, lo que puede generar búsquedas de datos duplicadas y una interfaz de usuario parpadeante.

.NET 10 mejora el servicio PersistentComponentState para que funcione de manera más fluida en las transiciones del modo de renderizado:

@page "/weather"
@rendermode InteractiveWebAssembly
@inject PersistentComponentState ApplicationState

<h1>Weather Forecast</h1>

@if (forecasts is null)
{
 <p>Loading...</p>
}
else
{
 @foreach (var forecast in forecasts)
 {
 <div class="forecast-card">
 <h4>@forecast.Date.ToShortDateString()</h4>
 <p>@forecast.Summary — @forecast.TemperatureC°C</p>
 </div>
 }
}

@code {
 private List<WeatherForecast>? forecasts;
 private PersistingComponentStateSubscription persistingSubscription;

 protected override async Task OnInitializedAsync()
 {
 persistingSubscription = ApplicationState.RegisterOnPersisting(PersistData);

 if (!ApplicationState.TryTakeFromJson<List<WeatherForecast>>(
 "weather-forecasts", out var restored))
 {
 // Data wasn't persisted from prerendering — fetch it
 forecasts = await Http.GetFromJsonAsync<List<WeatherForecast>>("api/weather");
 }
 else
 {
 forecasts = restored;
 }
 }

 private Task PersistData()
 {
 ApplicationState.PersistAsJson("weather-forecasts", forecasts);
 return Task.CompletedTask;
 }

 public void Dispose()
 {
 persistingSubscription.Dispose();
 }
}

Con las mejoras en .NET 10, este patrón funciona de manera más confiable. El estado serializado durante la renderización previa está disponible correctamente cuando el componente se inicializa en su modo interactivo, lo que evita la doble obtención de datos y el breve parpadeo que los usuarios pueden ver.

Blazor Script como activo web estático

En versiones anteriores, el archivo JavaScript de Blazor (blazor.web.js) se entregaba desde el punto final interno del marco. En .NET 10, se entrega como un recurso web estático. Esto puede parecer un pequeño cambio, pero tiene beneficios prácticos:- Mejor almacenamiento en caché: Los recursos web estáticos obtienen encabezados de caché adecuados y URL con huellas digitales, por lo que los navegadores los almacenan en caché de manera más efectiva.

Compatible con CDN: Dado que es un archivo estático normal, las CDN pueden almacenarlo en caché y servirlo desde ubicaciones perimetrales.
Compresión: La compresión estática de recursos web se aplica automáticamente, lo que reduce el tamaño del script en la conexión.

No es necesario cambiar la forma en que se hace referencia a él: el marco maneja la ruta actualizada automáticamente.

Mejores prácticas: elegir el modo de renderizado correcto

Después de trabajar con todos estos modos en varios proyectos, aquí está mi marco de decisión:

Comience con SSR estático

Haga que SSR estático sea su valor predeterminado. La mayoría de las páginas en la mayoría de las aplicaciones tratan principalmente de mostrar datos. Páginas de productos, publicaciones de blogs, perfiles de usuario, páginas de configuración: no necesitan interactividad en tiempo real. Static SSR le brinda el mejor rendimiento, el menor uso de recursos y el modelo mental más simple.

Agregue interactividad solo donde sea necesario

Identifique los componentes específicos que deben responder a las interacciones del usuario en tiempo real. Un botón “Me gusta”, un widget de chat, una interfaz de arrastrar y soltar: todo esto necesita interactividad. Pero la página que los rodea probablemente no sea así.

Utilice el modo interactivo automático como modo interactivo de acceso

Cuando necesita interactividad, Interactive Auto suele ser la mejor opción predeterminada. Le brinda cargas iniciales rápidas (renderizado del servidor) con eventual ejecución del lado del cliente (WebAssembly). El usuario obtiene lo mejor de ambos mundos y usted escribe su código una vez.

Reservar servidor interactivo para casos específicos

Utilice Interactive Server cuando:

Su componente necesita acceso directo a los recursos del servidor (bases de datos, sistema de archivos, API internas).
El tamaño de descarga de WebAssembly es un problema y no se puede utilizar Auto.
Necesita que el componente se ejecute siempre en el servidor por razones de seguridad (por ejemplo, procesamiento de datos confidenciales).

Utilice Streaming SSR generosamente

Si sus páginas SSR estáticas obtienen algún dato, agregue [StreamRendering]. El coste es mínimo y la mejora percibida en el rendimiento es significativa. Los usuarios ven que el contenido aparece progresivamente en lugar de mirar una página en blanco.

Maneje las transiciones de estado con cuidado

Si utiliza Interactive Auto o combina el renderizado previo con WebAssembly, utilice siempre PersistentComponentState para evitar recuperaciones de datos duplicadas. Tus usuarios te agradecerán la ausencia de contenido parpadeante.

Tenga en cuenta el árbol de componentes

Recuerde las reglas de jerarquía del modo de renderizado. Planifique su árbol de componentes para que los límites interactivos tengan sentido. Un patrón común es tener un diseño estático con “islas” interactivas integradas donde sea necesario:

@* Layout: Static SSR *@
<header>
 <NavMenu />
 <UserMenu @rendermode="InteractiveServer" /> @* Needs real-time auth state *@
</header>

<main>
 @Body
</main>

<footer>
 <ChatWidget @rendermode="InteractiveAuto" /> @* Rich interactivity *@
</footer>

Conclusión

El modelo de interactividad de Blazor en .NET 9 y .NET 10 representa un enfoque maduro y bien pensado para crear aplicaciones web. La capacidad de elegir modos de renderizado por componente, la navegación mejorada y fluida, la transmisión SSR y las mejoras continuas en la reconexión y la gestión del estado lo convierten en una opción convincente para una amplia gama de aplicaciones.La idea clave es que la interactividad es un espectro, no una elección binaria. La mayor parte de su aplicación puede ser estática. Algunas partes necesitan interactividad impulsada por el servidor. Algunos podrían beneficiarse si se ejecutan en el navegador. Blazor ahora le permite tomar esa decisión con la granularidad más fina (el componente individual) sin tener que luchar contra el marco.

Si está iniciando un nuevo proyecto, mi consejo es simple: cree una aplicación web Blazor, comience con SSR estático, agregue [StreamRendering] a páginas con muchos datos y promueva componentes individuales a modos interactivos solo cuando los necesite. Terminará con una aplicación que es rápida, eficiente y escalable bien.

Feliz codificación y, como siempre, no dudes en comunicarte con nosotros si tienes preguntas.

API mínimas en .NET: creación de API HTTP ligeras

Thu, 10 Apr 2025 00:00:00 +0000

Si ha estado creando API con ASP.NET Core durante algún tiempo, probablemente esté muy familiarizado con el enfoque basado en controladores: cree una clase de controlador, decórela con atributos, inyecte sus servicios a través del constructor y conecte sus rutas. Funciona, y funciona bien, pero a veces parece que estás escribiendo mucha ceremonia sobre lo que equivale a “aceptar esta solicitud, hacer algo, devolver una respuesta”.

Ese es exactamente el problema que las API mínimas se propusieron resolver. Introducidas en .NET 6, las API mínimas le permiten definir puntos finales HTTP con muy poco texto repetitivo. Sin controladores, sin atributos, sin malabarismos con las clases de inicio: solo asignaciones directas de ruta a controlador en un estilo limpio y funcional.

En esta publicación quiero explicarle todo lo que necesita saber sobre las API mínimas: desde su primer punto final hasta la organización de aplicaciones grandes, el manejo de la autenticación, la validación, los documentos OpenAPI y las consideraciones de rendimiento. Vayamos a ello.

¿Por qué API mínimas?

Antes de comenzar, hablemos de por qué elegirías API mínimas en lugar del enfoque tradicional basado en controladores.

Los controladores son excelentes cuando necesitas un marco estructurado y obstinado. Le brindan vinculación de modelos, filtros, negociación de contenido y una separación clara de inquietudes listas para usar. Para aplicaciones empresariales grandes con docenas de desarrolladores, la coherencia que imponen los controladores puede ser un beneficio real.

API mínimas, por otro lado, brillan cuando quieras:

Menos texto repetitivo: sin clases de controlador, sin atributos [ApiController], sin configuración de inicio separada.
Inicio más rápido: menos operaciones basadas en reflexión en el momento del arranque.
Modelo mental más simple: una ruta se asigna directamente a un controlador. Eso es todo.
Compatible con microservicios: cuando su API tiene entre 5 y 10 puntos finales, una configuración completa del controlador puede parecer excesiva.

La buena noticia es que no se trata de una decisión de uno u otro. Puede combinar controladores y API mínimas en el mismo proyecto. Pero una vez que se sienta cómodo con el enfoque mínimo, es posible que se encuentre recurriendo a él con más frecuencia de lo esperado.

Empezando

Creemos una API mínima desde cero. Si tiene instalado el SDK de .NET, es tan simple como:

dotnet new web -n MyMinimalApi
cd MyMinimalApi

Esto te da un Program.cs que se parece a esto:

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

app.MapGet("/", () => "Hello World!");

app.Run();

Eso es todo. Esa es una API que funciona. Sin Startup.cs, sin clase de controlador, sin configuración de enrutamiento. Ejecutas dotnet run, presionas http://localhost:5000 y obtienes “¡Hola mundo!” atrás. La simplicidad aquí es el punto.

Hagámoslo un poco más útil con una API de tareas clásica:

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

var todos = new List<Todo>();

app.MapGet("/todos", () => todos);

app.MapGet("/todos/{id:int}", (int id) =>
 todos.FirstOrDefault(t => t.Id == id) is { } todo
 ? Results.Ok(todo)
 : Results.NotFound());

app.MapPost("/todos", (Todo todo) =>
{
 todos.Add(todo);
 return Results.Created($"/todos/{todo.Id}", todo);
});

app.MapDelete("/todos/{id:int}", (int id) =>
{
 var todo = todos.FirstOrDefault(t => t.Id == id);
 if (todo is null) return Results.NotFound();
 todos.Remove(todo);
 return Results.NoContent();
});

app.Run();

record Todo(int Id, string Title, bool IsComplete);

Tenemos CRUD completo en menos de 30 líneas. Ése es el poder del enfoque minimalista.

Controladores de ruta

Los controladores de ruta son las funciones que se ejecutan cuando una solicitud coincide con una ruta. Tienes varias opciones para definirlos.

Expresiones Lambda

El enfoque más común y lo que verá en la mayoría de los ejemplos:

app.MapGet("/hello", () => "Hello!");
app.MapGet("/hello/{name}", (string name) => $"Hello, {name}!");

Grupos de métodos

Para una lógica más compleja, puede señalar un método con nombre:

app.MapGet("/products", GetProducts);
app.MapPost("/products", CreateProduct);

static IResult GetProducts(AppDbContext db)
 => Results.Ok(db.Products.ToList());

static IResult CreateProduct(Product product, AppDbContext db)
{
 db.Products.Add(product);
 db.SaveChanges();
 return Results.Created($"/products/{product.Id}", product);
}
```Este es mi enfoque preferido para cualquier cosa más allá de una sola línea. Mantiene la sección de mapeo de rutas limpia y legible: puede ver de un vistazo qué puntos finales existen sin tener que revisar los detalles de implementación.

### Funciones locales

También puedes usar funciones locales, lo cual es útil cuando deseas mantener los controladores cerca de sus definiciones de ruta:

```csharp
app.MapGet("/health", CheckHealth);

IResult CheckHealth()
{
 // Some health check logic
 return Results.Ok(new { Status = "Healthy", Timestamp = DateTime.UtcNow });
}

Enlace de parámetros

Una de las cosas que realmente aprecio de las API mínimas es lo intuitivo que es el enlace de parámetros. El marco determina de dónde extraer valores según el contexto y el tipo.

Parámetros de ruta

app.MapGet("/users/{id:int}", (int id) => $"User {id}");
app.MapGet("/files/{*path}", (string path) => $"File: {path}"); // catch-all

Parámetros de cadena de consulta

app.MapGet("/search", (string? query, int page = 1, int pageSize = 20) =>
 Results.Ok(new { query, page, pageSize }));

Los tipos que aceptan valores NULL se convierten en parámetros opcionales. Los valores predeterminados funcionan exactamente como cabría esperar.

Cuerpo de solicitud

app.MapPost("/orders", (Order order) =>
{
 // 'order' is automatically deserialized from the JSON body
 return Results.Created($"/orders/{order.Id}", order);
});

Encabezado y enlace de servicio

app.MapGet("/protected", (
 [FromHeader(Name = "X-Api-Key")] string apiKey,
 [FromServices] ILogger<Program> logger) =>
{
 logger.LogInformation("Request with API key: {Key}", apiKey[..4] + "****");
 return Results.Ok("Authorized");
});

HttpContext y HttpRequest

Cuando necesita acceso de nivel inferior:

app.MapGet("/info", (HttpContext context) =>
{
 var userAgent = context.Request.Headers.UserAgent.ToString();
 var ip = context.Connection.RemoteIpAddress?.ToString();
 return Results.Ok(new { userAgent, ip });
});

Enlace personalizado con BindAsync

Para tipos complejos, puede implementar un método BindAsync estático:

public record PaginationParams(int Page, int PageSize)
{
 public static ValueTask<PaginationParams?> BindAsync(HttpContext context)
 {
 int.TryParse(context.Request.Query["page"], out var page);
 int.TryParse(context.Request.Query["pageSize"], out var pageSize);

 var result = new PaginationParams(
 Page: page > 0 ? page : 1,
 PageSize: pageSize > 0 ? Math.Min(pageSize, 100) : 20
 );

 return ValueTask.FromResult<PaginationParams?>(result);
 }
}

app.MapGet("/items", (PaginationParams pagination, AppDbContext db) =>
{
 var items = db.Items
 .Skip((pagination.Page - 1) * pagination.PageSize)
 .Take(pagination.PageSize)
 .ToList();

 return Results.Ok(items);
});

Esto es increíblemente poderoso. Usted define la lógica de enlace una vez y la reutiliza en todos sus puntos finales.

Validación

Un área en la que las API mínimas no ofrecen tanto en comparación con los controladores es la validación de modelos. No hay aplicación automática de [Required] o [StringLength]. Pero existen patrones claros para manejarlo.

Validación manual

El enfoque más simple: simplemente validar en el controlador:

app.MapPost("/users", (CreateUserRequest request) =>
{
 if (string.IsNullOrWhiteSpace(request.Email))
 return Results.BadRequest(new { Error = "Email is required" });

 if (request.Name?.Length > 100)
 return Results.BadRequest(new { Error = "Name must be 100 characters or less" });

 // Create user...
 return Results.Created($"/users/{request.Email}", request);
});

Usando una biblioteca de validación

Para cualquier cosa que no sea trivial, recomiendo buscar FluentValidation o una biblioteca similar:

public class CreateUserValidator : AbstractValidator<CreateUserRequest>
{
 public CreateUserValidator()
 {
 RuleFor(x => x.Email).NotEmpty().EmailAddress();
 RuleFor(x => x.Name).NotEmpty().MaximumLength(100);
 RuleFor(x => x.Age).InclusiveBetween(0, 150);
 }
}

Puede conectar esto a sus puntos finales a través de filtros de puntos finales, lo que nos lleva a la siguiente sección.

Filtros de terminales

Los filtros de punto final son una de las mejores características de las API mínimas. Piense en ellos como middleware, pero dirigidos a puntos finales específicos en lugar de a todo el proceso. Se introdujeron en .NET 7 y son fantásticos para cuestiones transversales.

Filtro básico

app.MapPost("/todos", (Todo todo) =>
{
 // Handle the request
 return Results.Created($"/todos/{todo.Id}", todo);
})
.AddEndpointFilter(async (context, next) =>
{
 var todo = context.GetArgument<Todo>(0);

 if (string.IsNullOrEmpty(todo.Title))
 {
 return Results.BadRequest(new { Error = "Title is required" });
 }

 return await next(context);
});

Filtro de validación con FluentValidation

Aquí es donde se vuelve realmente poderoso: un filtro de validación reutilizable:

public class ValidationFilter<T> : IEndpointFilter where T : class
{
 private readonly IValidator<T> _validator;

 public ValidationFilter(IValidator<T> validator)
 {
 _validator = validator;
 }

 public async ValueTask<object?> InvokeAsync(
 EndpointFilterInvocationContext context,
 EndpointFilterDelegate next)
 {
 var model = context.Arguments
 .OfType<T>()
 .FirstOrDefault();

 if (model is null)
 return Results.BadRequest(new { Error = "Request body is required" });

 var result = await _validator.ValidateAsync(model);

 if (!result.IsValid)
 {
 var errors = result.Errors
 .GroupBy(e => e.PropertyName)
 .ToDictionary(g => g.Key, g => g.Select(e => e.ErrorMessage).ToArray());

 return Results.ValidationProblem(errors);
 }

 return await next(context);
 }
}

// Usage
app.MapPost("/users", (CreateUserRequest request) =>
{
 // Only reached if validation passes
 return Results.Created($"/users/{request.Email}", request);
})
.AddEndpointFilter<ValidationFilter<CreateUserRequest>>();

Filtro de registro

app.MapGet("/products", (AppDbContext db) => db.Products.ToList())
 .AddEndpointFilter(async (context, next) =>
 {
 var logger = context.HttpContext
 .RequestServices.GetRequiredService<ILogger<Program>>();

 var sw = Stopwatch.StartNew();
 var result = await next(context);
 sw.Stop();

 logger.LogInformation("Endpoint executed in {Elapsed}ms", sw.ElapsedMilliseconds);

 return result;
 });

Puede encadenar varios filtros y se ejecutan en el orden en que se agregan, como el middleware.

Integración OpenAPI/Swagger

Una buena documentación API ya no es opcional. Afortunadamente, las API Minimal tienen soporte de primera clase para OpenAPI a través del paquete Microsoft.AspNetCore.OpenApi.

Configuración básica

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddOpenApi();

var app = builder.Build();

app.MapOpenApi();

app.MapGet("/todos", () => new List<Todo>())
 .WithName("GetTodos")
 .WithDescription("Retrieves all todo items")
 .WithTags("Todos");

app.Run();

Metadatos enriquecidos de terminales

Puede proporcionar información detallada sobre sus puntos finales:

app.MapPost("/todos", (Todo todo) =>
{
 return Results.Created($"/todos/{todo.Id}", todo);
})
.WithName("CreateTodo")
.WithDescription("Creates a new todo item")
.WithTags("Todos")
.Accepts<Todo>("application/json")
.Produces<Todo>(StatusCodes.Status201Created)
.Produces(StatusCodes.Status400BadRequest)
.ProducesValidationProblem();

Uso de WithOpenApi para personalización

Para un control detallado sobre el documento OpenAPI generado:

app.MapGet("/todos/{id:int}", (int id) => Results.Ok(new Todo(id, "Sample", false)))
 .WithOpenApi(operation =>
 {
 operation.Summary = "Get a specific todo";
 operation.Description = "Retrieves a single todo item by its unique identifier.";
 operation.Parameters[0].Description = "The unique identifier of the todo item";
 return operation;
 });

Esto le brinda el mismo nivel de control de documentación que obtendría con los comentarios XML de Swashbuckle en los controladores, pero de una manera más explícita, con código primero.

Autenticación y autorización

La protección de puntos finales de API mínima sigue los mismos patrones que el resto de ASP.NET Core; simplemente los aplica de manera diferente.

Configuración básica```csharp

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme) .AddJwtBearer(options => { options.Authority = “https://your-identity-provider.com”; options.Audience = “your-api”; });

builder.Services.AddAuthorizationBuilder() .AddPolicy(“AdminOnly”, policy => policy.RequireRole(“Admin”)) .AddPolicy(“PremiumUser”, policy => policy.RequireClaim(“subscription”, “premium”));

var app = builder.Build();

app.UseAuthentication(); app.UseAuthorization();


### Aplicación de autorización a puntos finales

```csharp
// Require any authenticated user
app.MapGet("/profile", (ClaimsPrincipal user) =>
{
 return Results.Ok(new
 {
 Name = user.FindFirstValue(ClaimTypes.Name),
 Email = user.FindFirstValue(ClaimTypes.Email)
 });
}).RequireAuthorization();

// Require a specific policy
app.MapDelete("/admin/users/{id}", (int id) =>
{
 // Delete user logic
 return Results.NoContent();
}).RequireAuthorization("AdminOnly");

// Allow anonymous access
app.MapGet("/public/health", () => Results.Ok(new { Status = "Healthy" }))
 .AllowAnonymous();

Observe cómo puede inyectar ClaimsPrincipal directamente en los parámetros de su controlador: el marco se encarga del resto. Esta es una de esas pequeñas cosas que hace que las API mínimas parezcan realmente elegantes.

Organización de API grandes

El elefante en la sala con API mínimas es la organización. Cuando tu Program.cs tiene 50 puntos finales, se vuelve un desastre. Estos son los patrones que uso para mantener las cosas manejables.

Grupos de rutas

Los grupos de rutas (introducidos en .NET 7) le permiten compartir la configuración entre puntos finales relacionados:

var todos = app.MapGroup("/todos")
 .WithTags("Todos")
 .RequireAuthorization();

todos.MapGet("/", (AppDbContext db) => db.Todos.ToListAsync());
todos.MapGet("/{id:int}", (int id, AppDbContext db) => db.Todos.FindAsync(id));
todos.MapPost("/", (Todo todo, AppDbContext db) =>
{
 db.Todos.Add(todo);
 db.SaveChangesAsync();
 return Results.Created($"/todos/{todo.Id}", todo);
});

Todos los puntos finales del grupo comparten el prefijo /todos, la etiqueta Todos y el requisito de autorización. Limpio.

Métodos de extensión

Este es el patrón que realmente escala. Mueva cada grupo de puntos finales a su propia clase estática:

// Endpoints/TodoEndpoints.cs
public static class TodoEndpoints
{
 public static RouteGroupBuilder MapTodoEndpoints(this WebApplication app)
 {
 var group = app.MapGroup("/todos").WithTags("Todos");

 group.MapGet("/", GetAll);
 group.MapGet("/{id:int}", GetById);
 group.MapPost("/", Create);
 group.MapPut("/{id:int}", Update);
 group.MapDelete("/{id:int}", Delete);

 return group;
 }

 private static async Task<IResult> GetAll(AppDbContext db)
 => Results.Ok(await db.Todos.ToListAsync());

 private static async Task<IResult> GetById(int id, AppDbContext db)
 => await db.Todos.FindAsync(id) is { } todo
 ? Results.Ok(todo)
 : Results.NotFound();

 private static async Task<IResult> Create(Todo todo, AppDbContext db)
 {
 db.Todos.Add(todo);
 await db.SaveChangesAsync();
 return Results.Created($"/todos/{todo.Id}", todo);
 }

 private static async Task<IResult> Update(int id, Todo updated, AppDbContext db)
 {
 var todo = await db.Todos.FindAsync(id);
 if (todo is null) return Results.NotFound();

 todo.Title = updated.Title;
 todo.IsComplete = updated.IsComplete;
 await db.SaveChangesAsync();

 return Results.Ok(todo);
 }

 private static async Task<IResult> Delete(int id, AppDbContext db)
 {
 var todo = await db.Todos.FindAsync(id);
 if (todo is null) return Results.NotFound();

 db.Todos.Remove(todo);
 await db.SaveChangesAsync();

 return Results.NoContent();
 }
}

// Program.cs — stays clean
var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

app.MapTodoEndpoints();
app.MapUserEndpoints();
app.MapOrderEndpoints();

app.Run();

Tu Program.cs se convierte en una tabla de contenidos para tu API. Cada grupo de puntos finales vive en su propio archivo. Este es el enfoque que recomiendo para aplicaciones de producción.

La biblioteca Carter

Si desea aún más estructura, la biblioteca Carter proporciona un enfoque basado en módulos:

public class TodoModule : ICarterModule
{
 public void AddRoutes(IEndpointRouteBuilder app)
 {
 app.MapGet("/todos", async (AppDbContext db) =>
 await db.Todos.ToListAsync());

 app.MapPost("/todos", async (Todo todo, AppDbContext db) =>
 {
 db.Todos.Add(todo);
 await db.SaveChangesAsync();
 return Results.Created($"/todos/{todo.Id}", todo);
 });
 }
}

Carter descubre y registra automáticamente todos los módulos. Es un buen punto medio entre el enfoque de API minimalista y los controladores completos.

Resultados escritos y tipos de respuesta

A partir de .NET 7, puede usar TypedResults en lugar de Results para respuestas con seguridad de escritura. Esto puede parecer un pequeño cambio, pero tiene beneficios reales para la documentación y la capacidad de prueba de OpenAPI.

app.MapGet("/todos/{id:int}", async Task<Results<Ok<Todo>, NotFound>> (int id, AppDbContext db) =>
{
 var todo = await db.Todos.FindAsync(id);
 return todo is not null
 ? TypedResults.Ok(todo)
 : TypedResults.NotFound();
});

El tipo de retorno Results<Ok<Todo>, NotFound> le dice explícitamente al marco (y a sus documentos OpenAPI) exactamente qué tipos de respuesta puede producir este punto final. No más conjeturas, no más llamadas manuales Produces<>() para casos básicos.

Para múltiples resultados posibles:

app.MapPost("/todos",
 async Task<Results<Created<Todo>, ValidationProblem, Conflict>>
 (Todo todo, AppDbContext db) =>
{
 if (string.IsNullOrEmpty(todo.Title))
 return TypedResults.ValidationProblem(
 new Dictionary<string, string[]>
 {
 { "Title", new[] { "Title is required" } }
 });

 if (await db.Todos.AnyAsync(t => t.Title == todo.Title))
 return TypedResults.Conflict();

 db.Todos.Add(todo);
 await db.SaveChangesAsync();

 return TypedResults.Created($"/todos/{todo.Id}", todo);
});

Empecé a usar TypedResults en todos los proyectos nuevos. El compilador detecta discrepancias entre los tipos de devolución declarados y lo que realmente devuelve, lo que elimina toda una clase de sorpresas en tiempo de ejecución.

Consideraciones de rendimiento

Uno de los puntos de venta de las API mínimas es el rendimiento, y vale la pena entender por qué son más rápidas.

Reducción de la sobrecarga de inicio. Los controladores dependen en gran medida de la reflexión para descubrir puntos finales, vincular modelos y aplicar filtros. Las API mínimas utilizan generadores de código fuente (a partir de .NET 7) para generar código vinculante en tiempo de compilación. Esto significa menos trabajo al inicio y menos asignación de memoria por solicitud.

Sin canalización MVC. Las API basadas en controladores pasan por la canalización MVC completa: selección de acciones, enlace de modelos, filtros de acciones, ejecución de resultados. Las API mínimas omiten todo eso y pasan directamente del enrutamiento a su controlador.

Compilación de RequestDelegate. El marco compila sus expresiones lambda en instancias RequestDelegate optimizadas. El código resultante es muy parecido a lo que escribirías a mano si estuvieras trabajando directamente con HttpContext.

A continuación se ofrecen algunos consejos prácticos para maximizar el rendimiento:

// Use AsNoTracking for read-only queries
app.MapGet("/products", async (AppDbContext db) =>
 await db.Products.AsNoTracking().ToListAsync());

// Return results directly — avoid unnecessary allocations
app.MapGet("/count", async (AppDbContext db) =>
 await db.Products.CountAsync());

// Use cancellation tokens for long-running operations
app.MapGet("/report", async (AppDbContext db, CancellationToken ct) =>
 await db.Orders
 .AsNoTracking()
 .GroupBy(o => o.Status)
 .Select(g => new { Status = g.Key, Count = g.Count() })
 .ToListAsync(ct));
```También vale la pena mencionar que la brecha de rendimiento entre los controladores y las API mínimas sigue reduciéndose con cada versión de .NET. Para la mayoría de las aplicaciones, la diferencia no será su cuello de botella: las consultas a la base de datos y las llamadas de servicios externos sí lo serán. Elija según la experiencia del desarrollador y las necesidades del proyecto, no según los puntos de referencia.

## Conclusión

Las API mínimas han recorrido un largo camino desde su introducción en .NET 6. Lo que comenzó como una función de demostración de "hola mundo" ha madurado hasta convertirse en una opción legítima para las API de producción. Con filtros de puntos finales, grupos de rutas, resultados escritos y una sólida compatibilidad con OpenAPI, tiene todo lo que necesita para crear servicios bien estructurados y fáciles de mantener.

¿Mi recomendación? Si está iniciando un nuevo proyecto de API, especialmente un microservicio o una API interna enfocada, pruebe seriamente las API mínimas. Utilice el patrón del método de extensión para la organización, apóyese en los filtros de punto final para inquietudes transversales y aproveche `TypedResults` para la seguridad de tipos.

Para los proyectos existentes basados en controladores, no hay prisa por migrar. Ambos enfoques funcionan bien e incluso puedes usarlos uno al lado del otro. Pero la próxima vez que necesite agregar un pequeño servicio o una API interna rápida, omita los controladores y opte por el mínimo. Quizás no regreses.

¡Feliz codificación!

Usando CSS aislado en componentes Blazor

Wed, 12 Mar 2025 00:00:00 +0000

Una cosa que siempre me molestó cuando trabajaba con Blazor fue lo fácil que era romper estilos accidentalmente entre componentes. Agregabas una clase en un componente y de repente algo más en una página completamente diferente parecía fuera de lugar. Resulta que Blazor tiene una solución integrada para esto: el aislamiento de CSS.

¿Qué es el aislamiento CSS?

El aislamiento de CSS le permite aplicar estilos a un componente específico. Blazor hace esto generando un atributo único para cada componente en el momento de la compilación y agregándolo a los selectores de CSS. Entonces tus estilos sólo se aplican al componente al que pertenecen.

No hay necesidad de nombrar BEM, no hay necesidad de locos trucos de especificidad. Simplemente CSS limpio y con alcance.

Cómo usarlo

Digamos que tienes un componente llamado Card.razor:

<div class="card">
 <h3 class="card-title">@Title</h3>
 <p class="card-body">@ChildContent</p>
</div>

@code {
 [Parameter]
 public string Title { get; set; }

 [Parameter]
 public RenderFragment ChildContent { get; set; }
}

Para agregar estilos aislados, simplemente crea un archivo con el mismo nombre pero con la extensión .razor.css. En este caso: Card.razor.css.

.card {
 border: 1px solid var(--color-border);
 border-radius: 8px;
 padding: 1rem;
 background: var(--color-bg-secondary);
}

.card-title {
 font-size: 1.1rem;
 font-weight: 600;
 margin-bottom: 0.5rem;
}

.card-body {
 color: var(--color-text-secondary);
 font-size: 0.9rem;
}

¡Y eso es todo! Blazor lo seleccionará automáticamente y aplicará esos estilos únicamente al componente Card. Si tienes otra clase .card en otro lugar, no se verá afectada.

Cómo funciona bajo el capó

Cuando crea su proyecto, Blazor reescribe el HTML y CSS. Su componente obtiene un atributo único como b-3x8qz7k2f1, y los selectores CSS obtienen ese atributo agregado:

.card[b-3x8qz7k2f1] {
 border: 1px solid var(--color-border);
 /* ... */
}

El paquete CSS generado se sirve como {ProjectName}.styles.css. Asegúrate de tener esto en tu index.html o _Host.cshtml:

<link href="YourApp.styles.css" rel="stylesheet" />

Si te falta ese enlace, tus estilos aislados no aparecerán y pasarás 30 minutos preguntándote qué está pasando. Créame, he estado allí.

Apuntando a elementos secundarios

Una cosa a tener en cuenta es que, de forma predeterminada, el CSS aislado solo se aplica a los elementos del componente actual. Si desea aplicar estilo a elementos dentro de un componente secundario, necesita el combinador ::deep:

::deep .child-element {
 color: red;
}

Esto le indica a Blazor que también aplique el estilo a elementos coincidentes dentro de componentes secundarios. Bastante útil cuando tienes un componente contenedor que necesita darle estilo a sus hijos.

Cuando usarlo

Ahora uso aislamiento CSS para casi todos los componentes. Mantiene las cosas limpias y predecibles. La única vez que no lo uso es para estilos verdaderamente globales como restablecimientos, tipografía o variables de tema; estos van en un archivo CSS compartido.

Espero que os haya gustado el post! No dudes en contactarme en cualquier red social en @emimontesdeoca.

Recursos

Aislamiento CSS de ASP.NET Core Blazor

Controlar el gasto navideño con Semantic Kernel

Sat, 28 Dec 2024 00:00:00 +0000

## Introducción

A medida que se acerca la temporada navideña, administrar los gastos puede convertirse en un desafío, especialmente con la avalancha de compras y regalos. En esta publicación de blog, exploraremos cómo aprovechar la inteligencia artificial para ayudarlo a realizar un seguimiento de sus gastos navideños utilizando tecnologías .NET. Al analizar los recibos con el poder del kernel semántico y la IA, podemos extraer de manera eficiente detalles clave como nombres de tiendas, fechas, listas de artículos y montos totales. Esta solución le permite monitorear y administrar sin esfuerzo sus gastos navideños, asegurándose de estar al tanto de su presupuesto sin la molestia de revisar los recibos manualmente.

Calendario de Adviento de Inteligencia Artificial 2024 en Español

Este proyecto se inspiró en mi participación en el Calendario de Adviento de Inteligencia Artificial 2024 en Español, un evento en línea dedicado a la IA. Puede encontrar más información sobre el evento en este enlace Dev.to.

El proyecto

Para este proyecto, usaremos Azure OpenAI, un servicio que nos permite utilizar potentes modelos de IA como GPT-4 para procesar y analizar imágenes. El proceso implica varios pasos, desde la configuración del servicio API de backend hasta la integración con una interfaz de Blazor para la carga de imágenes. También usaremos .NET Aspire, un componente que ayuda a conectar todo sin problemas.

Requisitos previos

Antes de profundizar en el código, asegúrese de tener los siguientes requisitos previos:

.NET 9
Acceso a Azure OpenAI (clave API)
Visual Studio o Código de Visual Studio
Conocimientos básicos de Blazor, clientes HTTP y desarrollo de API.

La solución de Visual Studio

Terminaremos teniendo algo como esto, me gusta mantener las cosas separadas y con nombres interesantes, así que así es como se ve:

¡Pero vayamos paso a paso creando cosas!

Paso 0: Los modelos

El núcleo de la aplicación Receipt Scanner se basa en varios modelos clave que facilitan la interacción entre los servicios front-end, API y AI. A continuación se detallan los principales modelos utilizados en este proyecto:

AnalizarSolicitud de recibo
Este modelo representa la estructura de solicitud para analizar un recibo. Contiene la propiedad ImageBytes, que contiene la matriz de bytes de la imagen del recibo que se procesará.
```
public class AnalyzeReceiptRequest
{
 public byte[] ImageBytes { get; set; }
}
```
Resultado del análisis de recibo
Este modelo captura el resultado después de procesar un recibo. Contiene los datos estructurados extraídos del recibo, como el nombre de la tienda, la fecha, los artículos y el monto total.
```
public class ReceiptAnalyzeResult
{
 public DateTime CreatedAt { get; set; }
 public ReceiptData Result { get; set; }
}
```
Datos de recibo
Este es el modelo que contiene los datos de recibos estructurados. Incluye propiedades para el nombre de la tienda, la fecha, una lista de artículos (con el nombre y el precio de cada artículo) y el monto total en el recibo.
```
public class ReceiptData
{
 public string Store { get; set; }
 public DateTime? Date { get; set; }
 public List<ReceiptItem> Items { get; set; }
 public decimal? Total { get; set; }
}
```

Artículo de recibo
Cada artículo del recibo está representado por este modelo. Contiene el nombre del artículo y su precio.

public class ReceiptItem
{
 public string Name { get; set; }
 public decimal? Price { get; set; }
}
```Estos modelos sirven como base para pasar datos entre el cliente y el servidor, asegurando un flujo fluido de información. La API recibe la imagen del recibo y, a cambio, procesa y devuelve un objeto JSON estructurado que el front-end puede consumir fácilmente.

Paso 1: Configurar el servicio API de backend

El primer paso para crear esta aplicación es configurar un servicio API para analizar imágenes de recibos. Usaremos la API Azure OpenAI para extraer información de las imágenes de los recibos. Aquí hay un desglose de cómo encaja todo:

Servicio de IA: una inmersión profunda

El servicio de IA es el núcleo de nuestro sistema de análisis de recibos. Es responsable de comunicarse con la API de Azure OpenAI para procesar los datos de la imagen y devolver información significativa. La clase AiApiClient es el cliente que controlará todas las interacciones con la API de Azure OpenAI.

Implementación de cliente de IA

AiApiClient es el componente clave responsable de enviar la imagen del recibo (en formato de matriz de bytes) a la API de Azure OpenAI. Maneja la comunicación, el registro de errores y el análisis de datos:

public class AiApiClient
{
 private readonly HttpClient _httpClient;
 private readonly ILogger<AiApiClient> _logger;

 public AiApiClient(HttpClient httpClient, ILogger<AiApiClient> logger)
 {
 _httpClient = httpClient;
 _logger = logger;
 }

 public async Task<ReceiptAnalyzeResult?> AnalyzeAsync(byte[] imageBytes, CancellationToken cancellationToken = default)
 {
 if (imageBytes == null || imageBytes.Length == 0)
 {
 _logger.LogWarning("ImageBytes is null or empty.");
 return null;
 }

 _logger.LogInformation("Sending analyze request with image bytes of length: {Length}", imageBytes.Length);

 var request = new AnalyzeReceiptRequest
 {
 ImageBytes = imageBytes
 };

 try
 {
 var response = await _httpClient.PostAsJsonAsync("/analyze-receipt", request, cancellationToken);

 if (!response.IsSuccessStatusCode)
 {
 _logger.LogWarning("Failed to analyze receipt. StatusCode: {StatusCode}", response.StatusCode);
 return null;
 }

 var analyzeResult = await response.Content.ReadFromJsonAsync<ReceiptAnalyzeResult>(cancellationToken: cancellationToken);

 if (analyzeResult == null)
 {
 _logger.LogWarning("No content received from AI API service.");
 return null;
 }

 _logger.LogInformation("Analysis result received: {AnalyzeResult}", analyzeResult);

 return analyzeResult;
 }
 catch (Exception ex)
 {
 _logger.LogError(ex, "An error occurred while analyzing the receipt.");
 return null;
 }
 }
}

En esta parte del código definimos el método AnalyzeAsync, el cual es responsable de:

Envío de la matriz de bytes de la imagen a la API de Azure OpenAI.
Manejar cualquier error o respuesta fallida de la API.
Analizar los datos JSON devueltos en un resultado estructurado (ReceiptAnalyzeResult).

Los beneficios de separar esta funcionalidad en un servicio dedicado (AiApiClient) incluyen:

Manejo de errores: Manejo centralizado de errores como problemas de red o respuestas no válidas.
Registro: Registro adecuado de solicitudes y respuestas para monitorear el comportamiento del sistema.

Servicio API: manejo de solicitudes y respuestas

El Servicio API actúa como intermediario entre la aplicación frontal Blazor y el servicio de IA. Este servicio es responsable de aceptar los datos de la imagen, pasarlos al servicio de IA y devolver los resultados del análisis al cliente.

Punto final API

En este paso, definimos un punto final API simple para aceptar imágenes de recibos, reenviarlas al servicio de IA para su procesamiento y devolver los resultados al cliente:

using ReceiptScanner.Shared.Clients;
using ReceiptScanner.Shared.Models;

var builder = WebApplication.CreateBuilder(args);

// Add service defaults & Aspire client integrations.
builder.AddServiceDefaults();

// Add services to the container.
builder.Services.AddProblemDetails();

// Register AiApiClient with HttpClient
builder.Services.AddHttpClient<AiApiClient>(client =>
{
 client.BaseAddress = new Uri("https+http://aiservice");
});

// Learn more about configuring OpenAPI at https://aka.ms/aspnet/openapi
builder.Services.AddOpenApi();

var app = builder.Build();

// Configure the HTTP request pipeline.
app.UseExceptionHandler();

if (app.Environment.IsDevelopment())
{
 app.MapOpenApi();
}

// POST endpoint to analyze receipt
app.MapPost("/api/analyze-receipt", async (AnalyzeReceiptRequest request, AiApiClient aiApiClient, ILogger<Program> logger) =>
{
 if (request.ImageBytes == null || request.ImageBytes.Length == 0)
 {
 logger.LogWarning("ImageBytes is null or empty.");
 return Results.BadRequest("ImageBytes is required.");
 }

 logger.LogInformation("Received analyze receipt request with image bytes of length: {Length}", request.ImageBytes.Length);

 try
 {
 var result = await aiApiClient.AnalyzeAsync(request.ImageBytes);

 if (result == null)
 {
 logger.LogWarning("Failed to analyze the receipt.");
 return Results.Problem("Unable to process the receipt at this time. Please try again later.");
 }

 logger.LogInformation("Analysis completed successfully. Result: {Result}", result);

 return Results.Ok(result);
 }
 catch (Exception ex)
 {
 logger.LogError(ex, "An error occurred while processing the receipt.");
 return Results.Problem("An error occurred while processing the receipt. Please try again later.");
 }
});

app.MapDefaultEndpoints();

app.Run();

Este punto final:

Acepta la imagen del recibo como parte del cuerpo de la solicitud.
Llama al método endopint AiService para enviar la imagen a Azure OpenAI para su procesamiento.
Devuelve el resultado del análisis al cliente.

Paso 2: Configurar la interfaz de Blazor

Ahora que tenemos el backend configurado, dirijamos nuestra atención a la frontend de Blazor. Aquí es donde los usuarios pueden cargar las imágenes de sus recibos para analizarlas y ver los resultados.

Implementación de la página Blazor

La página Blazor proporciona una interfaz sencilla donde los usuarios pueden cargar varias imágenes de recibos y luego ver los resultados del análisis mostrados en una tabla. Aquí está el código de la página:

@page "/analyzer"
@using ReceiptScanner.Shared.Clients
@using ReceiptScanner.Shared.Models
@using System.Globalization
@inject ApiServiceClient ApiClient
@inject ILogger<Program> Logger

@attribute [StreamRendering]
@rendermode InteractiveServer

<PageTitle>Receipt Analyzer</PageTitle>

<h1 class="text-center my-4">Receipt Analyzer</h1>

<div class="container">
 <p class="lead text-center mb-4">Upload receipt images below to extract their data.</p>

 <!-- File Upload Section -->
 <div class="card mb-4">
 <div class="card-body">
 <InputFile OnChange="HandleFileSelected" multiple class="form-control mb-3" />
 <button class="btn btn-primary w-100" @onclick="ProcessReceipts" disabled="@(!hasFiles)" type="button">
 <span class="@(!processing ? "d-none" : "") spinner-border spinner-border-sm" role="status" aria-hidden="true"></span>
 @if (processing)
 {
 <span>Processing...</span>
 }
 else
 {
 <span>Process Receipts</span>
 }
 </button>
 </div>
 </div>

 <!-- Uploaded Images Preview -->
 @if (fileBytesList.Any())
 {
 <div class="card mb-4">
 <div class="card-header">
 <h5 class="mb-0">Uploaded Receipt Images</h5>
 </div>
 <div class="card-body">
 <div class="row">
 @foreach (var fileBytes in fileBytesList)
 {
 <div class="col-12 col-md-4 mb-3">
 <img src="@($"data:image/jpeg;base64,{Convert.ToBase64String(fileBytes)}")" class="img-fluid rounded" alt="Uploaded receipt" />
 </div>
 }
 </div>
 </div>
 </div>
 }

 <!-- Processing Indicator -->
 @if (processing)
 {
 <div class="alert alert-info text-center" role="alert">
 <strong>Processing receipts...</strong> Please wait while we analyze the uploaded files.
 </div>
 }

 <!-- Analysis Results Section -->
 @if (analyzedReceipts != null && analyzedReceipts.Any())
 {
 <div class="card">
 <div class="card-header">
 <h5 class="mb-0">Analysis Results</h5>
 </div>
 <div class="card-body">
 <table class="table table-striped table-bordered">
 <thead>
 <tr>
 <th>Store</th>
 <th>Date</th>
 <th>Total</th>
 <th>Items</th>
 </tr>
 </thead>
 <tbody>
 @foreach (var receipt in analyzedReceipts)
 {
 <tr>
 <td>@(receipt.Result?.Store ?? "Unknown")</td>
 <td>@(receipt.Result?.Date?.ToString() ?? "Unknown")</td>
 <td>@(receipt.Result?.Total?.ToString("C", ci) ?? "Unknown")</td>
 <td>
 <ul class="list-unstyled">
 @if (receipt.Result?.Items is not null)
 {
 @foreach (var item in receipt.Result?.Items!)
 {
 <li><strong>@item.Name</strong> - @item.Price?.ToString("C", ci)</li>
 }
 }
 </ul>
 </td>
 </tr>
 }
 </tbody>
 </table>
 </div>
 </div>
 }
 else if (processed && (analyzedReceipts == null || !analyzedReceipts.Any()))
 {
 <div class="alert alert-warning text-center" role="alert">
 <strong>No results found.</strong> Please try again with different images or ensure they are clear and legible.
 </div>
 }
</div>

@code {
 private bool hasFiles;
 private bool processing;
 private bool processed;
 private List<byte[]> fileBytesList = new();
 private List<ReceiptAnalyzeResult> analyzedReceipts = new();
 CultureInfo ci = new CultureInfo("es-es");

 private async Task HandleFileSelected(InputFileChangeEventArgs e)
 {
 try
 {
 fileBytesList.Clear();

 foreach (var file in e.GetMultipleFiles())
 {
 var memoryStream = new MemoryStream();
 await file.OpenReadStream().CopyToAsync(memoryStream);
 fileBytesList.Add(memoryStream.ToArray());
 }

 hasFiles = fileBytesList.Any();
 }
 catch (Exception ex)
 {
 Logger.LogError(ex, "Error while handling file upload.");
 }
 }

 private async Task ProcessReceipts()
 {
 if (!hasFiles)
 return;

 processing = true;
 analyzedReceipts.Clear();

 try
 {
 foreach (var fileBytes in fileBytesList)
 {
 var result = await ApiClient.AnalyzeReceiptAsync(fileBytes);
 if (result != null)
 {
 analyzedReceipts.Add(result);
 }
 }
 }
 catch (Exception ex)
 {
 Logger.LogError(ex, "Error while processing receipts.");
 }
 finally
 {
 processing = false;
 processed = true;
 }
 }
}

```Esta página permite a los usuarios cargar recibos y muestra los resultados del análisis en una tabla con nombres de tiendas, fechas, montos totales y la lista de artículos.

<p align="centro">
<img src="https://imgur.com/BLswKhm.png">
</p>

## Paso 3: .NET Aspire

<p align="centro">
<img src="https://imgur.com/ja56RWN.png">
</p>

### ¿Qué es .NET Aspire?

.NET Aspire es un conjunto de potentes herramientas, plantillas y paquetes para crear aplicaciones observables y listas para producción. .NET Aspire se entrega a través de una colección de paquetes NuGet que manejan inquietudes específicas nativas de la nube. Las aplicaciones nativas de la nube a menudo constan de piezas o microservicios pequeños e interconectados en lugar de una base de código única y monolítica. Las aplicaciones nativas de la nube generalmente consumen una gran cantidad de servicios, como bases de datos, mensajería y almacenamiento en caché. Para obtener información sobre soporte, consulte la Política de soporte de .NET Aspire.

Una aplicación distribuida es aquella que utiliza recursos computacionales en múltiples nodos, como contenedores que se ejecutan en diferentes hosts. Dichos nodos deben comunicarse a través de los límites de la red para entregar respuestas a los usuarios. Una aplicación nativa de la nube es un tipo específico de aplicación distribuida que aprovecha al máximo la escalabilidad, la resiliencia y la capacidad de administración de las infraestructuras de la nube.

El uso de **.NET Aspire** para este proyecto proporciona varios beneficios que mejoran la calidad general del sistema, como por ejemplo:

### 1. **Registro centralizado**

.NET Aspire integra automáticamente el registro en toda la aplicación, lo que significa que no es necesario configurar manualmente el registro para cada servicio. Esto garantiza que los registros sean coherentes y se almacenen en una ubicación centralizada, lo que facilita mucho la depuración y el seguimiento.

Por ejemplo, la clase `AiApiClient` utiliza el registro para registrar los bytes de imagen enviados al servicio de IA, las respuestas de la API y cualquier error que ocurra durante el proceso de análisis.

```csharp
_logger.LogInformation("Sending analyze request with image bytes of length: {Length}",

 imageBytes.Length);

2. Recopilación automática de métricas

.NET Aspire también rastrea e informa automáticamente métricas importantes de la aplicación, como tiempos de respuesta, recuentos de solicitudes y tasas de error. Esto le ayuda a comprender el rendimiento de la aplicación y a detectar rápidamente cualquier cuello de botella o problema.

3. Rendimiento mejorado

.NET Aspire optimiza las llamadas HTTP, lo que ayuda a mantener bajos los tiempos de respuesta y reducir el consumo innecesario de recursos. Proporciona funciones como agrupación de conexiones, reintentos de solicitudes y enrutamiento inteligente.

4. Integración perfecta

.NET Aspire simplifica la integración de varios servicios (como los servicios de IA y API en este proyecto) y agiliza el proceso de implementación. No necesita preocuparse por las configuraciones de bajo nivel, ya que Aspire se encarga de las tareas relacionadas con la infraestructura por usted.

ConclusiónLa IA ya no es sólo una palabra de moda o algo que vemos en las películas de ciencia ficción. Actualmente está resolviendo activamente problemas del mundo real, como el que abordamos en este proyecto: extraer datos estructurados de los recibos. Con la ayuda de Azure OpenAI, .NET Aspire y Blazor, podemos automatizar lo que de otro modo sería una tarea manual que consumiría mucho tiempo y sería propensa a errores. La IA no solo chatea o responde a indicaciones como ChatGPT; interpreta imágenes, extrae información valiosa y nos brinda información útil en segundos.

Al utilizar Azure OpenAI para el análisis de recibos y .NET Aspire para una integración perfecta con registros y métricas, hemos creado una solución que es potente y escalable. El potencial de la IA para agilizar los procesos empresariales, automatizar tareas tediosas y mejorar la precisión es enorme, y este es sólo un ejemplo de cómo se puede aplicar.

Esta publicación es parte del Calendario de Adviento de Inteligencia Artificial 2024 en Español, un evento que muestra aplicaciones de IA del mundo real y educa a la comunidad tecnológica de habla hispana sobre las últimas tendencias. Si busca profundizar en la IA y sus posibilidades, este evento es un excelente lugar para comenzar.

La IA está transformando nuestra forma de trabajar y este proyecto es solo una muestra de lo que es posible. El verdadero poder de la IA reside en su capacidad para resolver problemas reales, ya sea procesando recibos, analizando imágenes o prediciendo tendencias. Sólo estamos arañando la superficie.

Código fuente

El código fuente completo de este proyecto está disponible en GitHub. No dude en descargarlo, explorar cómo funcionan juntos los servicios de IA y API y adaptarlo a sus propios casos de uso. Si tiene algún problema o si tiene ideas para mejorar, no dude en crear un problema o enviar una solicitud de extracción. ¡Las contribuciones siempre son bienvenidas y sus comentarios ayudarán a que este proyecto sea aún mejor!

¡Feliz codificación!

¿Usar contenedores para... llevar la cuenta de los precios de los regalos de Navidad?

Thu, 12 Dec 2024 00:00:00 +0000

La Navidad está a la vuelta de la esquina y con ella llega la feliz tarea de encontrar el regalo perfecto para nuestros seres queridos. Si eres como yo, probablemente te encantará conseguir una buena oferta, pero navegar por los precios vertiginosos de artículos populares durante la temporada navideña puede parecer como un paseo en trineo en la vida real: ¡emocionante pero un poco abrumador! Este año, en lugar de volverme loco con comprobaciones diarias de precios, decidí darle un buen uso a mis habilidades tecnológicas y automatizar el proceso.

Como desarrollador de software y apasionado por aprovechar la tecnología para resolver problemas cotidianos, encontré una manera de automatizar el proceso de verificación de precios. En lugar de visitar manualmente varias tiendas en línea todos los días para comparar precios, decidí crear un sistema que pueda hacerlo por mí. Esto no sólo ahorra tiempo, sino que también garantiza que obtenga las mejores ofertas sin el estrés de las comprobaciones diarias.

¿Por qué automatizar el seguimiento de precios?

Automatizar el seguimiento de precios es como tener tu propio equipo de duendes de Papá Noel trabajando las 24 horas del día para garantizar que obtengas las mejores ofertas sin mover un dedo. He aquí por qué te encantará:

Artículos caros: Todos sabemos que los regalos de Navidad pueden resultar bastante caros, especialmente cuando hay gadgets y juguetes en tu lista. Ahorrar dinero en estos puede ser tan satisfactorio como encontrar la última copa de árbol disponible.
Revisiones diarias: ¿Quién tiene el tiempo (o la paciencia) para consultar los precios todos los días? ¡Yo no!
Automatización: Abrace el espíritu navideño de dar: regálese la eficiencia.
Precisión: la automatización garantiza que sus comprobaciones de precios sean tan precisas como brillante es la nariz de Rudolph.

Tecnologías centrales

Para construir mi propio pequeño ayudante de Papá Noel, decidí utilizar varias tecnologías clave:

Contenedores

Los contenedores son como el envoltorio navideño del software. Agrupan sus aplicaciones con todos sus beneficios (dependencias) para que todo funcione tan fluidamente como un paseo en trineo sobre nieve fresca. Docker es nuestra opción para crear estos contenedores.

Blazor

Blazor es un marco genial para crear aplicaciones web interactivas utilizando .NET. Es como reemplazar villancicos genéricos con tu propia lista de reproducción navideña: personalizada, eficiente y muy divertida.

Docker-Componer

Docker-Compose es el administrador de operaciones de nuestro Polo Norte. Nos ayuda a mantener todos nuestros servicios, como la API y el front-end de Blazor, funcionando juntos en perfecta armonía. Piense en él como el director de nuestra sinfonía navideña.

Guía paso a paso

¡Ahora, sumergámonos en el taller de Santa y démosle vida a este proyecto!

Paso 1: Crear la API

1.1 Configuración del proyecto

Ponte tu gorro de Papá Noel de codificación y configura un nuevo proyecto de API web ASP.NET Core. Abre tu terminal (es un poco como abrir tu calendario de adviento) y ejecuta:

dotnet new webapi -o PriceMonitorApi
cd PriceMonitorApi

Este comando crea un nuevo directorio llamado PriceMonitorApi y configura un proyecto API web básico. Imagínese que es como crear una base sólida para su casa de pan de jengibre.

1.2 Agregar HttpClient y bibliotecas de scrapingA continuación, agregue `HttpClient` y una biblioteca para analizar HTML. Este será nuestro trineo confiable para buscar y leer datos de precios.

dotnet add package HtmlAgilityPack

HtmlAgilityPack es el elfo que nos ayuda a analizar documentos HTML.

1.3 Creando modelos

Los modelos son como el modelo de nuestros juguetes. Creemos un modelo para representar la información del producto:

namespace PriceMonitorApi.Models
{
 public class ProductInfo
 {
 public string Title { get; set; }
 public decimal Price { get; set; }
 public DateTime Date { get; set; }
 }
}

Acabamos de crear la plantilla perfecta para nuestros datos.

1.4 Implementación del servicio Scraper

Nuestro servicio scraper es como el pequeño ayudante de Papá Noel: busca y procesa información para nosotros:

using HtmlAgilityPack;
using PriceMonitorApi.Models;
using System.Globalization;

namespace PriceMonitorApi.Services
{
 public class ScraperService
 {
 private readonly HttpClient _httpClient;

 public ScraperService(HttpClient httpClient)
 {
 _httpClient = httpClient;
 }

 public async Task<ProductInfo> ScrapeProductInfoAsync(string url)
 {
 var response = await _httpClient.GetStringAsync(url);

 var htmlDoc = new HtmlDocument();
 htmlDoc.LoadHtml(response);

 var title = htmlDoc.DocumentNode.SelectSingleNode("//h1[@class='product-title']").InnerText.Trim();
 var priceString = htmlDoc.DocumentNode.SelectSingleNode("//span[@class='product-price']").InnerText.Trim();

 if (decimal.TryParse(priceString, NumberStyles.Currency, CultureInfo.InvariantCulture, out var price))
 {
 return new ProductInfo
 {
 Title = title,
 Price = price,
 Date = DateTime.UtcNow
 };
 }

 throw new Exception("Unable to parse price");
 }
 }
}

Este fragmento convierte nuestro HtmlAgilityPack en una varita mágica navideña.

1.5 Creación del controlador API

Creemos un controlador que actuará como guardián de nuestros datos:

using Microsoft.AspNetCore.Mvc;
using PriceMonitorApi.Models;
using PriceMonitorApi.Services;

namespace PriceMonitorApi.Controllers
{
 [ApiController]
 [Route("api/[controller]")]
 public class ScraperController : ControllerBase
 {
 private readonly ScraperService _scraperService;

 public ScraperController(ScraperService scraperService)
 {
 _scraperService = scraperService;
 }

 [HttpGet("productinfo")]
 public async Task<ActionResult<ProductInfo>> GetProductInfo(string url)
 {
 try
 {
 var productInfo = await _scraperService.ScrapeProductInfoAsync(url);
 return Ok(productInfo);
 }
 catch (Exception ex)
 {
 return BadRequest(new { Message = ex.Message });
 }
 }
 }
}

Nuestro controlador garantiza que los datos se entreguen más rápido que Papá Noel por la chimenea.

1.6 Registro de servicios en contenedor DI

Por último, registra tu ScraperService para asegurarte de que esté disponible cuando sea necesario.

services.AddHttpClient<ScraperService>();

Ahora su API está lista, ¡como el trineo de Papá Noel en Nochebuena!

Paso 2: Creación de la aplicación Blazor

Blazor nos ayuda a decorar nuestro proyecto como un árbol de Navidad, haciéndolo visualmente atractivo e interactivo.

2.1 Configuración del proyecto Blazor

A continuación, crearemos un proyecto Blazor que actúa como interfaz para nuestro paseo en trineo de seguimiento de precios.

dotnet new blazor -o PriceMonitorBlazor
cd PriceMonitorBlazor

Este comando agrega algo de magia navideña para configurar un proyecto básico de Blazor WebAssembly.

2.2 Agregar modelos

Al igual que configurar adornos, agregue un modelo ProductInfo en el proyecto Blazor:

namespace PriceMonitorBlazor.Models
{
 public class ProductInfo
 {
 public string Title { get; set; }
 public decimal Price { get; set; }
 public DateTime Date { get; set; }
 }
}

2.3 Creación del servicio para llamadas API

Cree un servicio para obtener datos de nuestra API; considérelo como nuestro compañero de compras en línea:

using PriceMonitorBlazor.Models;
using System.Net.Http;
using System.Net.Http.Json;
using System.Threading.Tasks;

namespace PriceMonitorBlazor.Services
{
 public class ScraperService
 {
 private readonly HttpClient _httpClient;

 public ScraperService(HttpClient httpClient)
 {
 _httpClient = httpClient;
 }

 public async Task<ProductInfo> GetProductInfoAsync(string url)
 {
 var response = await _httpClient.GetFromJsonAsync<ProductInfo>($"https://localhost:5001/api/scraper/productinfo?url={url}");
 return response;
 }
 }
}

2.4 Registro de servicios en contenedor DI

Asegúrese de que ScraperService esté registrado para que podamos inyectarlo en nuestros componentes.

builder.Services.AddScoped<ScraperService>();

2.5 Creación del componente Blazor

Actualice Pages/Index.razor para incluir una interfaz divertida e interactiva:

@page "/"
@using PriceMonitorBlazor.Models
@using PriceMonitorBlazor.Services
@inject ScraperService ScraperService

<h3>Price Monitor</h3>

<p>
 <label for="urlInput">Product URL:</label>
 <input id="urlInput" @bind="productUrl" />
 <button @onclick="FetchProductInfo">Fetch Price</button>
</p>

@if (productInfos.Any())
{
 <table class="table">
 <thead>
 <tr>
 <th>Title</th>
 <th>Price</th>
 <th>Date</th>
 </tr>
 </thead>
 <tbody>
 @foreach (var product in productInfos)
 {
 <tr>
 <td>@product.Title</td>
 <td>@product.Price</td>
 <td>@product.Date</td>
 </tr>
 }
 </tbody>
 </table>
}

@code {
 private string productUrl;
 private List<ProductInfo> productInfos = new List<ProductInfo>();

 private async Task FetchProductInfo()
 {
 if (!string.IsNullOrEmpty(productUrl))
 {
 var productInfo = await ScraperService.GetProductInfoAsync(productUrl);
 productInfos.Add(productInfo);
 }
 }
}

Es como montar una exhibición festiva: hacer que nuestra aplicación sea interactiva y agradable.

Paso 3: Conectar todo usando Docker-Compose

Ahora conectemos todo usando Docker-Compose, convirtiendo nuestro proyecto en un paseo en trineo bien engrasado.

3.1 Creando archivos Docker

Cree Dockerfiles para los proyectos API y Blazor:

PriceMonitorApi/Dockerfile:

FROM mcr.microsoft.com/dotnet/aspnet:6.0 AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443

FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build
WORKDIR /src
COPY ["PriceMonitorApi/PriceMonitorApi.csproj", "PriceMonitorApi/"]
RUN dotnet restore "PriceMonitorApi/PriceMonitorApi.csproj"
COPY . .
WORKDIR "/src/PriceMonitorApi"
RUN dotnet build "PriceMonitorApi.csproj" -c Release -o /app/build

FROM build AS publish
RUN dotnet publish "PriceMonitorApi.csproj" -c Release -o /app/publish

FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "PriceMonitorApi.dll"]

PriceMonitorBlazor/Dockerfile:

FROM mcr.microsoft.com/dotnet/aspnet:6.0 AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443

FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build
WORKDIR /src
COPY ["PriceMonitorBlazor/PriceMonitorBlazor.csproj", "PriceMonitorBlazor/"]
RUN dotnet restore "PriceMonitorBlazor/PriceMonitorBlazor.csproj"
COPY . .
WORKDIR "/src/PriceMonitorBlazor"
RUN dotnet build "PriceMonitorBlazor.csproj" -c Release -o /app/build

FROM build AS publish
RUN dotnet publish "PriceMonitorBlazor.csproj" -c Release -o /app/publish

FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "PriceMonitorBlazor.dll"]

3.2 Creando docker-compose.yml

Conecta todos los puntos (luces navideñas) con un solo archivo docker-compose.yml:

version: '3.4'

services:
 api:
 image: pricemonitorapi
 build:
 context: ./PriceMonitorApi
 dockerfile: Dockerfile
 ports:
 - "5000:80"
 networks:
 - price-monitor-network

 blazor:
 image: pricemonitorblazor
 build:
 context: ./PriceMonitorBlazor
 dockerfile: Dockerfile
 ports:
 - "5001:80"
 depends_on:
 - api
 networks:
 - price-monitor-network

networks:
 price-monitor-network:
 driver: bridge

Diagramas

A continuación se muestran los diagramas para ayudar a visualizar los diferentes componentes y el flujo de datos, esto nos ayudará a comprender lo que realmente está sucediendo en nuestro mundo santa:

Diagrama de arquitectura del sistema

Diagrama de flujo de datos

Diagrama de secuencia

Diagrama de componentes para la configuración de Docker

Paso 4: Gestión de URL, actualización y actualización periódica automatizadaEn esta demostración simplemente lo almacenaremos en la memoria, pero en una aplicación real, usarías una base de datos. Para este divertido proyecto, centrémonos en el almacenamiento en memoria.

4.1 Modificación del servicio para administrar URL

Primero, nos aseguraremos de que nuestro servicio pueda agregar y recuperar URL, así como también obtener información del producto:

Actualización Services/ScraperService.cs:

using PriceMonitorBlazor.Models;
using System.Collections.Generic;
using System.Net.Http;
using System.Net.Http.Json;
using System.Threading.Tasks;

namespace PriceMonitorBlazor.Services
{
 public class ScraperService
 {
 private readonly HttpClient _httpClient;
 private List<string> urls = new List<string>();

 public ScraperService(HttpClient httpClient)
 {
 _httpClient = httpClient;
 }

 public async Task<ProductInfo> GetProductInfoAsync(string url)
 {
 var response = await _httpClient.GetFromJsonAsync<ProductInfo>($"http://localhost:5000/api/scraper/productinfo?url={url}");
 return response;
 }

 public void AddUrl(string url)
 {
 if (!urls.Contains(url))
 {
 urls.Add(url);
 }
 }

 public List<string> GetUrls()
 {
 return urls;
 }

 public void ClearUrls()
 {
 urls.Clear();
 }
 }
}

4.2 Actualización del componente Blazor para administración y actualización de URL

A continuación, actualice Pages/Index.razor para agregar administración de URL, actualización y actualización periódica automatizada:

@page "/"
@using PriceMonitorBlazor.Models
@using PriceMonitorBlazor.Services
@inject ScraperService ScraperService

<h3>Price Monitor</h3>

<p>
 <label for="urlInput">Product URL:</label>
 <input id="urlInput" @bind="productUrl" />
 <button @onclick="AddUrl">Add URL</button>
</p>

<p>
 <button @onclick="RefreshPrices">Refresh All Prices</button>
</p>

@if (productInfos.Any())
{
 <table class="table">
 <thead>
 <tr>
 <th>Title</th>
 <th>Price</th>
 <th>Date</th>
 </tr>
 </thead>
 <tbody>
 @foreach (var product in productInfos)
 {
 <tr>
 <td>@product.Title</td>
 <td>@product.Price</td>
 <td>@product.Date</td>
 </tr>
 }
 </tbody>
 </table>
}

@code {
 private string productUrl;
 private List<ProductInfo> productInfos = new List<ProductInfo>();
 private Timer _timer;

 protected override void OnInitialized()
 {
 StartTimer();
 }

 private void StartTimer()
 {
 // Set up the timer to call RefreshPrices every minute (60000 ms)
 _timer = new Timer(async _ => await InvokeAsync(RefreshPrices), null, TimeSpan.Zero, TimeSpan.FromMinutes(1));
 }

 private void AddUrl()
 {
 if (!string.IsNullOrEmpty(productUrl))
 {
 ScraperService.AddUrl(productUrl);
 productUrl = string.Empty;
 }
 }

 private async Task RefreshPrices()
 {
 productInfos.Clear();
 var urls = ScraperService.GetUrls();

 foreach (var url in urls)
 {
 var productInfo = await ScraperService.GetProductInfoAsync(url);
 productInfos.Add(productInfo);
 }
 StateHasChanged();
 }
}

En este componente actualizado:

Usamos un Timer para llamar periódicamente al método RefreshPrices cada minuto.
El método StartTimer inicializa el temporizador para que comience inmediatamente y luego se active cada 60 segundos.
El método de ciclo de vida OnInitialized llama a StartTimer cuando el componente se inicializa para iniciar la actualización periódica.

4.3 Ejecutando la solución

Para ejecutar la aplicación Blazor actualizada con las nuevas funciones, reconstruya y reinicie sus contenedores Docker:

docker-compose build
docker-compose up

Después de cargar http://localhost:5001 en su navegador, la aplicación Blazor ahora debería actualizar automáticamente los precios de los productos cada minuto, además de permitir actualizaciones manuales y administración de URL.

Conclusión

¡Construir este sistema de seguimiento de precios ha sido una maravilla festiva! No sólo me salvó del estrés de las comprobaciones diarias de precios, sino que también mostró la magia de las tecnologías web modernas.

Calendario tecnológico festivo 2024

Creé esta publicación como parte del evento Festive Tech Calendar 2024, que reúne a entusiastas de la tecnología, innovadores y soñadores digitales para compartir conocimientos y celebrar la fusión del espíritu festivo y las maravillas tecnológicas. Esta iniciativa no se trata solo de aprender y conectarse, sino también de retribuir.

Festive Tech Calendar 2024 apoya a Beatson Cancer Charity este año. Beatson Cancer Charity se dedica a apoyar a las personas afectadas por el cáncer, a sus familias y a los profesionales de la salud que los cuidan. Puede encontrar más información sobre su increíble trabajo en https://www.beatsoncancercharity.org/.

Visite el sitio web de Festive Tech Calendar en https://festivetechcalendar.com para consultar las preguntas frecuentes y obtener más detalles sobre el evento.

¡HO HO HO!

Crear este proyecto ha sido una manera maravillosa de contribuir a la comunidad tecnológica festiva y al mismo tiempo apoyar una gran causa.

Espero que esta guía le haya resultado útil y que le inspire a explorar más formas de utilizar la tecnología para simplificar las tareas cotidianas.

Si tiene alguna pregunta o necesita más ayuda, no dude en comunicarse.

¡Feliz codificación!

Validación personalizada de atributos y validación de Blazor

Fri, 29 Mar 2024 00:00:00 +0000

# Personalizar todo

Como probablemente habrás visto en todas mis publicaciones, realmente trato de mantener todo lo más limpio posible, ya que ya escribí publicaciones sobre atributos personalizados, manejo de excepciones personalizado, inyección de recopilación de servicios, etc.

Con el tiempo me di cuenta de que este tipo de codificación nos brinda a mí y a mi equipo una manera de mejorar con el tiempo, encontrar problemas más fácilmente y separar el código tanto como sea posible.

Sí, después de esta interesante historia que les acabo de contar, últimamente he estado trabajando en Blazor como de costumbre y descubrí que, después de años y años de desarrollo, se pueden crear atributos de validación personalizados.

Sí, es gracioso, después de todos estos años…

Atributos de validación personalizados

En realidad, la idea surgió del trabajo, siempre hacemos validación en todos los lugares, pero tenía algunos campos que requerían el mismo proceso de validación, así que pensé que podría haber algo allí… ¡como atributos de validación personalizados!

Así que abrí la documentación de Microsoft para eso y descubrí que sí, puedes crear atributos de validación personalizados y asignarlos a las propiedades, así:

public class StringLengthRangeAttribute : ValidationAttribute
{
 public int Minimum { get; set; }
 public int Maximum { get; set; }

 public StringLengthRangeAttribute()
 {
 this.Minimum = 0;
 this.Maximum = int.MaxValue;
 }

 public override bool IsValid(object value)
 {
 string strValue = value as string;
 if (!string.IsNullOrEmpty(strValue))
 {
 int len = strValue.Length;
 return len >= this.Minimum && len <= this.Maximum;
 }
 return true;
 }
}

y usarlo en una clase simple como esta:

[Required]
[StringLengthRange(Minimum = 10, ErrorMessage = "Must be >10 characters.")]

[StringLengthRange(Maximum = 20)]

[Required]
[StringLengthRange(Minimum = 10, Maximum = 20)]

Validador personalizado

Así que tengo este validador que necesito para algún caso de negocio específico que contendrá 20 primeros caracteres, de los cuales 9 números y un guión, y terminará con 2 caracteres que generalmente serán el código de país, algo como esto: 123456789-123456789-ES

Terminé con algo como esto, es muy simple pero funciona:

using System;
using System.ComponentModel.DataAnnotations;
using System.Text.RegularExpressions;

public class SpecialStringValidatorAttribute : ValidationAttribute
{
 private const int TotalLength = 22;
 private const string Pattern = @"^(\d{10})-(\d{10})-([A-Za-z]{2})$";

 protected override ValidationResult IsValid(object value, ValidationContext validationContext)
 {
 string strValue = value as string;

 if (!string.IsNullOrEmpty(strValue))
 {
 if (strValue.Length != TotalLength)
 {
 return new ValidationResult($"The string must be {TotalLength} characters long.");
 }

 if (!Regex.IsMatch(strValue, Pattern))
 {
 return new ValidationResult("The string must follow the pattern: 1234567890-1234567890-AB");
 }

 return ValidationResult.Success;
 }

 return new ValidationResult("The string cannot be null or empty.");
 }
}

Pruebas

También escribí algunas pruebas para ellos, por si acaso:

public class SpecialStringValidatorTests
{
 [Theory]
 [InlineData("1234567890-1234567890-AB", true)]
 [InlineData("1234567890-1234567890-XY", true)]
 [InlineData("1234567890-1234567890-A1", false)]
 [InlineData("1234567890-1234567890-A", false)]
 [InlineData("1234567890-123456789-AB", false)]
 [InlineData("1234567890-1234567890", false)]
 [InlineData("1234567890-1234567890-ABCDE", false)]
 public void SpecialStringValidatorTest(string input, bool expectedResult)
 {
 // Arrange
 var validator = new SpecialStringValidatorAttribute();

 // Act
 var result = validator.IsValid(input);

 // Assert
 Assert.Equal(expectedResult, result);
 }
}

Y cuando ejecuté obtuve estos resultados:

Microsoft (R) Test Execution Command Line Tool Version 16.9.1
Copyright (c) Microsoft Corporation. All rights reserved.

Starting test execution, please wait...

A total of 1 test files matched the specified pattern.

Test run in progress...

Passed! - SpecialStringValidatorTests.SpecialStringValidatorTest(input: "1234567890-1234567890-AB", expectedResult: True)
Passed! - SpecialStringValidatorTests.SpecialStringValidatorTest(input: "1234567890-1234567890-XY", expectedResult: True)
Passed! - SpecialStringValidatorTests.SpecialStringValidatorTest(input: "1234567890-1234567890-A1", expectedResult: False)
Passed! - SpecialStringValidatorTests.SpecialStringValidatorTest(input: "1234567890-1234567890-A", expectedResult: False)
Passed! - SpecialStringValidatorTests.SpecialStringValidatorTest(input: "1234567890-123456789-AB", expectedResult: False)
Passed! - SpecialStringValidatorTests.SpecialStringValidatorTest(input: "1234567890-1234567890", expectedResult: False)
Passed! - SpecialStringValidatorTests.SpecialStringValidatorTest(input: "1234567890-1234567890-ABCDE", expectedResult: False)

Test Run Successful.
Total tests: 7
 Passed: 7
 Total time: 1.7296 Seconds

Validación personalizada y Blazor

Ahora que sé que se puede usar, es claramente una buena idea implementarlo en Blazor, ¿verdad?

Supongamos que tengo este formulario, que usará el modelo Person que mostré antes:

@using Models
@page "/"

<PageTitle>Home</PageTitle>

<h1>Hello, world!</h1>

<EditForm Model=@Person FormName="PersonForm">
 <DataAnnotationsValidator/>
 <ValidationSummary/>
 <div class="form-group">
 <label for="Name">Name</label>
 <InputText @bind-Value=Person.Name class="form-control" id="Name" />
 <ValidationMessage For="() => Person.Name"/>
 </div>
 <div class="form-group">
 <label for="MySpecialString">My special string</label>
 <InputText @bind-Value=Person.MySpecialString class="form-control" id="Name" />
 <ValidationMessage For="() => Person.MySpecialString"/>
 </div>
 <div class="form-group">
 <label for="Age">Age</label>
 <InputNumber @bind-Value=Person.Age class="form-control" id="Age" />
 <ValidationMessage For=@(() => Person.Age) />
 </div>
 <input type="submit" class="btn btn-primary" value="Save"/>
</EditForm>

@code {
 Person Person = new Person();
}

Tan pronto como ejecutamos esto, obtenemos los siguientes errores:

Y si simplemente ponemos lo que queremos, obtenemos lo siguiente, todo claro:

Para ser honesto, está bastante claro que debemos mover la lógica al menos para validar esos formularios a atributos de validación personalizados, nos da libertad para almacenar el código para ese inicio de sesión en un solo lugar y podemos usarlo más tarde para una API u otra aplicación.

Espero que te haya gustado, si tienes alguna duda o quieres ponerte en contacto, ¡no lo dudes y contacta conmigo!

Manejo de excepciones personalizado en .NET API

Sun, 01 Oct 2023 00:00:00 +0000

Las excepciones son malas, lo sabemos, ¿verdad? ¿Pero qué pasa si tenemos que manejarlos?

¿Qué sucede cuando tenemos una excepción? Por ejemplo, en una API, muestra un mensaje de pila que incluye mucha información que quizás queramos eliminar de la respuesta que reciben nuestros usuarios.

Para la demostración, creé una API dotnet y agregué un método que generará una excepción:

[HttpGet]
[Route("GetWithoutExceptionHandler")]
public Task GetWithoutExceptionHandler()
{
 throw new Exception("This is a custom exception!");
}

Si lanzamos una excepción, se ve así:

System.Exception: This is a custom exception!
 at CustomExceptionHandleDemo.Controllers.WeatherForecastController.GetWithoutExceptionHandler()
 at lambda_method16(Closure , Object , Object[] )
 at Microsoft.AspNetCore.Mvc.Infrastructure.ActionMethodExecutor.AwaitableResultExecutor.Execute(IActionResultTypeMapper mapper, ObjectMethodExecutor executor, Object controller, Object[] arguments)
 at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.<InvokeActionMethodAsync>g__Logged|12_1(ControllerActionInvoker invoker)
 at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.<InvokeNextActionFilterAsync>g__Awaited|10_0(ControllerActionInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
 at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Rethrow(ActionExecutedContextSealed context)
 at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Next(State& next, Scope& scope, Object& state, Boolean& isCompleted)
 at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.InvokeInnerFilterAsync()
--- End of stack trace from previous location ---
 at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeFilterPipelineAsync>g__Awaited|20_0(ResourceInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
 at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeAsync>g__Logged|17_1(ResourceInvoker invoker)
 at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeAsync>g__Logged|17_1(ResourceInvoker invoker)
 at Microsoft.AspNetCore.Routing.EndpointMiddleware.<Invoke>g__AwaitRequestTask|6_0(Endpoint endpoint, Task requestTask, ILogger logger)
 at Microsoft.AspNetCore.Authorization.AuthorizationMiddleware.Invoke(HttpContext context)
 at Swashbuckle.AspNetCore.SwaggerUI.SwaggerUIMiddleware.Invoke(HttpContext httpContext)
 at Swashbuckle.AspNetCore.Swagger.SwaggerMiddleware.Invoke(HttpContext httpContext, ISwaggerProvider swaggerProvider)
 at Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddleware.Invoke(HttpContext context)

Esto parece normal, esto es lo que se obtiene de una excepción, pero para mí, muestra mucha información, si tiene bibliotecas y demás, podría mostrar información sensible sobre su cliente, su proyecto u otras cosas a alguien que podría estar intentando ver cosas.

Esto es lo que se ve en Swagger:

Creando una excepción personalizada

Este paso podría evitarse, ya que sabemos qué excepción se generará, en este caso una Exception, pero para mí, tener excepciones personalizadas es mejor ya que tienes más control de lo que estás lanzando.

En este caso, acabo de crear un objeto CustomException que hereda de Exception:

namespace CustomExceptionHandleDemo.Exceptions
{
 public class CustomException : Exception
 {
 /// <summary>
 /// Constructor for <see cref="CustomException"/>
 /// </summary>
 public CustomException() { }

 /// <summary>
 /// Constructor for <see cref="CustomException"/>
 /// </summary>
 /// <param cref="string" name="message">Parameter for message</param>
 public CustomException(string message) : base(message) { }

 /// <summary>
 /// Constructor for <see cref="CustomException"/>
 /// </summary>
 /// <param cref="string" name="message">Parameter for message</param>
 /// <param cref="Exception" name="inner">Parameter for inner</param>
 public CustomException(string message, Exception inner) : base(message, inner) { }
 }
}

Después de haber creado nuestra excepción personalizada, actualicemos nuestro método para lanzar CustomException en lugar de Exception:

[HttpGet]
[Route("GetWithoutExceptionHandler")]
public Task GetWithoutExceptionHandler()
{
 throw new CustomException("This is a custom exception!");
}

Esto por ahora no cambiará nada, pero el seguimiento de la pila mostrará que el objeto que se lanzó es un CustomException en lugar de Exception, eche un vistazo al inicio del seguimiento de la pila:

CustomExceptionHandleDemo.Exceptions.CustomException: This is a custom exception!
 at CustomExceptionHandleDemo.Controllers.WeatherForecastController.GetWithoutExceptionHandler()
 at lambda_method24(Closure , Object , Object[] )
 at Microsoft.AspNetCore.Mvc.Infrastructure.ActionMethodExecutor.AwaitableResultExecutor.Execute(IActionResultTypeMapper mapper, ObjectMethodExecutor executor, Object controller, Object[] arguments)
 at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.<InvokeActionMethodAsync>g__Logged|12_1(ControllerActionInvoker invoker)
 at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.<InvokeNextActionFilterAsync>g__Awaited|10_0(ControllerActionInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
 at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Rethrow(ActionExecutedContextSealed context)
 at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Next(State& next, Scope& scope, Object& state, Boolean& isCompleted)
 at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.InvokeInnerFilterAsync()
--- End of stack trace from previous location ---
 at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeFilterPipelineAsync>g__Awaited|20_0(ResourceInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
 at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeAsync>g__Logged|17_1(ResourceInvoker invoker)
 at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeAsync>g__Logged|17_1(ResourceInvoker invoker)
 at Microsoft.AspNetCore.Routing.EndpointMiddleware.<Invoke>g__AwaitRequestTask|6_0(Endpoint endpoint, Task requestTask, ILogger logger)
 at Microsoft.AspNetCore.Authorization.AuthorizationMiddleware.Invoke(HttpContext context)
 at Swashbuckle.AspNetCore.SwaggerUI.SwaggerUIMiddleware.Invoke(HttpContext httpContext)
 at Swashbuckle.AspNetCore.Swagger.SwaggerMiddleware.Invoke(HttpContext httpContext, ISwaggerProvider swaggerProvider)
 at Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddleware.Invoke(HttpContext context)

Creando un atributo de filtro de excepción

Microsoft nos ha brindado una forma de manejar las excepciones después de que se hayan generado; puede consultar más información aquí.

Pero hasta el momento la documentación que nos dan es:

Un filtro abstracto que se ejecuta de forma asincrónica después de que una acción haya generado una excepción. Las subclases deben anular OnException(ExceptionContext) o OnExceptionAsync(ExceptionContext), pero no ambos.

Entonces creemos uno, vamos a crear CustomExceptionFilterAttribute en el cual vamos a anular OnException:

using Microsoft.AspNetCore.Mvc.Filters;
using Microsoft.AspNetCore.Mvc;
using CustomExceptionHandleDemo.Exceptions;

namespace CustomExceptionHandleDemo.ExceptionFilterAttributes
{
 public class CustomExceptionFilterAttribute : ExceptionFilterAttribute
 {
 /// <summary>
 /// OnException
 /// </summary>
 /// <param cref="ExceptionContext" name="context">Parameter for context</param>
 public override void OnException(ExceptionContext context)
 {
 if (context.Exception is CustomException)
 {
 context.HttpContext.Response.StatusCode = 500;
 context.Result = new ObjectResult(context.Exception.Message);
 }
 }
 }
}

Como puedes ver, estamos echando un vistazo al ExceptionContext, cuando la excepción es un tipo de CustomException, hacemos algo.

Este algo es actualizar la respuesta y el código de estado de lo que vamos a devolver.

Para actualizar el código de estado, debemos actualizar context.HttpContext.Response.StatusCode y para devolver el resultado, tenemos que actualizar el context.Result dándole un objeto que se hereda de ActionResult.

Este es un filtro, por lo que significa que tenemos que agregarle algo agregando [CustomExceptionFilter].

Usando el filtro

Ahora, repliquemos el método que tenemos y agreguemos este filtro para que entre en acción, nuestro punto final API terminará así:

using CustomExceptionHandleDemo.ExceptionFilterAttributes;
using CustomExceptionHandleDemo.Exceptions;
using Microsoft.AspNetCore.Mvc;

namespace CustomExceptionHandleDemo.Controllers
{
 [ApiController]
 [Route("[controller]")]
 public class WeatherForecastController : ControllerBase
 {
 public WeatherForecastController()
 {
 }

 [HttpGet]
 [Route("GetWithoutExceptionHandler")]
 public Task GetWithoutExceptionHandler()
 {
 throw new CustomException("This is a custom exception!");
 }

 [HttpGet]
 [Route("GetWithExceptionHandler")]
 [CustomExceptionFilter]
 public Task GetWithExceptionHandler()
 {
 throw new CustomException("This is a custom exception!");
 }
 }
}

Como puedes ver, tenemos un nuevo método llamado GetWithExceptionHandler, que tiene la misma lógica que tiene GetWithoutExceptionHandler, pero en este caso, le hemos agregado el filtro [CustomExceptionFilter] al método.

El resultado es el siguiente, después de ejecutar el método, mostraré una imagen, porque ya no muestra el seguimiento de la pila:

Entonces, con esto hemos creado una excepción personalizada, un filtro para anular lo que sucede cuando lanzamos una excepción y la usamos en un método.

Esto se puede utilizar para muchas cosas, como registrar y saber qué, cuándo y dónde ocurre el error.

Una forma más agradable de inyectar cosas.

Mon, 04 Sep 2023 00:00:00 +0000

Siempre que estoy creando cosas como servicios, repositorios, atributos o lo que sea para inyectar en mis aplicaciones, hay un paso que debemos realizar, que en realidad es agregar los servicios a la aplicación.

Esto es siempre lo mismo, vas a Program.cs, luego procedes a agregar en alguna parte del archivo builder.Services.AddScoped<MyService>(); para inyectar el servicio.

Algo como esto:

var builder = WebApplication.CreateBuilder(args);

// Add services to the container.
builder.Services.AddRazorPages();

// Repositories
builder.Services.AddScoped<ARepository>(); // 👀
builder.Services.AddScoped<BRepository>(); // 👀

// Services
builder.Services.AddScoped<AService>(); // 👀
builder.Services.AddScoped<BService>(); // 👀
builder.Services.AddScoped<CService>(); // 👀
builder.Services.AddScoped<DService>(); // 👀

var app = builder.Build();

// Configure the HTTP request pipeline.
if (!app.Environment.IsDevelopment())
{
 app.UseExceptionHandler("/Error");
 // The default HSTS value is 30 days. You may want to change this for production scenarios, see https://aka.ms/aspnetcore-hsts.
 app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

Quiero decir, funciona, pero soy exigente y realmente no me gusta.

Digamos que tenemos múltiples inyecciones de dependencia que queremos hacer, y en realidad no son lo mismo, en mi caso esto podría ser algo así como tener una biblioteca que contenga todos los repositorios, otra biblioteca que tenga todos los servicios y, por último, otra biblioteca que contenga atributos.

En ese caso, ¿te imaginas la cantidad de líneas que tenemos que agregar a Program.cs.

Digamos que tenemos una biblioteca que contiene algunos servicios, si queremos incluir todos nuestros servicios, tenemos que trabajar con IServiceCollection.

Entonces vamos a crear un static class que tendrá un método static llamado AddServices que devuelve un IServiceCollection.

En este caso, se llamará IServiceCollectionServicesExtensions.

/// <summary>
/// IServiceCollectionServicesExtensions class
/// </summary>
public static class IServiceCollectionServicesExtensions
{
 /// <summary>
 /// AddCoreServices
 /// </summary>
 /// <param cref="IServiceCollection" name="services">Parameter for <see cref="IServiceCollection"/></param>
 /// <returns>An object of type <see cref="IServiceCollection"/></returns>
 public static IServiceCollection AddServices(this IServiceCollection services)
 {
 services
 .AddScoped<AService>()
 .AddScoped<BService>()
 .AddScoped<CService>()
 .AddScoped<DService>();

 return services;
 }
}

No solo eso, también tenemos otra biblioteca que incluye algunos repositorios que utilizan estos servicios, así que hagamos lo mismo.

/// <summary>
/// IServiceCollectionServicesExtensions class
/// </summary>
public static class IServiceCollectionServicesExtensions
{
 /// <summary>
 /// AddCoreServices
 /// </summary>
 /// <param cref="IServiceCollection" name="services">Parameter for <see cref="IServiceCollection"/></param>
 /// <returns>An object of type <see cref="IServiceCollection"/></returns>
 public static IServiceCollection AddRepositories(this IServiceCollection services)
 {
 services
 .AddScoped<ARepository>()
 .AddScoped<BRepository>();

 return services;
 }
}

Ahora, tenemos nuestros repositorios y métodos de servicios para inyectar creados, pero ¿cómo los usamos?

Volvamos a nuestro Program.cs y agreguemos lo siguiente:

var builder = WebApplication.CreateBuilder(args);

// Add services to the container.
builder.Services.AddRazorPages();

// Repositories
builder.Services.AddRepositories(); // 👀

// Services
builder.Services.AddServices(); // 👀

var app = builder.Build();

// Configure the HTTP request pipeline.
if (!app.Environment.IsDevelopment())
{
 app.UseExceptionHandler("/Error");
 // The default HSTS value is 30 days. You may want to change this for production scenarios, see https://aka.ms/aspnetcore-hsts.
 app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

Esto parece mucho más limpio, ¿no? Bueno, con eso, hemos inyectado con éxito algunos servicios y repositorios, pero ahora se ve mejor y en realidad tenemos lo que inyectamos en la biblioteca externa.

Inyección de dependencia con atributos en .NET API

Tue, 22 Aug 2023 00:00:00 +0000

La inyección de dependencia es probablemente una de las mejores características que tenemos en .NET en este momento. No hay forma en ningún caso posible de que no lo estés usando, así que si eres como yo, querrás agregarlo a todas las implementaciones que hagas.

Filtros, según la [documentación] oficial de Microsoft (https://learn.microsoft.com/en-us/aspnet/core/mvc/controllers/filters?view=aspnetcore-3.1):

Los filtros en ASP.NET Core permiten que el código se ejecute antes o después de etapas específicas en el proceso de procesamiento de solicitudes.

Los filtros integrados manejan tareas como:

Autorización, que impide el acceso a recursos para los que un usuario no está autorizado.

Almacenamiento en caché de respuestas, cortocircuitando la canalización de solicitudes para devolver una respuesta almacenada en caché.

Se pueden crear filtros personalizados para manejar inquietudes transversales. Ejemplos de preocupaciones transversales incluyen el manejo de errores, el almacenamiento en caché, la configuración, la autorización y el registro. Los filtros evitan duplicar código.

Trabajo mucho con API y hay algunas cosas que deben ejecutarse en cada solicitud, o prácticamente en todas, por lo que idealmente lo que queremos hacer es trabajar con ellas y además… ¡inyección de dependencias!

Pero a veces es un pequeño truco, no funciona como queremos si queremos heredar de ActionAttribute, por lo que necesitamos trabajar con TypeFilterAttribute, lo que nos permite hacer cosas al anular OnActionExecutionAsync.

Normalmente creo estos filtros para realizar algunos registros, así que los usaremos como ejemplo:

/// <summary>
/// LoggedQueryAttribute class
/// </summary>
public class LoggedQueryTypeFilterAttribute : TypeFilterAttribute
{
 /// <summary>
 /// Constructor for <see cref="LoggedQueryTypeFilterAttribute"/>
 /// </summary>
 public LoggedQueryTypeFilterAttribute() : base(typeof(LoggedQueryFilter))
 {
 }

 /// <summary>
 /// LoggedQueryFilter class
 /// </summary>
 private class LoggedQueryFilter : IAsyncActionFilter
 {
 /// <summary>
 /// <see cref="_loggingService"/> object
 /// </summary>
 private readonly LoggingService _loggingService;

 /// <summary>
 /// Constructor for <see cref="LoggedQueryFilter"/>
 /// </summary>
 /// <param cref="LoggingService" name="loggingService">Parameter for loggingService</param>
 public LoggedQueryFilter(LoggingService loggingService)
 {
 _loggingService = loggingService;
 }

 /// <summary>
 /// OnActionExecutionAsync
 /// </summary>
 /// <param cref="ActionExecutingContext" name="context">Parameter for context</param>
 /// <param cref="ActionExecutionDelegate" name="next">Parameter for next</param>
 public async Task OnActionExecutionAsync(ActionExecutingContext context, ActionExecutionDelegate next)
 {
 // Get properties
 var properties = (Request)context.ActionArguments.First().Value!;

 // Get call from context
 var call = context.HttpContext.Request.Path.Value!;

 // Logging
 _loggingService.LogCustomEvent(call);

 // Continue call
 await next();
 }
 }
}

La lógica es bastante simple, obtenemos el cuerpo accediendo al objeto context con context.ActionArguments.First().Value, también obtenemos la llamada al método con context.HttpContext.Request.Path.Value.

Luego simplemente llamamos a nuestro método desde nuestro servicio, en este caso es _loggingService.LogCustomEvent(call).

Luego, debemos llamar a await next();, porque el pipeline debe continuar.

Esto es para el atributo, ahora debemos incluir este atributo en un método.

[LoggedQueryTypeFilterAttribute]
public ActionResult<string> TestFilter()
{
 return Ok("Hello world!");
}

Espero que te haya gustado, si tienes alguna duda o quieres ponerte en contacto, ¡no lo dudes y contacta conmigo!

Documentación de Swagger con bibliotecas externas

Fri, 17 Feb 2023 00:00:00 +0000

Usar varias bibliotecas para dividir el código para casos futuros es algo bueno. Personalmente me encanta hacerlo, si puedo dividir mi lógica para poder reutilizarla en otros proyectos o partes de los proyectos.

Al menos para mí, es imprescindible dividir los modelos de datos, que incluyen el Entity Framework, para que pueda ser referenciado y utilizado en un Console application, un Blazor application o un API.

Echemos un vistazo a un ejemplo de cómo hago las cosas. Esta es una captura de pantalla de un proyecto que tiene algunas aplicaciones y una biblioteca compartida que tiene todos los modelos.

Este es un ejemplo de una clase que moví del proyecto API con documentación con summary en cada propiedad y clase.

namespace CustomLibrariesDocumentation.Models
{
 /// <summary>
 /// WeatherForecast class
 /// </summary>
 public class WeatherForecast
 {
 /// <summary>
 /// Gets or sets the Date
 /// </summary>
 public DateOnly Date { get; set; }

 /// <summary>
 /// Gets or sets the TemperatureC
 /// </summary>
 public int TemperatureC { get; set; }

 /// <summary>
 /// Gets or sets the TemperatureF
 /// </summary>
 public int TemperatureF => 32 + (int)(TemperatureC / 0.5556);

 /// <summary>
 /// Gets or sets the Summary
 /// </summary>
 public string? Summary { get; set; }
 }
}

Si lo referenciamos al Console application y comenzamos a usar el modelo, podemos ver la documentación, esa es una característica estándar en Visual Studio por lo que funciona bien, como puedes ver aquí:

Pero luego, si lo hacemos referencia a API y vamos a Swagger, no hay documentación resumida.

¿Cómo solucionamos esto?

Primero, tenemos que habilitar los comentarios XML en la biblioteca; para hacer esto, necesita actualizar la configuración del proyecto y habilitar ``:

Esto generará algunos archivos en la carpeta de compilación que terminan con la extensión de archivo xml, como puedes ver aquí:

Ahora que hemos hecho esto, tenemos que agregar algunas cosas en Program.cs, para poder leer esos archivos, esto se debe a que de forma predeterminada solo carga la definición XML del proyecto en el que se encuentra.

Utiliza un método que tenemos dentro del AddSwaggerGen que se llama IncludeXmlComments.

La idea es que si tenemos todos los archivos xml, vamos a forzar la carga en el Swagger.

builder.Services.AddSwaggerGen(s =>
{
 // Comments
 var allXmlFiles = Directory.GetFiles(AppContext.BaseDirectory, "*.xml");

 foreach (string xmlFiles in allXmlFiles)
 {
 s.IncludeXmlComments(xmlFiles);
 }
});

Es sencillo, obtenemos los archivos xml del directorio de compilación y los agregamos con el método IncludeXmlComments.

Ahora cargamos nuevamente el API y comprobamos si podemos ver la documentación.

¡Y puedes ver que podemos ver la documentación!

Espero que te haya ayudado, si tienes alguna pregunta ¡no dudes en contactarme!

Limpieza de sucursales locales en Git

Mon, 30 Jan 2023 00:00:00 +0000

¿Alguna vez ha llegado a un punto en el que tenía demasiadas sucursales locales? Me pasa mucho, ya que usamos ramas para cada característica, error o tarea.

Termino con algo como esto y se ensucia mucho después de un tiempo.

Realmente me molesta, así que compartiré un comando rápido que puedes ejecutar en tu consola para realizar esta limpieza.

Encontré este comando en Stack Overflow en la siguiente respuesta de Robert Corvus, que es una versión que se ejecuta en Powerhsell.

Tenga cuidado al ejecutar este comando porque puede perder los cambios

Antes de ejecutarlo recuerda actualizar el MY_MASTER_BRANCH_NAME a tu rama principal, que puede ser master como yo uso o las nuevas que vienen por defecto llamadas main.

git branch | %{ $_.Trim() } | ?{ $_ -ne 'MY_MASTER_BRANCH_NAME' } | %{ git branch -D $_ }

Después de ejecutar este comando, obtendrá un resultado como este

¡Espero que te sea útil!

Actualización de las rutas de Identity en ASP.NET Core 7

Mon, 23 Jan 2023 00:00:00 +0000

¿Incluso te preguntas por qué los nombres de Microsoft son tan raros? Siempre he pensado que no lo hacen tan bien pero bueno, ¡eso es lo que es!

¡Lo bueno de esto es que prácticamente puedes cambiar todo mientras te desarrollas!

¿Alguna vez ha ingresado a una página y se ha dado cuenta instantáneamente de que se trata de un proyecto web ASP.NET con solo realizar el proceso de registro o inicio de sesión?

Me ha pasado mucho porque por defecto en el proyecto que creas, tienes estas URL para hacer el proceso de inicio de sesión y registro (también tienes muchas otras páginas).

¡Así que este tutorial muestra una manera de actualizar esas URL para que se vean mejor en tu proyecto!

Comportamiento predeterminado

Cuando estamos creando un proyecto Blazor y decidimos usarlo con Identity, se muestra algo como esto:

Y cuando intentamos realizar el proceso de inicio de sesión o registro, vamos a /Identity/Account/Login o /Identity/Account/Register.

Pero, ¿qué pasa si te digo que realmente puedes actualizar esas URL para que sean diferentes?

Armado de las páginas `Login` y `Register`

Para actualizar estas páginas, Microsoft las oculta, pero usted puede ampliarlas rápidamente y realizar los cambios que desee.

Para hacer eso, debes ir a Add Scaffolded Item en el menú contextual del proyecto, así:

Luego aparecerá un modal y tendrás que seleccionar Identity dos veces y hacer clic en Add:

Después de este, aparecerá otro modal, donde podrá seleccionar qué páginas de toda la identidad desea actualizar. Hay muchas páginas que puedes actualizar, pero nos centraremos en Account/Login y Account/Register:

Ahora déjelo funcionar por un momento y luego revise el Explorador de soluciones, encontrará algunos archivos nuevos:

¡Estos nuevos archivos son la página de inicio de sesión y registro que ASP.NET agrega a su proyecto cuando lo selecciona para agregar Identidad!

Actualizando URL

Como probablemente habrás notado, estos archivos son archivos razor, ya que su extensión es cshtml, por lo que solo usaremos una directiva para actualizar la URL de la página:

@page "/login"
@model LoginModel

@{
 ViewData["Title"] = "Log in";
}

<h1>@ViewData["Title"]</h1>
<div class="row">
 <div class="col-md-4">
 <section>
 <form id="account" method="post">
 <h2>Use a local account to log in.</h2>
 <hr />
 <div asp-validation-summary="ModelOnly" class="text-danger" role="alert"></div>
 <div class="form-floating mb-3">
 <input asp-for="Input.Email" class="form-control" autocomplete="username" aria-required="true" placeholder="name@example.com" />
 <label asp-for="Input.Email" class="form-label">Email</label>
 <span asp-validation-for="Input.Email" class="text-danger"></span>
 </div>
 <div class="form-floating mb-3">
 <input asp-for="Input.Password" class="form-control" autocomplete="current-password" aria-required="true" placeholder="password" />
 <label asp-for="Input.Password" class="form-label">Password</label>
 <span asp-validation-for="Input.Password" class="text-danger"></span>
 </div>
 <div class="checkbox mb-3">
 <label asp-for="Input.RememberMe" class="form-label">
 <input class="form-check-input" asp-for="Input.RememberMe" />
 @Html.DisplayNameFor(m => m.Input.RememberMe)
 </label>
 </div>
 <div>
 <button id="login-submit" type="submit" class="w-100 btn btn-lg btn-primary">Log in</button>
 </div>
 <div>
 <p>
 <a id="forgot-password" asp-page="./ForgotPassword">Forgot your password?</a>
 </p>
 <p>
 <a asp-page="./Register" asp-route-returnUrl="@Model.ReturnUrl">Register as a new user</a>
 </p>
 <p>
 <a id="resend-confirmation" asp-page="./ResendEmailConfirmation">Resend email confirmation</a>
 </p>
 </div>
 </form>
 </section>
 </div>
 <div class="col-md-6 col-md-offset-2">
 <section>
 <h3>Use another service to log in.</h3>
 <hr />
 @{
 if ((Model.ExternalLogins?.Count ?? 0) == 0)
 {
 <div>
 <p>
 There are no external authentication services configured. See this <a href="https://go.microsoft.com/fwlink/?LinkID=532715">article
 about setting up this ASP.NET application to support logging in via external services</a>.
 </p>
 </div>
 }
 else
 {
 <form id="external-account" asp-page="./ExternalLogin" asp-route-returnUrl="@Model.ReturnUrl" method="post" class="form-horizontal">
 <div>
 <p>
 @foreach (var provider in Model.ExternalLogins!)
 {
 <button type="submit" class="btn btn-primary" name="provider" value="@provider.Name" title="Log in using your @provider.DisplayName account">@provider.DisplayName</button>
 }
 </p>
 </div>
 </form>
 }
 }
 </section>
 </div>
</div>

@section Scripts {
 <partial name="_ValidationScriptsPartial" />
}

Como puedes ver, la mayoría de las cosas son iguales, pero si echas un vistazo a la primera línea de la clase, actualicé lo que teníamos antes:

@page

@page "/login"

Bueno, eso fue fácil, ¿no? Ahora hagamos una prueba rápida para ver si funciona.

En primer lugar, vayamos a la página predeterminada que tenemos al principio, para comprobar si todavía funciona:

¡Lo cual no es así! Ahora vamos a probar nuestra nueva URL que es /login:

¡¡Y funciona!!

Ahora hagamos lo mismo con el registro, actualizamos su página y agregamos la ruta que queremos en la directiva @page ¡y hagamos una prueba!

@page "/register"
@model RegisterModel
@{
 ViewData["Title"] = "Register";
}

<h1>@ViewData["Title"]</h1>

<div class="row">
 <div class="col-md-4">
 <form id="registerForm" asp-route-returnUrl="@Model.ReturnUrl" method="post">
 <h2>Create a new account.</h2>
 <hr />
 <div asp-validation-summary="ModelOnly" class="text-danger" role="alert"></div>
 <div class="form-floating mb-3">
 <input asp-for="Input.Email" class="form-control" autocomplete="username" aria-required="true" placeholder="name@example.com" />
 <label asp-for="Input.Email">Email</label>
 <span asp-validation-for="Input.Email" class="text-danger"></span>
 </div>
 <div class="form-floating mb-3">
 <input asp-for="Input.Password" class="form-control" autocomplete="new-password" aria-required="true" placeholder="password" />
 <label asp-for="Input.Password">Password</label>
 <span asp-validation-for="Input.Password" class="text-danger"></span>
 </div>
 <div class="form-floating mb-3">
 <input asp-for="Input.ConfirmPassword" class="form-control" autocomplete="new-password" aria-required="true" placeholder="password" />
 <label asp-for="Input.ConfirmPassword">Confirm Password</label>
 <span asp-validation-for="Input.ConfirmPassword" class="text-danger"></span>
 </div>
 <button id="registerSubmit" type="submit" class="w-100 btn btn-lg btn-primary">Register</button>
 </form>
 </div>
 <div class="col-md-6 col-md-offset-2">
 <section>
 <h3>Use another service to register.</h3>
 <hr />
 @{
 if ((Model.ExternalLogins?.Count ?? 0) == 0)
 {
 <div>
 <p>
 There are no external authentication services configured. See this <a href="https://go.microsoft.com/fwlink/?LinkID=532715">article
 about setting up this ASP.NET application to support logging in via external services</a>.
 </p>
 </div>
 }
 else
 {
 <form id="external-account" asp-page="./ExternalLogin" asp-route-returnUrl="@Model.ReturnUrl" method="post" class="form-horizontal">
 <div>
 <p>
 @foreach (var provider in Model.ExternalLogins!)
 {
 <button type="submit" class="btn btn-primary" name="provider" value="@provider.Name" title="Log in using your @provider.DisplayName account">@provider.DisplayName</button>
 }
 </p>
 </div>
 </form>
 }
 }
 </section>
 </div>
</div>

@section Scripts {
 <partial name="_ValidationScriptsPartial" />
}

Actualicé la parte superior con @page "/login" y ahora probamos si funciona:

¡¡También funciona!!

Eso es todoEspero que hayas aprendido cómo actualizar estas URL, principalmente porque en algunos proyectos, cuando haces las URL de cierta manera y luego la identidad se ve diferente, ¡apesta jaja!

Si necesitas algo, envíame un tweet o envíame un correo electrónico e intentaré echarte una mano.

Atributos personalizados en .NET 6 Core API

Fri, 09 Dec 2022 00:00:00 +0000

Los atributos personalizados son realmente buenos de usar, comencé a usarlos hace muy poco tiempo, porque me permiten crear uno solo de ellos y reutilizarlos en el controlador, la clase o el método en sí.

Realmente ayudan cuando quieres hacer algunas cosas de seguridad como verificar encabezados o verificar el valor de un parámetro que definitivamente necesitas.

En mi caso, lo usaremos en un proyecto API de .NET Core, donde verificaremos si todas las solicitudes contienen un encabezado determinado.

EncabezadoCheckAttribute

Entonces, después de crear nuestra excelente API .NET Core, creemos una carpeta para almacenar nuestras cosas, porque nos gusta usar carpetas.

Y luego vamos a agregar la lógica a nuestra clase HeaderCheckAttribute.

using Microsoft.AspNetCore.Mvc;
using Microsoft.AspNetCore.Mvc.Filters;

namespace DotNet6CustomAttribute.Attributes
{
 public class HeaderCheckAttribute : ActionFilterAttribute
 {
 public override void OnActionExecuting(ActionExecutingContext context)
 {
 // Get all headers
 var headers = context.HttpContext.Request.Headers;

 // Check if headers has x-dotnet-6-custom-attribute
 if (!headers.ContainsKey("x-dotnet-6-custom-attribute"))
 {
 context.Result = new BadRequestObjectResult("The header x-dotnet-6-custom-attribute is missing");
 }
 else if (string.IsNullOrEmpty(headers["x-dotnet-6-custom-attribute"]))
 {
 context.Result = new BadRequestObjectResult("The header x-dotnet-6-custom-attribute can't be null or empty");
 }

 base.OnActionExecuting(context);
 }
 }
}

Básicamente, la lógica es que primero busca un encabezado con la clave x-dotnet-6-custom-attribute y, si está allí, verifica si tiene valores.

Si ambas expresiones son verdaderas, devolverá un BadRequestObjectResult con un mensaje determinado.

Agregándolo al controlador

Podemos agregar esta lógica a varios lugares, podemos agregarla directamente a todo el controlador, o podemos agregarla a algunos de los métodos, primero la agregaremos a los métodos y luego a todo el controlador.

Así que decoremos la clase WeatherForecastController con ellos.

using DotNet6CustomAttribute.Attributes;
using Microsoft.AspNetCore.Mvc;

namespace DotNet6CustomAttribute.Controllers
{
 [ApiController]
 [Route("[controller]")]
 public class WeatherForecastController : ControllerBase
 {
 private static readonly string[] Summaries = new[]
 {
 "Freezing", "Bracing", "Chilly", "Cool", "Mild", "Warm", "Balmy", "Hot", "Sweltering", "Scorching"
 };

 private readonly ILogger<WeatherForecastController> _logger;

 public WeatherForecastController(ILogger<WeatherForecastController> logger)
 {
 _logger = logger;
 }

 [HttpGet]
 [Route("GetWeatherForecastWithCheck")]
 [HeaderCheckAttribute]
 public IEnumerable<WeatherForecast> GetWithCheck()
 {
 return Enumerable.Range(1, 5).Select(index => new WeatherForecast
 {
 Date = DateTime.Now.AddDays(index),
 TemperatureC = Random.Shared.Next(-20, 55),
 Summary = Summaries[Random.Shared.Next(Summaries.Length)]
 })
 .ToArray();
 }

 [HttpGet]
 [Route("GetWeatherForecastWithoutCheck")]
 public IEnumerable<WeatherForecast> GetWithoutCheck()
 {
 return Enumerable.Range(1, 5).Select(index => new WeatherForecast
 {
 Date = DateTime.Now.AddDays(index),
 TemperatureC = Random.Shared.Next(-20, 55),
 Summary = Summaries[Random.Shared.Next(Summaries.Length)]
 })
 .ToArray();
 }
 }
}

¡Vamos a ejecutar el proyecto!

Tenemos 2 funciones ahí: GetWeatherForecastWithCheck y GetWeatherForecastWithoutCheck, una de ellas fallará y la otra no, ¡pero veámoslo en Swagger!

Como puede ver, uno de ellos devuelve un error 400 con nuestro mensaje y el otro devuelve los valores. Ahora, para probar esto completamente, ejecutemos Postman y agreguemos un encabezado para que también veamos los datos usando GetWeatherForecastWithCheck.

cartero

Ahora, ejecutando Postman, agregamos el encabezado y vemos que el mensaje de error ha cambiado, ya que ahora proporcionamos el encabezado pero no tiene ningún valor.

Si le agregamos un valor, ¡finalmente obtenemos los valores!

Eso es todo

¡Pues eso es todo! Bastante simple ¿verdad? ¡Bueno, ahora sabes cómo crear un atributo y asignarlo a métodos y controladores!

¡Diviértete con ellos!

Código

¡Este proyecto completo está en Github y puedes encontrarlo aquí!

Si tienes algún problema o pregunta, no dudes en contactarme en cualquier red social en @emimontesdeoca (en Twitter en realidad es @emimontesdeocaa con dos aa al final). También puedes encontrar la mayoría de mis redes sociales en el encabezado del blog.

Espero que os haya gustado el post! ¡Cya!

Manejar la carga de componentes en Blazor

Tue, 19 Jul 2022 00:00:00 +0000

Blazor es asombroso, realmente asombroso, especialmente cuando hacemos cosas asincrónicas como cargar cuadros y simplemente se ve bien.

He estado intentando hacer varias formas de manejar la carga de páginas, estados, componentes, etc. Y creo que finalmente encontré la manera perfecta de hacerlo de la manera que quiero.

#idea

En lugar de reescribir la lógica para cargar en cada página o componente, creamos el componente principal con un ChildComponent, esto nos dará el cambio para simplemente reutilizarlo varias veces.

Cargando código de componente

Aunque el código es bastante simple, no hay mucho que hacer, un if básico con una propiedad de carga, una función de alternancia interna y ¡listo!

@if (_loaded)
{
 <div class="text-center">
 <div class="spinner-border" role="status">
 <span class="sr-only"></span>
 </div>
 </div>
}
else
{
 @ChildContent
}

@code {
 private bool _loaded = true;

 [Parameter]
 public RenderFragment? ChildContent { get; set; }

 public void ToggleLoad(bool state)
 {
 _loaded = state;
 }
}

Uso

El uso es bastante simple, para realizar pruebas usaremos una nueva página y colocaremos nuestro contenido dentro del componente LoadingComponent creado que acabamos de crear.

@page "/loading"
@using LoadingBoxes.Components

<LoadingBoxes.Components.LoadingComponent @ref=loadingComponent>
 This is some content
</LoadingBoxes.Components.LoadingComponent>

@code {
 private LoadingComponent loadingComponent;


 protected override async Task OnInitializedAsync()
 {
 // We are going to simulate some load
 await Task.Delay(5000);

 loadingComponent.ToggleLoad(false);
 }

}

así es como se ve

Ejemplo más divertido

Digamos que tenemos múltiples componentes y cada uno de ellos tiene sus tiempos de carga, ¡podemos construir algo que se vea bien con eso!

Creemos un componente de carga falso que podamos reutilizar llamado FakeLoadingComponent.

@using LoadingBoxes.Components

<LoadingBoxes.Components.LoadingComponent @ref=loadingComponent>
 It took @ellapsedTime seconds!
</LoadingBoxes.Components.LoadingComponent>

@code {
 private LoadingComponent loadingComponent = new();
 private int ellapsedTime = 0;
 private Random rnd = new();

 protected override async Task OnInitializedAsync()
 {
 var random = rnd.Next(0, 5000);

 // We are going to simulate some load
 await Task.Delay(random);

 ellapsedTime = random/ 1000;

 loadingComponent.ToggleLoad(false);
 StateHasChanged();
 }
}

Luego simplemente actualizamos la página Loading con múltiples componentes FakeLoadingComponent y verificamos el resultado.

@page "/loading"
@using LoadingBoxes.Components

<FakeLoadingComponent/>
<FakeLoadingComponent/>
<FakeLoadingComponent/>
<FakeLoadingComponent/>
<FakeLoadingComponent/>

Ahora esto se ve mucho mejor

¡Y eso es todo!

Espero que os haya gustado el post!

Obtener la fecha de vencimiento de un certificado

Fri, 27 May 2022 00:00:00 +0000

Existen algunas aplicaciones web que lo ayudan a verificar el estado actual de los certificados de los dominios que utilizamos, y tenemos algunas de ellas.

Creé una función de Azure que se ejecuta una vez al día y verifica algunos de los dominios que necesito revisar. Es una aplicación de consola súper simple que si la fecha de vencimiento del certificado es inferior a 30 días, enviará un correo electrónico.

No se mostrará la lógica misma de cómo funciona la función, me gustaría mostrar la función que realiza la verificación base del certificado y qué datos obtenemos.

La función

static async Task<X509Certificate2> CheckCertificateAsync(string urlPath)
{
 var certificate = new X509Certificate2();
 var httpClientHandler = new HttpClientHandler
 {
 ServerCertificateCustomValidationCallback = (request, cert, chain, policyErrors) =>
 {
 certificate = new X509Certificate2(cert);
 return true;
 }
 };

 using HttpClient httpClient = new HttpClient(httpClientHandler);
 await httpClient.SendAsync(new HttpRequestMessage(HttpMethod.Head, urlPath));

 return certificate;
}

Este método CheckCertificateAsync nos devolverá un certificado X509Certificate2 que nos permitirá hacer un montón de cosas, incluido echar un vistazo a la fecha de vencimiento.

Resultado serializado

Este es el valor serializado del objeto certificate:

{
 "Archived":false,
 "Extensions":[
 {
 "KeyUsages":160,
 "Critical":true,
 "Oid":{
 "Value":"2.5.29.15",
 "FriendlyName":"Key Usage"
 },
 "RawData":"AwIFoA=="
 },
 {
 "EnhancedKeyUsages":[
 {
 "Value":"1.3.6.1.5.5.7.3.1",
 "FriendlyName":"Server Authentication"
 },
 {
 "Value":"1.3.6.1.5.5.7.3.2",
 "FriendlyName":"Client Authentication"
 }
 ],
 "Critical":false,
 "Oid":{
 "Value":"2.5.29.37",
 "FriendlyName":"Enhanced Key Usage"
 },
 "RawData":"MBQGCCsGAQUFBwMBBggrBgEFBQcDAg=="
 },
 {
 "CertificateAuthority":false,
 "HasPathLengthConstraint":false,
 "PathLengthConstraint":0,
 "Critical":true,
 "Oid":{
 "Value":"2.5.29.19",
 "FriendlyName":"Basic Constraints"
 },
 "RawData":"MAA="
 },
 {
 "SubjectKeyIdentifier":"634E1585565AA49402C21642A4A5979A38025797",
 "Critical":false,
 "Oid":{
 "Value":"2.5.29.14",
 "FriendlyName":"Subject Key Identifier"
 },
 "RawData":"BBRjThWFVlqklALCFkKkpZeaOAJXlw=="
 },
 {
 "Critical":false,
 "Oid":{
 "Value":"2.5.29.35",
 "FriendlyName":"Authority Key Identifier"
 },
 "RawData":"MBaAFBQusxe3WFbLrlAJQOYfr52LFMLG"
 },
 {
 "Critical":false,
 "Oid":{
 "Value":"1.3.6.1.5.5.7.1.1",
 "FriendlyName":"Authority Information Access"
 },
 "RawData":"MEcwIQYIKwYBBQUHMAGGFWh0dHA6Ly9yMy5vLmxlbmNyLm9yZzAiBggrBgEFBQcwAoYWaHR0cDovL3IzLmkubGVuY3Iub3JnLw=="
 },
 {
 "Critical":false,
 "Oid":{
 "Value":"2.5.29.17",
 "FriendlyName":"Subject Alternative Name"
 },
 "RawData":"MB6CHGJsb2cuZW1pbGlhbm9tb250ZXNkZW9jYS5jb20="
 },
 {
 "Critical":false,
 "Oid":{
 "Value":"2.5.29.32",
 "FriendlyName":"Certificate Policies"
 },
 "RawData":"MEMwCAYGZ4EMAQIBMDcGCysGAQQBgt8TAQEBMCgwJgYIKwYBBQUHAgEWGmh0dHA6Ly9jcHMubGV0c2VuY3J5cHQub3Jn"
 },
 {
 "Critical":false,
 "Oid":{
 "Value":"1.3.6.1.4.1.11129.2.4.2",
 "FriendlyName":"SCT List"
 },
 "RawData":"BIH0APIAdwBByMqx3yJGShDGoToJQodeTjGLGwPr60vHaPCQYpYG9gAAAYCeJIwYAAAEAwBIMEYCIQCG8sf4iBitUjNCc1dsxVd5mdRQCKapRqqnTHKxSKHjHgIhAJFGNXEZkCHKygT1T7bE4orpd6p2l1+GmifMEIuRsgHbAHcARqVV63X6kSAwtaKJafTzfREsQXS+/Um4havy/HD+bUcAAAGAniSMNgAABAMASDBGAiEAoxv1LBn/vfyR7s67kRLB/n1tq3eicuA/8/V0S2YzQCYCIQDXaS3FZbdIVNxQvKxPFxM1awBO/sGxBXafz0lspOoWSA=="
 }
 ],
 "FriendlyName":"",
 "HasPrivateKey":false,
 "PrivateKey":null,
 "IssuerName":{
 "Name":"CN=R3, O=Let's Encrypt, C=US",
 "Oid":{
 "Value":null,
 "FriendlyName":null
 },
 "RawData":"MDIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQDEwJSMw=="
 },
 "NotAfter":"2022-08-05T10:50:35+01:00",
 "NotBefore":"2022-05-07T10:50:36+01:00",
 "PublicKey":{
 "EncodedKeyValue":{
 "Oid":{
 "Value":"1.2.840.113549.1.1.1",
 "FriendlyName":"RSA"
 },
 "RawData":"MIIBCgKCAQEAq8cbDO3GAfjqqbPPCBdPost8NMRmEubv85gXecll7mZMH5qSfTPuB/ouFWL3tPMf1U8usWeoSUK/48yatzBGwmj1KKlkaW9MS2QkydztRp+kH8LvbzbQvGknuOLWGHBALLT17o/3DYxuA5LnXdY+vLvJWygQoFr2N/XhnhUjcm6OaQEJpIykydfbBQGQSEuQIIw4egpgdHkYJjCOYAsXuSSggN8/FADTCec0RzVjfFTSoJ3hV9HLE9M8MCSXjuo0AJ/MbAxq91S8XmDcRjHCCd7Zw+NjHo8cxZCQ6NqGvn3xwx8ahmmbC+CyDEcIyJJZK2Yv+qE4oS8QZfaX/RaHMwIDAQAB"
 },
 "EncodedParameters":{
 "Oid":{
 "Value":"1.2.840.113549.1.1.1",
 "FriendlyName":"RSA"
 },
 "RawData":"BQA="
 },
 "Key":{
 "Key":{
 "Algorithm":{
 "Algorithm":"RSA"
 },
 "AlgorithmGroup":{
 "AlgorithmGroup":"RSA"
 },
 "ExportPolicy":0,
 "Handle":{
 "IsInvalid":false,
 "IsClosed":false
 },
 "IsEphemeral":true,
 "IsMachineKey":false,
 "KeyName":null,
 "KeySize":2048,
 "KeyUsage":16777215,
 "ParentWindowHandle":{
 "value":0
 },
 "Provider":{
 "Provider":"Microsoft Software Key Storage Provider"
 },
 "ProviderHandle":{
 "IsInvalid":false,
 "IsClosed":false
 },
 "UIPolicy":{
 "ProtectionLevel":0,
 "FriendlyName":null,
 "Description":null,
 "UseContext":null,
 "CreationTitle":null
 },
 "UniqueName":null
 },
 "LegalKeySizes":[
 {
 "MinSize":512,
 "MaxSize":16384,
 "SkipSize":64
 }
 ],
 "KeyExchangeAlgorithm":"RSA",
 "SignatureAlgorithm":"RSA",
 "KeySize":2048
 },
 "Oid":{
 "Value":"1.2.840.113549.1.1.1",
 "FriendlyName":"RSA"
 }
 },
 "RawData":"MIIFQDCCBCigAwIBAgISBNwTmwP/RTcrEeIgAdMrpaFtMA0GCSqGSIb3DQEBCwUAMDIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQDEwJSMzAeFw0yMjA1MDcwOTUwMzZaFw0yMjA4MDUwOTUwMzVaMCcxJTAjBgNVBAMTHGJsb2cuZW1pbGlhbm9tb250ZXNkZW9jYS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCrxxsM7cYB+Oqps88IF0+iy3w0xGYS5u/zmBd5yWXuZkwfmpJ9M+4H+i4VYve08x/VTy6xZ6hJQr/jzJq3MEbCaPUoqWRpb0xLZCTJ3O1Gn6Qfwu9vNtC8aSe44tYYcEAstPXuj/cNjG4Dkudd1j68u8lbKBCgWvY39eGeFSNybo5pAQmkjKTJ19sFAZBIS5AgjDh6CmB0eRgmMI5gCxe5JKCA3z8UANMJ5zRHNWN8VNKgneFX0csT0zwwJJeO6jQAn8xsDGr3VLxeYNxGMcIJ3tnD42MejxzFkJDo2oa+ffHDHxqGaZsL4LIMRwjIklkrZi/6oTihLxBl9pf9FoczAgMBAAGjggJZMIICVTAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMAwGA1UdEwEB/wQCMAAwHQYDVR0OBBYEFGNOFYVWWqSUAsIWQqSll5o4AleXMB8GA1UdIwQYMBaAFBQusxe3WFbLrlAJQOYfr52LFMLGMFUGCCsGAQUFBwEBBEkwRzAhBggrBgEFBQcwAYYVaHR0cDovL3IzLm8ubGVuY3Iub3JnMCIGCCsGAQUFBzAChhZodHRwOi8vcjMuaS5sZW5jci5vcmcvMCcGA1UdEQQgMB6CHGJsb2cuZW1pbGlhbm9tb250ZXNkZW9jYS5jb20wTAYDVR0gBEUwQzAIBgZngQwBAgEwNwYLKwYBBAGC3xMBAQEwKDAmBggrBgEFBQcCARYaaHR0cDovL2Nwcy5sZXRzZW5jcnlwdC5vcmcwggEGBgorBgEEAdZ5AgQCBIH3BIH0APIAdwBByMqx3yJGShDGoToJQodeTjGLGwPr60vHaPCQYpYG9gAAAYCeJIwYAAAEAwBIMEYCIQCG8sf4iBitUjNCc1dsxVd5mdRQCKapRqqnTHKxSKHjHgIhAJFGNXEZkCHKygT1T7bE4orpd6p2l1+GmifMEIuRsgHbAHcARqVV63X6kSAwtaKJafTzfREsQXS+/Um4havy/HD+bUcAAAGAniSMNgAABAMASDBGAiEAoxv1LBn/vfyR7s67kRLB/n1tq3eicuA/8/V0S2YzQCYCIQDXaS3FZbdIVNxQvKxPFxM1awBO/sGxBXafz0lspOoWSDANBgkqhkiG9w0BAQsFAAOCAQEAjSEID5MWonbSiyHbmPYWO8ImCCOjkLGxgY8WJODbrWxFy+xU44UwrWOCkqYZUlv2LRmPqSyZDrIeeHK9VMbGh71oXX+XovikgAr6PpI0Mp897nPWj0XvOBaSYG0s+f+CXMtyt0tWCsQOcl+iT82+Ja71f8gbVL6l7xESewEE78pTKEH8EqD22r8VSD7FNICD8EYQr13v3AuVWObSU/R8Td6SrSVEknw1HgJS4e9nvmrMxBGKOJ+aWrAGiUydehg8M9o2gbGckMhz6D7cwB5l618cYaXKkW1dEOYZHl++qUj1/VPK+FNkiDZOPVNN//PbZuOLwAUIlZvhqGWX5/9PBg==",
 "SerialNumber":"04DC139B03FF45372B11E22001D32BA5A16D",
 "SignatureAlgorithm":{
 "Value":"1.2.840.113549.1.1.11",
 "FriendlyName":"sha256RSA"
 },
 "SubjectName":{
 "Name":"CN=blog.emilianomontesdeoca.com",
 "Oid":{
 "Value":null,
 "FriendlyName":null
 },
 "RawData":"MCcxJTAjBgNVBAMTHGJsb2cuZW1pbGlhbm9tb250ZXNkZW9jYS5jb20="
 },
 "Thumbprint":"28CF960F772ABFF22AA193C291492C27F8E13D4D",
 "Version":3,
 "Handle":{
 "value":2658150705632
 },
 "Issuer":"CN=R3, O=Let's Encrypt, C=US",
 "Subject":"CN=blog.emilianomontesdeoca.com"
}

Fecha de vencimiento

Para saber el tiempo de vencimiento, debemos echar un vistazo a los NotAfter y NotBefore, que se encuentran dentro de este objeto:

 "NotAfter":"2022-08-05T10:50:35+01:00",
 "NotBefore":"2022-05-07T10:50:36+01:00",

Aplicación de consola

El siguiente fragmento es una aplicación de consola simple construida en .NET 6, que producirá el siguiente resultado, en el que podrá verificar cualquiera de las certificaciones que desee:

using Newtonsoft.Json;
using System.Net;
using System.Security.Cryptography.X509Certificates;
using System.Text.Json;

var url = "https://blog.emilianomontesdeoca.com/";

static async Task<X509Certificate2> CheckCertificateAsync(string urlPath)
{
 var certificate = new X509Certificate2();
 var httpClientHandler = new HttpClientHandler
 {
 ServerCertificateCustomValidationCallback = (request, cert, chain, policyErrors) =>
 {
 certificate = new X509Certificate2(cert);
 return true;
 }
 };

 using HttpClient httpClient = new HttpClient(httpClientHandler);
 await httpClient.SendAsync(new HttpRequestMessage(HttpMethod.Head, urlPath));

 return certificate;
}

var cert = await CheckCertificateAsync(url);

var serializedValue = JsonConvert.SerializeObject(cert);

Console.WriteLine(serializedValue);

Console.ReadLine();

Proyecto de demostración

Puedes encontrar la aplicación de consola en mi Github, en el repositorio llamado fecha-de-expiración-certificado.

Enfocando un elemento en Blazor

Thu, 05 May 2022 00:00:00 +0000

Después de trabajar en el juego Wordlzor que hice recientemente, necesitaba agregar una funcionalidad bastante simple: enfocar todo el juego al ingresar.

Esto debía hacerse porque el usuario podía escribir en el juego y no solo usar el teclado en pantalla.

archivo Javascript

Para hacer esto, tenemos que crear un archivo Javascript llamado app.js que contendrá una función

window.FocusElement = (element) => {
 element.focus();
};

Una vez hecho esto, debemos incluir el script en el archivo index.html:

<script src="js/app.js"></script>

Componente Blazor

Una vez que hemos inicializado el script, necesitamos encontrar un elemento en el que enfocarnos, por lo que en cualquiera de nuestros componentes, debemos hacer referencia a ese elemento a un objeto.

Entonces, en nuestro componente Blazor, agreguemos un div con el Propiedad @ref:

<div @ref=@elementToFocus tabindex="0" >
 This is my focus component
</div>

Luego, en la lógica del componente, puede tener la propiedad como ElementReference:

/// <summary>
/// Reference to element
/// </summary>
private ElementReference elementToFocus;

Inyectando JSInterop

Ahora, para poder llamar a la función que tenemos en nuestro archivo Javascript, necesitamos usar JSInterop.

Primero que nada debemos inyectarlo en un componente con la siguiente sintaxis:

[Inject]
public IJSRuntime JSRuntime { get; set; }

Con el servicio inyectado, ahora podemos llamar a cualquiera de los métodos que tiene, como InvokeVoidAsync, que llamará a la función:

public async Task Focus()
{
 // Focus when initializing
 await JSRuntime.InvokeVoidAsync("window.FocusElement", elementToFocus);
}

Y cuando llamas a la función Focus(), se enfocará en el elemento que creamos, obviamente puedes refactorizar y pasar el elemento en sí como parámetro.

Si quieres ver cómo lo implementé, mira el código fuente de Wordlzor, lo usé para alertas y enfoque al cerrar el modal de instrucciones.

Genere archivos *.dacpac desde el proyecto de base de datos VS en GitHub Actions

Mon, 18 Apr 2022 00:00:00 +0000

Si necesita trabajar con bases de datos y desea realizar un desarrollo ágil, debe tener un flujo en el que cada vez que agregue o modifique una tabla, SP o función, la compilará y generará el archivo de implementación para la base de datos.

He estado haciendo este método durante mucho tiempo, hacemos los cambios en local, los comparamos con nuestro proyecto de base de datos y luego, cuando confirmamos y publicamos nuestros cambios, generan un archivo bacpac que irá a la base de datos.

Elimina todos los problemas de hacerlo a mano, lo que puede provocar un error humano y en una base de datos, eso es realmente una mala noticia.

Proyecto de base de datos

Cuando creamos nuestro proyecto de base de datos en Visual Studio e importamos una base de datos, terminará así

Cuando ejecutemos una compilación en este proyecto, generará un archivo dacpac que incluirá toda nuestra estructura.

Canalización de Github

Ahora que tenemos nuestro código publicado en el repositorio, necesitamos crear una acción que compilará este proyecto, generará este archivo dacpac y lo colocará en algún lugar donde podamos descargarlo o usarlo para otro paso.

name: DacpacGithubActions project build

on:
 push:
 branches: main

jobs:
 build:
 runs-on: windows-latest

 steps:
 - uses: actions/checkout@v2

 - name: Setup MSBuild
 uses: microsoft/setup-msbuild@v1

 - name: Navigate to Workspace
 run: cd $GITHUB_WORKSPACE

 - name: Create Build Directory
 run: mkdir artifacts

 - name: Build Solution
 run: |
 msbuild.exe /t:DacpacGithubActions /p:DebugSymbols=false /p:DebugType=None /p:DeployOnBuild=true /p:WebPublishMethod=FileSystem /p:OutDir="../artifacts"
 
 - name: Upload artifact
 uses: actions/upload-artifact@v1.0.0
 with:
 name: DacpacGithubActionsArtifacts
 path: "../artifacts"

Esta acción hará un montón de cosas, creará la solución y colocará el resultado en la carpeta artifacts, creada de antemano, luego cargará los archivos de esa carpeta a los artefactos.

Ejecutando la tubería

Ahora continúe y active una compilación, el resultado debería ser el siguiente

Si realmente descargamos el artefacto y echamos un vistazo al contenido, eso es lo que necesitaremos para el futuro, cuando implementemos un paso de implementación continua, ¡el archivo dacpac!

Código

¡Este proyecto completo está en Github y puedes encontrarlo aquí!

Espero que os haya gustado el post! ¡Cya!

Alternar temas con Javascript Interop en Blazor

Fri, 01 Apr 2022 00:00:00 +0000

Para personas como yo que sufren flashbacks cada vez que abro una página web, se me ocurrió una solución súper simple sobre cómo alternar entre el modo claro y oscuro usando Javascript y llamarlo desde Blazor usando Javascript Interop.

Estableciendo el atributo padre

Primero que nada tenemos que identificar el elemento padre con un identificador, esto se debe a que cambiamos los colores dependiendo del valor de ese identificador.

Para hacer eso en Javascript, tendríamos que ejecutar este comando

document.documentElement.setAttribute('data-theme', 'YOUR_IDFENTIFIER');

En nuestro caso queremos tener dos identificadores para cada tipo de estilo, que son light y dark.

Creando un archivo Javascript para manejar la lógica

Ahora tenemos la función para actualizar el identificador, ahora creemos un archivo Javscript con una función que ejecute esa lógica. Nuestro archivo se llamará app.js

En ese archivo tendremos una función que llamará al código que mencionamos anteriormente.

var toggleTheme = function (identifier) {
 document.documentElement.setAttribute('data-theme', identifier);
}

Agregar un archivo Javascript a Blazor

Agregue el script a la aplicación Blazor agregándolo donde se encuentran los scripts.

<script src="~/js/app.js"></script>

Creando el servicio

Ahora que tenemos el código Javascript, necesitamos crear un servicio que se llamará ThemeToggleService.

Este servicio manejará la lógica para alternar entre el tema light y dark.

Inyectando JSInterop

Para llamar a cualquier Javascipt, tenemos que llamar a JSInterop, por lo que debemos crear una propiedad que inyectará.

using Microsoft.AspNetCore.Components;
using Microsoft.JSInterop;

namespace BlazorDarkmodeToggle.Data
{
 private readonly IJSRuntime jSRuntime;

 public ThemeToggleService(IJSRuntime jSRuntime)
 {
 this.jSRuntime = jSRuntime;
 }
}

Función para configurar el identificador

Ahora que tenemos el servicio creado, creemos la función para configurar el identificador, esta función simplemente actualizará el data-theme en la página.

using Microsoft.AspNetCore.Components;
using Microsoft.JSInterop;

namespace BlazorDarkmodeToggle.Data
{
 public class ThemeToggleService
 {
 private readonly IJSRuntime jSRuntime;

 public ThemeToggleService(IJSRuntime jSRuntime)
 {
 this.jSRuntime = jSRuntime;
 }

 public bool IsLightTheme { get; set; } = true;
 public string GetIdentifier => IsLightTheme ? "light" : "dark";

 public async Task ToggleTheme() {
 IsLightTheme = !IsLightTheme;
 await jSRuntime.InvokeVoidAsync("toggleTheme", GetIdentifier);
 }
 }
}

Agregar servicio al inicio

Para que el servicio esté disponible para todos los componentes y páginas, debemos agregarlo al archivo Program.cs.

builder.Services.AddSingleton<ThemeToggleService>();

Entonces el archivo terminará así.

using BlazorDarkmodeToggle.Data;
using Microsoft.AspNetCore.Components;
using Microsoft.AspNetCore.Components.Web;

var builder = WebApplication.CreateBuilder(args);

// Add services to the container.
builder.Services.AddRazorPages();
builder.Services.AddServerSideBlazor();
builder.Services.AddSingleton<WeatherForecastService>();
builder.Services.AddSingleton<ThemeToggleService>();

var app = builder.Build();

// Configure the HTTP request pipeline.
if (!app.Environment.IsDevelopment())
{
 app.UseExceptionHandler("/Error");
 // The default HSTS value is 30 days. You may want to change this for production scenarios, see https://aka.ms/aspnetcore-hsts.
 app.UseHsts();
}

app.UseHttpsRedirection();

app.UseStaticFiles();

app.UseRouting();

app.MapBlazorHub();
app.MapFallbackToPage("/_Host");

app.Run();

Tenga en cuenta que esto puede cambiar dependiendo de si usa Blazor Server o Blazor WebAssembly.

Hornear el CSS

Ahora que tenemos parte del código listo, tenemos que empezar a trabajar en el CSS. Lo que tenemos que hacer es establecer todas las propiedades CSS que manejan los colores, el fondo, etc. de CSS en una variable.

:root {
 --background-color:#ffffff;
 --text-color:#000000;
}

Una vez que hayamos hecho esto, usando el identificador, podemos cambiar fácilmente entre los identificadores, y usará cualquiera de otros valores.

[data-theme="dark"] {
 --background-color: #000000;
 --text-color: #ffffff;
}

Para que la animación se desvanezca, simplemente agregaremos una propiedad transition a todo, para que se vea bien.

* {
 transition: all 250ms;
}

Ahora asignaremos estas variables a algunas clases CSS, para que podamos verlas en la página de Blazor.

.app-background {
 background-color: var(--background-color);
 width: 200px;
 height: 200px;
}

.app-text {
 color: var(--text-color);
}

Recuerde agregar el archivo a la aplicación Blazor agregándolo en el head.

<link href="css/app.css" rel="stylesheet" />

Llamando desde Blazor

Entonces, ¿cómo vamos a probar esto? Para hacerlo simple, simplemente agregaremos un div con la clase app-background, y dentro tendrá un p con la clase app-text.Entonces, creemos una página llamada Theme.razor en la carpeta Pages y agreguemos algo de código para eso.

@page "/theme"
@using BlazorDarkmodeToggle.Data
@inject ThemeToggleService ThemeToggleService

<button class="btn btn-primary" @onclick=Toggle>Toggle theme</button>

<br />

<div class="app-background">
 <p class="app-text">Hello world!</p>
</div>

@code{
 public async Task Toggle()
 {
 await this.ThemeToggleService.ToggleTheme();
 }
}

Podríamos probar esto yendo a /theme, pero agreguémoslo también a la barra de navegación.

<div class="nav-item px-3">
 <NavLink class="nav-link" href="theme">
 <span class="oi oi-list-rich" aria-hidden="true"></span> Theme togle
 </NavLink>
</div>

Pruebas

Como puede ver, tan pronto como alternamos los cambios de color de tema, fondo y fuente, ahora puede ver lo poderoso que es, si realmente desarrolla la página completa usando estas variables en CSS, podría tener diferentes temas y simplemente alternarlos.

¡¡Qué genial!!

Código

¡Este proyecto completo está en Github y puedes encontrarlo aquí!

Espero que os haya gustado el post!

Recursos

Llamar a funciones de JavaScript desde métodos .NET en ASP.NET Core Blazor

Carga de archivos a Azure Blob Storage en Blazor

Wed, 23 Mar 2022 00:00:00 +0000

El servicio de almacenamiento Azure Blob es uno de los servicios más utilizados en el ecosistema de Azure y le permite cargar una gran cantidad de archivos a la nube a un precio muy económico. También dispone de una web intuitiva a la que puedes acceder a ellos o descargarla mediante un enlace directo.

En general es un servicio bastante bueno, lo he estado usando tanto para proyectos laborales como personales y, sinceramente, lo mejor es la simplicidad de cómo hacerlo funcionar.

La mayoría de los casos en los que he usado Azure Blob Storage es en el backend, cargando directamente algo que es el resultado de una operación o algo así. Así que realmente no he subido ningún archivo desde un sitio web. ¡Desafortunado!

Como soy fanático de Blazor, les traigo una forma de cargar archivos en Azure Blob Storage utilizando la entrada de archivos nativos de HTML5.

Requisitos previos

Cuenta de Azure (si no la tiene, vaya aquí con un montón de $$$).
Un IDE (VS, Código, cualquiera funcionará)
.NET Core 3.0 o superior

Creación de un almacenamiento de blobs de Azure

Vaya a su portal de Azure y procedamos a crear una cuenta de almacenamiento.

Primero busque Storage accounts y haga clic en el resultado.

Una vez cargado, haga clic en Create.

Aparecerá un formulario con varios pasos, así que continúa y complétalos.

Después de completar todo con la configuración que desee, pase la validación y cree el recurso.

Una vez creado, haga clic en Go to resource. Obtendremos una cadena de conexión que nos permitirá jugar con la API.

Obtener las claves de recursos

Después de llegar a nuestro recurso recién creado, vaya a Acccess keys debajo de Security + networking. Después de cargar verás un Connection string y un Key, ¡cópialos porque los vamos a necesitar más tarde!

Creando un proyecto genial de Blazor Server

Usaré Visual Studio 2022 para este tutorial, pero como dije antes, puedes usar cualquier otro IDE y simplemente crear el proyecto usando la CLI dotnet.

Luego, sigamos adelante y creemos un proyecto Blazor muy rápido usando Visual Studio en solo unos pocos pasos.

Si ejecutamos lo que acabamos de crear, se verá así, simplemente una aplicación Blazor normal y corriente.

Ahora que hemos creado el proyecto, hagamos algunas cosas de la interfaz de usuario para tener una nueva página con un montón de entradas para que podamos completar las claves del recurso, un InputFile para los archivos, un botón para hacer algo y un mensaje que resultará de la acción.

Creando el modelo

Necesitaremos algunos modelos para hacer esto correctamente. Primero tendremos la clase BlobRequest que manejará la cadena de conexión, el nombre del contenedor y los archivos.

Además, para mantener todo ordenado, crearemos una clase llamada BlobFile en la que almacenaremos el Name y el Data.

He creado una carpeta llamada Models para que tengamos todo separado.

Las clases son muy sencillas.```csharp using System.ComponentModel.DataAnnotations;

namespace UploadingFilesAzBlobBlazor.Models { public class BlobRequest { [Required(ErrorMessage = “Connection string is required”)] public string? ConnectionString { get; set; } [Required(ErrorMessage = “Container name is required”)] public string? Container { get; set; } public List? Files { get; set; } } }


```csharp
namespace UploadingFilesAzBlobBlazor.Models
{
 public class BlobFile
 {
 public string? Name { get; set; }
 public byte[]? Data { get; set; }
 }
}

Modificando la interfaz de usuario

Ahora que hemos creado nuestro modelo, ¡sigamos adelante y hagamos algo de magia en la interfaz de usuario con él!

En primer lugar, cree una página en la carpeta Pages llamada Upload.razor.

En esta página vamos a agregar un pequeño formulario que completará nuestra clase BlobRequest, por lo que tenemos que agregar entradas para ConnectionString, Container y Files.

@page "/upload"
@using UploadingFilesAzBlobBlazor.Models
@inject IJSRuntime JsRuntime
<PageTitle> Upload</PageTitle>

<h1> Azure blob storage uploader!</h1>

<EditForm Model="@modal" OnValidSubmit="@HandleValidSubmit">
<DataAnnotationsValidator />
<ValidationSummary />

<div class="mb-3">
<label for="connectionString" class="form-label"> Connection string</label>
<InputText class="form-control" id="connectionString" @bind-Value="modal.ConnectionString" />
</div>

<div class="mb-3">
<label for="container" class="form-label"> Container name</label>
<InputText class="form-control" id="container" @bind-Value="modal.Container" />
</div>

<div class="mb-3">
<label for="formFileMultiple" class="form-label"> Files</label>
<InputFile OnChange="OnInputFileChange" class="form-control" id="formFileMultiple" multiple />
</div>

<div class="mb-3">
<button type="submit" class="btn btn-primary"> Submit</button>
</div>
</EditForm>

@code {
 private BlobRequest modal = new();
 private EditContext editContext;
 IReadOnlyList <IBrowserFile> selectedFiles;
 private void OnInputFileChange(InputFileChangeEventArgs e)
 {
 selectedFiles = e.GetMultipleFiles();
 this .StateHasChanged();
 }

 private async Task HandleValidSubmit() {
 // This is where we are going to upload stuff ! 
 await JsRuntime.InvokeVoidAsync("alert", "Files uploaded!");
 }
}

Es un poco de código, pero básicamente representará el formulario y manejará la validación.

Si presionas el botón para cargar y todo está bien, mostrará una alerta.

Carga en Azure Blob Storage

Ahora que hemos terminado la mayor parte de la interfaz de usuario, instalemos el paquete que manejará la API de Azure Blob Storage y nos permitirá cargar archivos. Bastante sencillo.

Agregar el paquete NuGet

Administremos los paquetes NuGet del proyecto y agreguemos Azure.Storage.Blob.

Cargar en Azure Blob Stoare

Ahora hagamos la lógica para cargar el archivo, normalmente usaríamos la cadena de conexión y la clave de app.config pero, por el bien de este tutorial, usamos entradas y proporcionamos los datos allí.

Primero, agreguemos el using para la clase Azure Blob Storage.

@using Azure.Storage.Blobs
@using Azure.Storage.Blobs.Models

Luego vamos a trabajar en el método HandleValidSubmit, que se conectará al almacenamiento de blobs, creará el contenedor si no existe y luego cargará los archivos.

private async Task HandleValidSubmit()
{
 try
 {
 // Instantiate container
 var container = new BlobContainerClient(modal.ConnectionString, modal.Container);
 // Create container if not exists
 var createResponse = await container.CreateIfNotExistsAsync();
 // Set access policy
 if (createResponse != null && createResponse.GetRawResponse().Status == 201)
 {
 await container.SetAccessPolicyAsync(Azure.Storage.Blobs.Models.PublicAccessType.Blob);
 }

 // For each file that we have uploaded
 foreach (var file in selectedFiles)
 {
 // New blob
 var blob = container.GetBlobClient(file.Name);
 // Delete any blob with the same name
 await blob.DeleteIfExistsAsync(Azure.Storage.Blobs.Models.DeleteSnapshotsOption.IncludeSnapshots);
 // Create a file stream and use the UploadSync method to upload the Blob.
 using (var fileStream = file.OpenReadStream())
 {
 await blob.UploadAsync(fileStream, new BlobHttpHeaders { ContentType = file.ContentType });
 }
 }

 // Display success message
 await JsRuntime.InvokeVoidAsync("alert", "Files uploaded!");
 }
 catch (Exception e)
 {
 // Display error message
 await JsRuntime.InvokeVoidAsync("alert", "An error ocurred!");
 }
}

Probando el código

Ahora es el momento de probar el código, para hacerlo, simplemente complete el formulario y haga clic en enviar.

Mostraremos una alerta y el archivo debería cargarse en Azure Blob Storage, vaya al Portal de Azure y eche un vistazo.

Como puede ver, el contenedor también fue creado, ahora si entramos al contenedor, vemos el archivo que subimos.

¡Buen trabajo!

Refactorizar

Ahora que todo está trabajado, muevamos el código de la página .razor a una clase .razor.cs para que se vea mejor.

Si está utilizando Visual Studio 2022, hay una bombilla cuando pasa el cursor justo en @code, le mostrará una opción para Extract block to code behind y hará lo que dice.

¡Ahora vas a tener todo separado y listo!

Código

¡Este proyecto completo está en Github y puedes encontrarlo aquí!

Espero que os haya gustado el post! ¡Cya!

Recursos

Anulación de un controlador central de Pimcore

Thu, 10 Dec 2020 00:00:00 +0000

He estado trabajando en un proyecto Pimcore desde hace algún tiempo, nunca toqué PHP y Symfony en mi vida, así que ha sido un gran desafío.

La documentación es excelente, quiero decir, en serio, es excelente, pero parece que no está hecha para principiantes en el lenguaje/framework, así que todo lo que hice tuve que tomar notas de ello.

Después de enterarme de que se puede ampliar Pimcore mediante el uso de paquetes, pasé horas y horas intentando anular controladores, métodos de JavaScript y más cosas.

Entonces, en esta publicación explicaré cómo logré anular un controlador. Cómo anular archivos javascript se explicará más adelante 😎.

Creando el paquete

En primer lugar, necesitamos crear un paquete para ello, es bastante simple como está documentado en la [documentación de Pimcore] (https://pimcore.com/docs/pimcore/current/Development_Documentation/Extending_Pimcore/Bundle_Developers_Guide/index.html), solo necesitamos ejecutar bin/console pimcore:generate:bundle --namespace=EmiDemo/EmiDemoBundle en la carpeta del proyecto.

Generará algunas preguntas, pero no hay nada de qué preocuparse.

Creará una nueva carpeta bajo la carpeta src con el espacio de nombres que declaramos antes, y dentro tendremos todos los archivos necesarios para el paquete.

Además, el sitio de administración de Pimcore detectará el complemento, pero estará deshabilitado, debe habilitarlo para comenzar a usarlo.

Anulando un método desde un controlador

Para anular un método en un controlador, primero obviamente necesitas encontrar la acción que deseas actualizar, esto parece fácil pero te daré la forma que suelo hacer (aprendida de mi compañero de equipo Cesar).

Primero vaya a la página en la que cree que el controlador realiza la acción, en mi caso quiero verificar la que se carga cuando abrimos un activo.

Luego simplemente abre la consola y ve a la pestaña de red, vuelve a realizar los mismos pasos e intenta encontrar la acción.

Con esta información puedes ver que la acción que carga el activo es http://localhost/admin/asset/get-data-by-id?_dc=1607601778450&id=2&type=image. De eso podemos ver que la acción del controlador es get-data-by-id.

Encuentra la acción en el controlador central.

Para mí, la forma más sencilla de hacerlo es simplemente buscar en todos los archivos en Visual Studio Code.

Probablemente encontrará más de uno así que debes echarle un vistazo y decidir cuál es, en nuestro caso estamos trabajando con activos por lo que está claro que queremos usar el AssetController.php.

Modificar el controlador central

Depende del desarrollador, normalmente no lo hago porque es más rápido simplemente anular el controlador y desarrollar desde allí. Pero recomendaría primero actualizar el controlador en el paquete principal para ver si los cambios funcionan.

En nuestro caso simplemente devolveré un mensaje al comienzo del método para comprobar que funciona.

return $this->adminJson(['success' => false, 'message' => "Overriding the getDataByIdAction in the core!!"]);

Luego recarguemos nuestro activo y revisemos la pestaña de red.

Mantengamos lo que tenemos allí, para que luego sepamos que estamos usando el mensaje del paquete en lugar del principal.

Ahora copiemos eso a un archivo temporal para realizar un seguimiento de lo que hicimos.

Mover esos cambios al paquete

Ahora, para mover esos cambios a nuestro paquete, primero necesitamos algunas cosas de nuestro controlador central:

Espacio de nombres
Importaciones
Nombre del controlador

Y obviamente el método getDataByIdAction que es el que queremos anular.

Exponer el controlador

Necesitamos exponer el controlador, para hacer esto necesitas ir al archivo /src/EmiDemo/EmiDemoBundle/Resources/config/pimcore/routing.yml y agregar

options:
 expose: true

También necesitamos cambiar el controlador prefix por el que vamos a anular, en nuestro caso el controlador admin.

Entonces al final te verás así.

emi_demo_emi_demo:
 resource: "@EmiDemoEmiDemoBundle/Controller/"
 type: annotation
 prefix: /admin
 options:
 expose: true

Controlador predeterminado.php

En nuestro archivo, agregaremos las importaciones y extenderemos el controlador con el que anularemos

Luego simplemente copiaremos el método del controlador central y, en nuestro caso, actualizaremos el mensaje que devolvemos.

Si recuerdas, ya tenemos un mensaje en el controlador central: Overriding the getDataByIdAction in the core!! y ahora deberíamos ver Overriding the getDataByIdAction in the bundle!!

Simplemente no devolvamos nada y veamos que ahora podemos ver la página como era antes.

Comente la declaración de devolución y vuelva a cargarla.

Eso es todo

Y con esta pequeña demostración podrá ver lo fácil que es anular un controlador central Pimcore existente. Hay algunos pasos que debes seguir pero no es nada difícil. Sólo asegúrese de exponer el controlador y borrar el caché de vez en cuando mientras realiza cambios; a veces se almacena en caché y usted se queda atascado pensando que no funciona y simplemente está almacenado en caché.

Si se pregunta cómo anular los archivos javascript, lo encontrará en otro tutorial 😁.

Configurar el Apple Magic Keyboard 2 en Windows 10

Wed, 11 Nov 2020 00:00:00 +0000

Ayer mismo compré un Apple Magic Keyboard 2, aunque tengo como 5 teclados mecánicos, porque quería probarlo y era inalámbrico.

Mi sistema operativo principal es Windows 10, me encanta y no quiero cambiarlo, así que con eso en mente sabía que sería necesario hacer algunas cosas para que el teclado funcionara perfectamente. Sé cómo funciona Apple y cómo les gusta mantener sus dispositivos en su ecosistema.

Problemas

Si empareja el teclado, reconocerá algunas cosas:

Las teclas de función no funcionan
Algunas claves están mal mapeadas (esto me pasó en la versión en español)

Documentación

Para que funcionara tuve que leer mucho de la web, pero estos dos enlaces son los que me ayudaron a que funcione:

Instalación del controlador del teclado Apple

Algunos de estos pasos provienen de la documentación mencionada anteriormente:

Instale 7zip en su computadora si no lo tiene.
Instale Python (versión 2.x) en su computadora si no lo tiene.
- IMPORTANTE: La última versión de Python es 3.x. Pero necesita la versión 2.x porque el script brigadier no es compatible con la versión 3.x.
- (opción) El instalador, de forma predeterminada, no agrega python.exe a su RUTA. Si lo desea, debe habilitar esta opción. (ver la captura de pantalla a la derecha)
- Si ya tienes otra versión de Python, probablemente no quieras habilitar esta opción.
Descargue brigadier (un script de Python que le ayuda a descargar la última versión de Boot Camp).
Haga clic derecho en el siguiente enlace y guarde el archivo usando “Guardar enlace como…”. https://raw.githubusercontent.com/timsutton/brigadier/master/brigadier
Abra la ventana del símbolo del sistema (también conocida como cuadro de DOS) y cambie el directorio donde descargó el script brigadier.
Suponiendo que el script brigadier se guardó como “brigadier.txt”, ejecute el siguiente comando:
- Si la versión 2.x de Python está en su RUTA: python brigadier.txt –model=MacBook13,2
- De lo contrario: [Ruta a la versión 2.x de Python]\python.exe brigadier.txt –model=MacBook13,2
Descargará un paquete grande con todos los controladores del bootcamp.
Cree una carpeta llamada BootCamp y copie BootCamp-xxx-yyyyyy\BootCamp\Drivers\Apple\BootCamp.msi y BootCamp-xxx-yyyyyy\BootCamp\Drivers\Apple\AppleKeyboardMagic2 en ella.
Ejecute un powershell de administrador y ejecute BootCamp.msi, instalará algunas cosas pero necesitamos actualizar el controlador usando el contenido de la carpeta AppleKeyboardMagic2
Inicie el Administrador de dispositivos (devmgmt.msc)
Expanda el nodo Human Interface Devices
Busque Bluetooth HID Device
Actualice el controlador utilizando el contenido de la carpeta AppleKeyboardMagic2
Reiniciar la computadora

Deberías ver el teclado Bluetooth ahora detectado como un teclado Apple.

Actualizar el comportamiento de las claves FNSi instaló todo correctamente, notará que las teclas FN están habilitadas de forma predeterminada, lo que significa que debe presionar `fn` + `F5` para presionar el botón `F5`.

Para solucionar este problema, encontré una solución, indicada en la sección de documentación, que funciona cambiando alguna entrada en el regedit.

Abra regedit
Vaya a HKEY_CURRENT_USER\SOFTWARE\Apple Inc.\Apple Keyboard Support
Cree o actualice OSXFnBehavior y configúrelo en 0
Reinicie la computadora

Actualizar mapeo de claves

Si tiene algún problema con las asignaciones, puede usar SharpKeys y actualizarlas.

Es realmente sencillo de usar, pero recuerda cerrar sesión o reiniciar la computadora para habilitar las actualizaciones, ya que actualiza el registro.

Para mi caso, tuve que actualizar las claves Windows, alt, º y <>.

Agregar bibliotecas compiladas a un paquete NuGet

Thu, 01 Oct 2020 00:00:00 +0000

El otro día encontré un error sobre un NullReferenceException en una biblioteca faltante que debería haber estado allí ya que proviene de un paquete nuget que subimos.

Básicamente, compilé una clase de biblioteca que hacía referencia a algunos proyectos. En la fase de compilación, agregaría los archivos dll a la carpeta bin, pero cuando packaging lo utiliza como un paquete nuget y los instala en otra solución, los archivos dll a los que hice referencia y que deberían copiarse en la carpeta bin, no están allí.

Cómo solucionarlo

Resolver este problema es bastante simple, debes actualizar el archivo nuspec y para cada una de las bibliotecas que quieras copiar, agrega el file en la parte files.

<?xml version="1.0" encoding="utf-8"?>
<package >
 <metadata>
 <id>$id$</id>
 <version>$version$</version>
 <title>$title$</title>
 <authors>$author$</authors>
 <owners>$author$</owners>
 <requireLicenseAcceptance>false</requireLicenseAcceptance>
 <license type="expression">MIT</license>
 <projectUrl>$projectUrl$</projectUrl>
 <iconUrl>$projectIconUrl$</iconUrl>
 <description>$description$</description>
 <releaseNotes></releaseNotes>
 <copyright>$copyright$</copyright>
 <tags></tags>
 </metadata>
 <files>
 <file src="bin\Release\MyFile1.dll" target="lib\net47" />
 <file src="bin\Release\MyFile2.dll" target="lib\net47" />
 <file src="bin\Release\MyFile3.dll" target="lib\net47" />
 <file src="bin\Release\MyFile4.dll" target="lib\net47" />
 </files>
</package>

Hacer bash de carga de terminal en el directorio de inicio de WSL

Tue, 22 Sep 2020 00:00:00 +0000

Me encanta WSL para el desarrollo y las pruebas desde el día de su lanzamiento, luego la aplicación Terminal cayó y no podría estar más feliz, se ve bien, funciona perfectamente y tiene un rendimiento excelente.

Sería una estupidez no usarlo con la distro WSL en lugar de usar la consola que te proporciona.

Esta consola es obviamente buena, pero después de haber usado Terminal, no hay vuelta atrás. Es mucho mejor, también c o l o r s.

Ahora, si enciende la terminal y abre una nueva pestaña para cargar su distribución WSL, carga su carpeta de usuario montada.

Esto no es realmente un problema, porque si simplemente haces cd ~ simplemente carga la carpeta de usuario de la distribución.

La cuestión es que no quiero hacerlo una y otra vez, así que actualicemos un archivo para que lo haga solo.

.bashrc

Encienda la terminal o la consola, vaya a la carpeta de su perfil y luego edite el archivo .bashrc usando su editor de texto favorito.

Agregue cd ~ al final del archivo antes de la última instrucción.

Guarde, vuelva a abrir la consola WSL con el terminal y debería estar en la carpeta de perfiles.

Tenga en cuenta que tendrá que hacer esto para todas sus instalaciones de WSL, ya que estamos actualizando el archivo bashrc para una sola.

Generación dinámica de objetos usando ExpandoObject

Fri, 06 Mar 2020 00:00:00 +0000

He estado en la necesidad de convertir archivos de Excel con sus propias columnas definidas a uno nuevo con columnas dinámicas, y estaba un poco confundido sobre cómo hacerlo correctamente sin algunos problemas graves de rendimiento.

Se me ocurrió un tutorial que puedes encontrar aquí que usa .NET ExpandoObject que prácticamente te permite crear un objeto y agregar miembros dinámicos.

Objeto Expando

La definición de Microsoft es:

Representa un objeto cuyos miembros se pueden agregar y eliminar dinámicamente en tiempo de ejecución.

Y tiene algunas observaciones:

La clase ExpandoObject le permite agregar y eliminar miembros de sus instancias en tiempo de ejecución y también establecer y obtener valores de estos miembros. Esta clase admite el enlace dinámico, lo que le permite utilizar una sintaxis estándar como sampleObject.sampleMember en lugar de una sintaxis más compleja como sampleObject.GetAttribute(“sampleMember”).

Comportamiento actual

Tenemos un ExcelExportService que al pasarle un List<T>, en este caso ExcelItem, usará Reflection para crear un archivo xlsx.

Hasta ahora, nuestro código se ve así:

class ExcelItem
 {
 public int Id { get; set; }
 public string Name { get; set; }
 public string Surname { get; set; }
 public string Age { get; set; }
 public string CreatedAt { get; set; }
 public string UpdatedAt { get; set; }
 }

ExcelItem es el objeto con todas las propiedades que se utilizan para generar el archivo de Excel.

public static byte[] GetExcelBytes() {
 List<ExcelItem> excelItems = new List<ExcelItem>();
 ExcelExportService exportService = new ExcelExportService();

 foreach (var items in itemsToExcel)
 {
 excelItems.Add(new ExcelItem()
 {
 Id = item.Id,
 Name = item.Name,
 Surname = item.Surname,
 Age = item.Age,
 CreatedAt = item.CreatedAt
 UpdatedAt = item.UpdatedAt
 });
 }

 return exportService.ExportToExcel(excelItems);
}

Este enfoque funciona perfectamente, el archivo xlsx se genera sin problemas siendo cada columna cada propiedad, usarías este método GetExcelBytes así, por ejemplo, para guardarlo en un archivo:

File.WriteAllBytes("path-to-somewhere/my-file.xlsx", GetExcelBytes());

El problema

Dado que lo que estamos haciendo bien es usar todas las propiedades del objeto ExcelItem, lo único que quiero es no usarlas todas, solo usar quizás 2 o 3 de ellas.

También es un requisito que no quiero cambiar el código, todo lo debe hacer el administrator, quien decidirá qué columnas se deben mostrar y puede que conozca o no las propiedades en el código.

TLDR: todo debe ser dinámico, tenemos un objeto con propiedades y debemos asegurarnos de que el archivo generado tenga N propiedades de ese objeto, pero obviamente no codificadas.

Columnas dinámicas

El cambio sería usar un objeto dynamic, porque nos gustaría establecer qué propiedades del objeto se usarán para generar la lista de columnas.

Digamos que tenemos un objeto con muchas propiedades, como una tonelada de ellas, y realmente no queremos cambiar el objeto ExcelItem cada vez que hacemos un cambio, creamos una tabla ColumnExcelItem, que se usará para generar ese ExcelItem.

Estructura de la base de datos

Guardamos esta definición en nuestra base de datos con algo como esto:

Id PropertyName
---------------------
1 Name
2 Surname
3 Age

Tenga en cuenta que tenemos menos valores que las propiedades existentes del objeto ExcelItem, este tiene propiedades 6 y solo tenemos 3 listado en la base de datos.

También tenga en cuenta que PropertyName debe coincidir con el nombre de propiedad del objeto que usaré para la asignación dinámica.

Construyendo el objeto

Ahora que tenemos la tabla de la base de datos, necesitamos crear el repositorio para obtenerla y poder usarla en el código.No haré un tutorial de esta parte, me saltaré el comienzo de la nueva función GetExcelBytes().

public static byte[] GetExcelBytes(List<string> columns) {
 List<ExcelItem> excelItems = new List<ExcelItem>();
 List<dynamic> objectsToExcel = new List<dynamic>();
 ExcelExportService exportService = new ExcelExportService();

 foreach (var item in itemsToExcel)
 {
 dynamic newObject = new ExpandoObject();
 foreach (var col in columns)
 {
 this.AddProperty(newObject, col, product.GetType().GetProperty(col).GetValue(item, null));
 }

 objectsToExcel.Add(newObject);
 }

 return exportService.ExportToExcel(objectsToExcel);
}

Ahora crearemos un objeto con algunas de las propiedades de ExcelItem, pero completamente dinámico. En lugar de usar las 6 propiedades, solo usamos 3 de ellas, la que solo queremos enviar.

Ahora supongamos que este objeto ExcelItem tiene 200 propiedades, una locura, pero podría suceder.

Lo único que tengo que hacer es insertar esas propiedades que quiero renderizar en el archivo de Excel a esa tabla ColumnExcelItem y listo.

Casos

En este caso solo usamos un caso único, pero digamos que desea tener informes diferentes para algunos usuarios. Digamos que el rol admin debe obtener todas las propiedades, entonces crearías algo como esta estructura en la base de datos.

ReportingTemplates

Id PropertyName
---------------------
1 Admin
2 Users

ReportingTemplateItems

Id TemplateId PropertyName
---------------------
1 1 Id
2 1 Name
3 1 Surname
4 1 Age
5 1 CreatedAt
6 1 UpdatedAt
7 2 Name
8 2 Surname
9 2 Age

Luego, al obtener la plantilla, podría tener diferentes columnas, todas dinámicamente y sin código relacionado.

Si tenemos un usuario con el rol Admins, el archivo contendrá las columnas Id, Name, Surname, Age, CreatedAt, UpdatedAt.

En el caso de que lo generes usando el rol Users, tendrá Name, Age. Surname.

Conclusión

Esta es una forma genial de aprender cómo funciona dynamic en .NET, y es una solución realmente buena cuando necesitas tener diferentes roles o plantillas para diferentes usuarios y no estás realmente interesado en invertir tiempo en codificar cosas.

Entrega continua del paquete NuGet utilizando TravisCI

Tue, 21 Jan 2020 00:00:00 +0000

Recientemente hice un tutorial sobre cómo usar Travis CI como herramienta para probar automáticamente el código que acabas de enviar o intentaste enviar a la rama master. Haciéndolo para ser compilado y probado y finalmente informarle el estado de ese cambio.

Pero podemos seguir haciéndolo mejor, por ejemplo, la biblioteca principal que se creó en el último tutorial, quiero hacerla pública usando el feed NuGet, para que todos puedan facilitar la operación en sus bibliotecas.

¿Pero cómo? ¿Cómo vamos a compilar, probar y luego publicar ese paquete en el feed para que todos lo descarguen en sus proyectos?

Bueno, ¡ese es este tutorial para 😁!

¿Qué hay de nuevo?

Casi no hay cambios con respecto al código, las cosas que necesitamos cambiar son el empaquetado, la publicación y luego cómo podemos automatizarlo.

CLI de .NET Core

Vamos a utilizar .NET Core CLI, lo usamos en el tutorial anterior con comandos como dotnet restore, dotnet build y dotnet test.

¡Ahora vamos a utilizar un nuevo conjunto de comandos!

`dotnet nuget`

Puedes consultar la documentación de este conjunto de herramientas directamente aquí, pero una breve explicación:

dotnet nuget es un conjunto de herramientas esenciales que incluyen instalar, restaurar, eliminar y publicar paquetes.

fuente NuGet

NuGet es el administrador de paquetes para .NET. Las herramientas cliente de NuGet brindan la capacidad de producir y consumir paquetes. La Galería NuGet es el repositorio central de paquetes utilizado por todos los autores y consumidores de paquetes.

NuGet es gratuito, por lo que puede registrarse, obtener su clave API y comenzar a cargar paquetes. Se cargarán, verificarán y luego se enumerarán para todos.

Obtener la clave API

Para cargar su paquete, necesitará obtener su clave API después de registrarse, así que vaya a la página de claves API y cree una nueva.

Ten en cuenta que la clave API tiene una caducidad de 365 días.

Luego copia tu clave y guárdala en algún lugar, como se dice en la página, no podrás volver a verla, y si no la guardaste tendrás que regenerarla.

Generar paquete NuGet

Ahora que tenemos la clave API, nuestro siguiente paso es generar ese paquete NuGet a partir de la solución, así que continúe y abra la solución donde tiene su biblioteca de clases.

Usaré la solución de mi último tutorial, que tiene una clase de biblioteca .NET Core llamada CalculatorCLI.Core.

Ahora vaya a propiedades del proyecto y luego a Paquete, verá mucha información sobre el paquete, como la versión del paquete, los autores, las descripciones y más.

Lo siguiente es llenar esto, realmente no tienes que llenar todo, pero los importantes y obligatorios son Package id, Package version, Authors y Description. Además, si intenta cargar el archivo usted mismo, le solicitará License, y tendremos que agregarlo también.

Luego puede guardar, haga clic derecho en el proyecto y seleccione Pack.

1>------ Build started: Project: CalculatorCLI.Core, Configuration: Debug Any CPU ------
1>CalculatorCLI.Core -> D:\Development\Personal\CalculatorCLI-demo\CalculatorCLI\CalculatorCLI.Core\bin\Debug\netstandard2.1\CalculatorCLI.Core.dll
1>Successfully created package 'D:\Development\Personal\CalculatorCLI-demo\CalculatorCLI\CalculatorCLI.Core\bin\Debug\CalculatorCLI.Core.1.0.0.1.nupkg'.
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========

El resultado mostrará que si todo está bien, imprimirá Successfully created package.

Usando `dotnet`

Como en el tutorial anterior, utilizamos diferentes comandos para construir y probar la solución. Ahora vamos a agregar más comandos para empaquetar y publicar los paquetes.

Esos comandos son:

dotnet pack -c <configuration>
dotnet nuget push <package> <k <apikey> -s <source>

Scripts de implementación

Como vamos a cambiar la forma en que será la compilación, creo que la mejor idea sería tener diferentes archivos, cada uno de los cuales contenga una definición de compilación dependiendo del entorno.

Entonces, creemos una carpeta llamada scripts con tres scripts bash en la raíz del repositorio.

scripts\compile.sh

#!/bin/sh

echo "Restoring..."
dotnet restore ".\CalculatorCLI\CalculatorCLI.sln"

echo "Building..."
dotnet build ".\CalculatorCLI\CalculatorCLI.sln" -c Release

scripts\test.sh

#!/bin/sh

echo "Testing..."
dotnet test ".\CalculatorCLI\CalculatorCLI.sln" -c Release -v n

scripts\push.sh

#!/bin/sh

echo "Packing..."
dotnet pack ./CalculatorCLI/CalculatorCLI.Core/CalculatorCLI.Core.csproj -c Release

echo "Pushing..."
dotnet nuget push ./CalculatorCLI/CalculatorCLI.Core/bin/Release/*.nupkg -s "https://nuget.org" -k $NUGET_API_KEY

Mejorando el archivo `.travis.yml`

Ahora que tenemos el código fuente actualizado, sabemos los comandos que necesitamos usar, necesitamos integrar nuestra entrega continua con la integración continua. Con eso realmente no tenemos que hacer nada más que codificar, probar, revisar y enviar.

Lo que vamos a hacer ahora, al archivo .travis.yml, es lo siguiente:

Agrega diferentes stages
Cada stage depende de la rama
Si su compilación está en master, significa que el paquete debe actualizarse, por lo tanto, enviaremos nuestro paquete a los feeds de NuGet.
Si su compilación es una solicitud de extracción, aún verificaremos si la compilación se compila y probará, pero no la publicaremos.

Etapas

De su documentación:

Puede filtrar y rechazar compilaciones, etapas y trabajos especificando condiciones en su configuración de compilación (su archivo .travis.yml).

Puede encontrar más información sobre TravisCI stages en su página de documentación.

Entonces vamos a cambiar el archivo y agregar las etapas, que terminan así:

language:
 csharp
sudo: required
mono: none 
dotnet: 3.0

os:
 - linux

jobs:
 include:
 - stage: compile
 script: bash scripts/compile.sh

 - stage: test
 script: bash scripts/test.sh

 - stage: deploy-prod
 if: branch = master AND type = push
 name: "Deploy to NuGet"
 script: bash scripts/push.sh

Como pueden ver tenemos tres etapas diferentes compile, test y push, la cual la última solo se va a ejecutar cuando el branch sea master y no sea un pull request, solo un push.

Si no entiende esto, simplemente vaya a la documentación y se explica bastante fácilmente.

Teniendo esto en cuenta, todos los pull request no enviarán nada al feed de NuGet.

Configurar la clave API como variable de entorno

Vaya a la configuración de compilación de su repositorio y agregue una nueva variable de entorno, llamada NUGET_API_KEY cuyo valor es la clave de API copiada de la página NuGet.

Crea un `pull request`

Ahora que tenemos todo configurado, es hora de hacer un pull request y verificar si la compilación para esa solicitud de extracción ignora el último stage.

Verifica las compilaciones

Justo cuando realiza la solicitud de extracción, se pondrá en cola una compilación en el panel de TravisCI y, como puede ver, tenemos 2 compilaciones diferentes allí y no tres.

Ahora aceptemos el pull request y verifiquemos la compilación nuevamente para ver que ahora tenemos tres trabajos en lugar de dos.

Y tan pronto como pueda ver la compilación en cola, podrá ver los tres trabajos, incluido el Deploy-prod al final.

Tan pronto como se complete toda esta compilación, podrá ver en los registros que el paquete se envió a las fuentes.

Y obviamente puedes verlo en la página de NuGet.

Eso es todo

En este tutorial descubrimos cómo automatizar la entrega de nuestros paquetes NuGet. Usamos algunas herramientas como TravisCI, stages y dotnet nuget.

En mi opinión, incluso si es algo que llevaría tiempo configurar correctamente y podría ser demasiado complejo en algunos casos. Invertir tiempo en este tipo de técnicas para dejarlo todo perfecto y automatizado merece la pena.

Puedes encontrar el código fuente, con el archivo .travis.yml justo aquí, si tienes alguna pregunta, no dudes en contactarme en mi twitter.

Integración continua para un proyecto .NET Core 3.0 usando TravisCI

Tue, 14 Jan 2020 00:00:00 +0000

El fin de semana pasado decidí que quería comenzar correctamente mi proyecto scraper-checker-downloader que he estado haciendo en diferentes repositorios.

Después de comenzar otro proyecto más, esto tenía que ser genial, realmente genial, usando CI/CD, solicitud de extracción, documentación, insignias en el archivo Léame, todo lo que he visto es genial y, de hecho, son las mejores prácticas.

Y después de un buen fin de semana terminé creando Dramarr, un conjunto de herramientas que eliminan y descargan programas de diferentes fuentes.

Tiene diferentes repositorios en la organización y la mayoría de ellos son bibliotecas que se compilan, prueban e implementan en la solicitud de extracción y cuando se fusionan en la rama maestra.

Eso es lo que se llama CI/CD o integración continua/entrega continua.

Pero en este tutorial solo hablaremos de CI.

Integración continua

¿Qué es?

Tomado del [blog] de Martin Fowler (https://martinfowler.com/articles/continuousIntegration.html), que es la mejor explicación que he leído:

La Integración Continua es una práctica de desarrollo de software en la que los miembros de un equipo integran su trabajo con frecuencia; por lo general, cada persona se integra al menos diariamente, lo que genera múltiples integraciones por día. Cada integración se verifica mediante una compilación automatizada (incluida la prueba) para detectar errores de integración lo más rápido posible.

Herramientas

Hay muchas herramientas para integrar su flujo de trabajo con CI/CD, pero para este tutorial usaremos Github para almacenar nuestro código y las herramientas TravisCI para configurar el CI. En cuanto al lenguaje y frameworks, usaremos C# y el nuevo .NET Core 3.0.

Requisitos

Para que esto funcione necesitas tres cosas simples:

Última versión de Visual Studio 2019
Cuenta Github
Cuenta Travis-CI vinculada a su cuenta Github

Proyecto

Por el bien de este tutorial, haremos una Calculadora simple. Crearemos una biblioteca, una herramienta de línea de comandos y un proyecto de prueba para probar todo.

Este proyecto de prueba también se ejecutará cuando configuremos el CI, lo que significa que si en el futuro realizamos un cambio en el código y las pruebas que creamos inicialmente no pasan, recibiremos una notificación o simplemente podríamos rechazar la solicitud de extracción.

Creando el repositorio de Github

Primero, crearemos un repositorio de Github, así que acceda a Github, cree el repositorio y clónelo en su entorno local. Decidí llamar a este nuevo repositorio CalculatorCLI-demo.

Creando la solución

Ahora creemos una solución vacía llamada CalculatorCLI, en la carpeta raíz del repositorio clonado.

Biblioteca principal

Como sería en un proyecto del mundo real, almacenaremos nuestra lógica en un proyecto separado que genera una biblioteca, así que vamos a crearla.

Ve y crea un Class Library (.NET Standard) y llámalo CalculatorCLI.Core

Versión NET CoreTan pronto como cree el proyecto, vaya a las propiedades del proyecto y cambie `Target framework` a `.NET Standard 2.1`, para que sea compatible con los proyectos creados en `.NET Core 3.0`.

Código

Por el bien del tutorial, creemos una clase simple que maneje operaciones.

using System;

namespace ConsoleCalculator.Core
{
 public enum OperatorsEnum
 {
 ADD,
 SUBSTRACT,
 MULTIPLY,
 DIVIDE
 }

 public class Operation
 {
 public OperatorsEnum OperatorEnum { get; set; }
 public int LeftValue { get; set; }
 public int RightValue { get; set; }

 public Operation(string operatorString, int leftValue, int rightValue)
 {
 switch (operatorString)
 {
 case "+":
 OperatorEnum = OperatorsEnum.ADD;
 break;
 case "-":
 OperatorEnum = OperatorsEnum.SUBSTRACT;
 break;
 case "*":
 OperatorEnum = OperatorsEnum.MULTIPLY;
 break;
 case "/":
 OperatorEnum = OperatorsEnum.DIVIDE;
 break;
 default:
 throw new Exception("Operator invalid");
 }

 LeftValue = leftValue;
 RightValue = rightValue;
 }

 public int DoOperation()
 {
 switch (OperatorEnum)
 {
 case OperatorsEnum.ADD:
 return LeftValue + RightValue;
 case OperatorsEnum.SUBSTRACT:
 return LeftValue - RightValue;
 case OperatorsEnum.MULTIPLY:
 return LeftValue * RightValue;
 case OperatorsEnum.DIVIDE:
 return LeftValue / RightValue;
 default:
 throw new Exception("Operator is not valid");
 }
 }
 }
}

##CLI

Ahora que tenemos el proyecto principal, creemos la aplicación. En este caso será una aplicación de consola simple que acepta argumentos y muestra un resultado.

Así que sigamos adelante y creemos un nuevo Console App (.NET Core), lo llamé CalculatorCLI.CLI.

Versión NET Core

Como hicimos antes, tan pronto como crees el proyecto, ve a las propiedades del proyecto y cambia Target framework a .NET Core 3.0, si aún no está así.

Luego agregue la referencia a ConsoleCLI.Core a nuestro proyecto recién creado.

Código

Ahora el código, esto es más simple que antes.

using ConsoleCalculator.Core;
using System;
using System.Text.RegularExpressions;

namespace ConsoleCalculator.CLI
{
 public class Program
 {
 public static void Main(string[] args)
 {
 if (args.Length == 0)
 {
 PrintUsage();
 }
 else
 {
 var joinedArgs = string.Join(" ", args);
 var regex = @"-op [\+\-\*\/] -l [-0-9]+ -r [-0-9]+";

 if (Regex.IsMatch(joinedArgs, regex))
 {
 int _left = Int32.Parse(args[3]);
 int _right = Int32.Parse(args[5]);
 string _operator = args[1];

 var _operation = new Operation(_operator, _left, _right);
 var _result = _operation.DoOperation();

 Console.WriteLine($"Result is: {_result}");
 }
 else
 {
 PrintUsage();
 }
 }
 }

 public static void PrintUsage()
 {
 Console.WriteLine($"Welcome to ConsoleCalculator!");
 Console.WriteLine($"");
 Console.WriteLine($"-op Operator, it must be +,-,*,/");
 Console.WriteLine($"-l Left number");
 Console.WriteLine($"-r Left number");
 Console.WriteLine($"");
 Console.WriteLine($"Example usage: -op + -l 5 -r 6");
 }
 }
}

Usaremos esta aplicación desde un comando como, por lo que para que funcione, debemos llamarla pasando algunos parámetros. Por ejemplo:

ConsoleCalculator.CLI.exe -op + -l 10 -r 20

Lo que se traduce en:

ConsoleCalculator.CLI.exe -operator + -leftValue 10 -rightValue 20

El código para esto es bastante simple, si no coincide con un determinado patrón de expresiones regulares, es una llamada incorrecta y llama a PrintUsage(). Esto significa que si ingresamos algo diferente a un número, porque está configurado en la expresión regular, ni siquiera intentará realizar el cálculo.

Eso significa, si lo llamamos así:

ConsoleCalculator.CLI.exe -operator + -leftValue asdfg -rightValue ghjk

Nunca entrará dentro de la lógica de operaciones y estamos guardando comprobaciones futuras como TryParseing los valores.

Prueba

Tenemos la biblioteca principal y la línea de comando, pero ahora necesitamos realizar pruebas, porque eso es lo que queremos hacer en el CI.

Así que sigamos adelante y creemos un nuevo MSTest Test Project (.NET Core) y asígnale el nombre CalculatorCLI.Tests.

Versión NET Core

Como hicimos antes, tan pronto como crees el proyecto, ve a las propiedades del proyecto y cambia Target framework a .NET Core 3.0, si aún no está así.

Luego agregue la referencia a ConsoleCLI.Core y ConsoleCLI.Core a nuestro proyecto de prueba recién creado.

Código

Vamos a dividir la prueba en dos archivos diferentes: CoreTests.cs y CLITests.cs

using CalculatorCLI.Core;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using System;
using System.Collections.Generic;
using System.Text;

namespace CalculatorCLI.Tests
{
 [TestClass]
 public class CoreTests
 {
 public int _left = 2;
 public int _right = 2;

 [TestMethod]
 public void ShouldAdd()
 {
 var expectedResult = 4;
 var operation = new Operation("+", _left, _right);
 var functionResult = operation.DoOperation();

 Assert.AreEqual(functionResult, expectedResult);
 }

 [TestMethod]
 public void ShouldSubstract()
 {
 var expectedResult = 0;
 var operation = new Operation("-", _left, _right);
 var functionResult = operation.DoOperation();

 Assert.AreEqual(functionResult, expectedResult);
 }

 [TestMethod]
 public void ShouldMultiply()
 {
 var expectedResult = 4;
 var operation = new Operation("*", _left, _right);
 var functionResult = operation.DoOperation();

 Assert.AreEqual(functionResult, expectedResult);
 }

 [TestMethod]
 public void ShouldDivide()
 {
 var expectedResult = 1;
 var operation = new Operation("/", _left, _right);
 var functionResult = operation.DoOperation();

 Assert.AreEqual(functionResult, expectedResult);
 }

 [TestMethod]
 [ExpectedException(typeof(System.DivideByZeroException))]
 public void ShouldThrowExceptionForDivideByZero()
 {
 var operation = new Operation("/", _left, 0);
 operation.DoOperation();
 }

 [TestMethod]
 [ExpectedException(typeof(System.Exception), "Operator invalid")]
 public void ShouldThrowExceptionForWrongOperator()
 {
 var operation = new Operation("text", _left, 0);
 operation.DoOperation();
 }
 }
}

using Microsoft.VisualStudio.TestTools.UnitTesting;
using System;
using System.Collections.Generic;
using System.Text;

namespace CalculatorCLI.Tests
{
 [TestClass]
 public class CLITests
 {
 public string _left = "2";
 public string _right = "2";

 [TestMethod]
 public void ShouldAdd()
 {
 var args = new string[] { "-op", "+", "-l", "45", "-r", "96" };
 CalculatorCLI.CLI.Program.Main(args);
 }

 [TestMethod]
 public void ShouldSubstract()
 {
 var args = new string[] { "-op", "-", "-l", "45", "-r", "96" };
 CalculatorCLI.CLI.Program.Main(args);
 }

 [TestMethod]
 public void ShouldMultiply()
 {
 var args = new string[] { "-op", "*", "-l", "45", "-r", "96" };
 CalculatorCLI.CLI.Program.Main(args);
 }

 [TestMethod]
 public void ShouldDivide()
 {
 var args = new string[] { "-op", "/", "-l", "45", "-r", "96" };
 CalculatorCLI.CLI.Program.Main(args);
 }
 }
}

Con todo creado terminaremos con una solución como esta:

Y con esto ahora podemos ejecutar las Pruebas, así que vaya a Test Explorer en Visual Studio y ejecútelas.

#TravisCI

Si aún no lo ha hecho, TravisCI es un sistema alojado de integración e implementación continua.

Hay algunos pasos que debemos seguir aquí, pero primero vamos a vincular nuestro repositorio de Github para que los agentes de TravisCI lo escuchen y puedan construir y probar nuestro proyecto.

Habilitar repositorio

Para hacer esto, inicie sesión en la página de Travis CI y vaya a sus repositorios, luego filtre el proyecto que creó y habilítelo haciendo clic en el control deslizante al lado del nombre del repositorio.

Crear .travis.ymlNecesitamos crear un archivo llamado `.travis.yml` en la raíz de su proyecto, esto se debe a que como se indica en la documentación:

Travis solo ejecuta compilaciones de las confirmaciones que envía después de haber agregado un archivo .travis.yml.

Así que ve y crea un archivo .travis.yml en la raíz del repositorio con las siguientes líneas:

language:
 csharp
sudo: required
mono: none 
dotnet: 3.0

os:
 - linux

before_script:
 - dotnet restore ".\CalculatorCLI\CalculatorCLI.sln"

script:
 - dotnet build ".\CalculatorCLI\CalculatorCLI.sln" -c Release
 - dotnet test ".\CalculatorCLI\CalculatorCLI.sln" -c Release -v n

No entraré en la sintaxis de cómo funciona el archivo .travis.yml, pero repasemos lo que hace:

Configuramos que el idioma será csharp.
No usaremos mono porque .NET Core 3.0 se ejecutará de forma nativa en Linux.
Configuramos la versión dotnet en 3.0.
Configuramos el os, por defecto es linux pero lo agregué de todos modos.
Ahora tenemos before_script que se ejecutará antes de la lógica principal aquí, así que lo que puse fue ejecutar dotnet restore en la solución para que todo se cargue perfectamente después.
Ahora en el script, haremos un dotnet builld y un dotnet test a nuestra solución, esto comprobará que se compila y luego ejecutará las pruebas.

¡Y hemos terminado!

Subir al master

Ahora sólo tenemos que impulsar todo para dominarlo.

git add --all
git commit -m "Initial files"
git push

Verifique la integración continua

Podemos verificar el estado de CI del envío a master que hicimos tanto en la página del repositorio como en el panel de TravisCI.

En progreso

Terminado

Vamos a romperlo

Ahora, para ver qué tan poderoso es esto, rompamos el código y cambiemos la biblioteca principal para que falle.

Cambios de código

Así que vaya a Operation.cs y cambie algo que rompa algunas pruebas.

using System;

namespace CalculatorCLI.Core
{
 public enum OperatorsEnum
 {
 ADD,
 SUBSTRACT,
 MULTIPLY,
 DIVIDE
 }

 public class Operation
 {
 public OperatorsEnum OperatorEnum { get; set; }
 public int LeftValue { get; set; }
 public int RightValue { get; set; }

 public Operation(string operatorString, int leftValue, int rightValue)
 {
 switch (operatorString)
 {
 case "+":
 OperatorEnum = OperatorsEnum.SUBSTRACT;
 break;
 case "-":
 OperatorEnum = OperatorsEnum.SUBSTRACT;
 break;
 case "*":
 OperatorEnum = OperatorsEnum.MULTIPLY;
 break;
 case "/":
 OperatorEnum = OperatorsEnum.DIVIDE;
 break;
 default:
 throw new Exception("Operator invalid");
 }

 LeftValue = leftValue;
 RightValue = rightValue;
 }

 public int DoOperation()
 {
 switch (OperatorEnum)
 {
 case OperatorsEnum.ADD:
 return LeftValue + RightValue;
 case OperatorsEnum.SUBSTRACT:
 return LeftValue - RightValue;
 case OperatorsEnum.MULTIPLY:
 return LeftValue * RightValue;
 case OperatorsEnum.DIVIDE:
 return LeftValue / RightValue;
 default:
 throw new Exception("Operator is not valid");
 }
 }
 }
}

Y si ejecutamos la prueba nuevamente, porque cambiamos el caso a suma, fallará:

case "+":
 OperatorEnum = OperatorsEnum.SUBSTRACT;
 break;

Como era de esperar, falló en el caso ShouldAdd:

Ahora confirme este cambio, empújelo a master y espere los resultados del agente TravisCI.

git add --all
git commit -m "Breaking changes"
git push

Construir

Ahora vayamos a los registros de TravisCI y veremos que rompimos el proyecto con éxito, porque la prueba de integración está fallando y el estado de compilación es error.

Al final del registro podemos ver el error en sí:

¡Arreglemoslo de nuevo!

Ahora revierta lo que hicimos, envíe el código a Master y verifique el estado de la nueva compilación.

Las pruebas se pasan con éxito:

Y construir también es un éxito:

Conclusión

Es realmente bastante poderoso, CI y CD existen desde hace mucho tiempo, pero ahora es bastante sencillo ejecutarlo en cada proyecto, no importa cuán pequeño o simple sea.Desde mi punto de vista, todos deberían al menos configurar CI para cada uno de sus proyectos, porque es una buena práctica y eventualmente le ahorrará tiempo depurando y encontrando errores que no deberían ocurrir si hubiera configurado tests y CI adecuados.

Eso es todo

Se trata de cómo crear una solución .NET Core 3.0 que tenga integración continua en cada compilación usando TravisCI y almacenando el código en Github.

Puede encontrar el código fuente de este proyecto aquí.

Mi opinión sobre el caché en memoria

Tue, 03 Sep 2019 00:00:00 +0000

He estado trabajando en algunas cosas que manejaban una gran cantidad de datos. Mientras lo hacía, me di cuenta de que una gran parte nunca cambia, o al menos durante un tiempo determinado, no cambia.

Entonces pensé que sería útil crear un repositorio de caché personal, por supuesto, esto no es nuevo, hace unas semanas leí sobre esto en la publicación de StackOverflow escrita por Nick Craver sobre cómo administran el caché de la aplicación.

Además, siempre quise trabajar con caché, cómo funciona, la lógica y cómo podría hacer que funcione, así que… ¡por qué no!

Flujo

Aquí hay un flujo rápido de cómo se comportará la clase que tiene el control del caché cuando el usuario solicite un valor.

Implementación

Antes de comenzar

Lo sé, lo sé. Hay System.Runtime.Caching que maneja la memoria caché. Pero decidí construirlo yo mismo. Si quieres usar esa clase, consulta aquí para obtener instrucciones.

Elemento de caché

El primer paso es tener una clase que almacene el valor de un objeto y la fecha de vencimiento. Probablemente haya una mejor manera de hacerlo, pero esto es lo que pensé, así que ahí lo tienes:

public class CacheItem
{
 public string Identifier { get; set; }
 public object Value { get; set; }
 public DateTime ValidUntil { get; set; }

 public CacheItem(string identifier, object value, TimeSpan valid)
 {
 Identifier = identifier;
 Value = value;
 ValidUntil = DateTime.UtcNow.Add(valid);
 }
}

Repositorio de caché

Luego necesitamos una clase que maneje los objetos y los guarde en algún lugar (como CacheItem). Me gusta manejar todos los datos/modelos en clases que tienen el sufijo Repository, pero no es necesario, así que creemos uno para el almacenamiento en caché.

public class CacheRepository
{
 private static Dictionary<string, string> Cache = new Dictionary<string, string>();
 private static T Set<T>(string key, Func<T> lookup, TimeSpan durationMinutes)
 {
 var item = new Models.Item(key, lookup(), durationMinutes);
 return Save<T>(key, item);
 }
 private static T Save<T>(string key, Item item)
 {
 Cache[key] = JsonConvert.SerializeObject(item);
 return (T)item.Value;
 }
 private static T Get<T>(string key)
 {
 var cached = Cache.FirstOrDefault(x => x.Key == key).Value;
 var item = string.IsNullOrEmpty(cached) ? null : JsonConvert.DeserializeObject<Item>(cached);
 return (item == null)
 ? default : (item.ValidUntil > DateTime.UtcNow)
 ? JsonConvert.DeserializeObject<T>(JsonConvert.SerializeObject(item.Value)) : default;
 }
 public static T GetOrSet<T>(string key, Func<T> lookup, TimeSpan durationMinutes)
 {
 var cache = Get<T>(key);
 return cache == null ? Set(key, lookup, durationMinutes) : cache;
 }
}

Hasta ahora tenemos un diccionario estático llamado Cache donde se almacenarán todos los elementos. Recuerde que esto solo durará mientras la aplicación se esté ejecutando, por eso este título de tutorial tiene almacenamiento en memoria caché.

Tenga en cuenta que el elemento Cache se inicializará una vez que se cargue la clase CacheRepository.

El único método disponible al invocar la clase CacheRepository es GetOrSet(string key, Func<T> lookup, TimeSpan durationMinutes) que necesita tres parámetros:

key: el identificador del objeto a guardar.
lookup: la función de devolución de llamada en caso de que el caché caduque o sea nulo.
durationMinutes: la duración en minutos que se agregará a la hora actual (en UTC).

Hora de almacenar en caché

Ahora, use nuestro repositorio de almacenamiento en caché para obtener algunos datos de algún lugar.

Para que todo esto tenga sentido, creemos un objeto de ejemplo con algunas propiedades y luego un repositorio para buscar y completar una lista de ese objeto.

public class User
{
 public Guid Id { get; set; }
 public string Name { get; set; }
 public string Email { get; set; }
}
public class UserRepository
{
 public List<User> Get()
 {
 // Code to get users
 }
}

Ya que tenemos el método para llenar una lista de User, usemos la clase CacheRepository.

private UserRepository _userRepository = new UserRepository();
private List<User> _user;
public List<User> User
{
 get
 {
 _user = CacheRepository.GetOrSet($"users", usersRepo.Get, TimeSpan.FromMinutes(10));
 return _user;
 }
}

Y así, cada vez que accedas a la variable User, te pedirá a CacheRepository el valor de un objeto que tiene la clave users.

Si esa clave existe, verificará la fecha de vencimiento. Si cualquiera de estas condiciones es falsa, utilizará la devolución de llamada para establecer el valor (con usersRepo.Get) del objeto, lo guardará en la caché con la fecha de vencimiento establecida en DateTime.UtcNow + TimeSpan.FromMinutes(10) y lo devolverá.

Tome capturas de pantalla de la página usando Devtools

Thu, 09 May 2019 00:00:00 +0000

Ha habido ocasiones en las que necesitaba mostrarle a un cliente o a un compañero de equipo una captura de pantalla completa del estado actual del sitio web o incluso una parte de él, así que he estado usando Captura de pantalla de página completa y, para cualquier otro tipo de capturas de pantalla, la Herramienta de fragmentos de Windows o Snaggit. Si quiero alojarlo en línea como en esta publicación Gyazo, que también tiene un creador de GIF.

Recientemente descubrí que Devtools tiene una herramienta que realiza una captura de pantalla de página completa, ¡no se necesita extensión!

Este no es un pensamiento nuevo, se incluyó en la actualización de Devtools en abril de 2017, pero parece que vivo bajo una roca y no lo descubrí hasta ahora…

Herramientas de desarrollo

Como se indica en la página oficial de Devtools:

Chrome DevTools es un conjunto de herramientas para desarrolladores web integradas directamente en el navegador Google Chrome. DevTools puede ayudarle a editar páginas sobre la marcha y diagnosticar problemas rápidamente, lo que en última instancia le ayuda a crear mejores sitios web y más rápido.

Ejecutando comandos en Devtools

Ya sabes cómo abrir Devtools pero en caso de que lo hayas olvidado y por el bien de esta publicación, ábrelo usando la tecla F12 o el atajo Ctrl + Shift + I. Luego tienes que abrir Run command en el menú dentro de Devtools o usar Ctrl + Shift + P.

Herramienta de captura de pantalla

Si escribes screenshot filtrará los comandos, habrá 4 tipos de métodos de captura de pantalla que puedes usar:

Captura de pantalla del área
Captura de pantalla en tamaño completo
Captura de pantalla del nodo
Captura de pantalla

Antes de verificar todos los métodos de captura de pantalla, después de que devtools termine de procesar la imagen, la descargará automáticamente con el nombre de la página web.

Captura de pantalla del área

El area screenshot te permitirá seleccionar una parte del sitio web y hacer una captura de pantalla.

Resultado:

Captura de pantalla en tamaño completo

El full size screenshot tomará una captura de pantalla de toda la página web, desde el principio hasta el final.

Resultado:

Captura de pantalla del nodo

El node screenshot le permitirá hacer una captura de pantalla de un nodo seleccionado en el elemento de inspección.

Resultado:

Captura de pantalla

El capture screenshot tomará una captura de pantalla de la página actual sin necesidad de desplazarse y del tamaño del navegador.

Resultado:

Lenguajes personalizados que utilizan recursos integrados y externos en .NET Framework

Mon, 06 May 2019 00:00:00 +0000

Introducción

En el trabajo se nos ocurrió un problema normal con el que estoy bastante seguro que muchos desarrolladores tienen que lidiar, que son los idiomas y los idiomas personalizados de los clientes que brindan nuestro servicio a sus clientes.

Por ejemplo, digamos que el lenguaje base utiliza un lenguaje informal y un cliente quiere un lenguaje formal porque sus clientes son personas mayores.

También tenga en cuenta que esta solución es para varios idiomas, usaremos inglés y español.

Mi lengua materna no es el inglés, así que pido disculpas por cualquier error en el tutorial. Si encuentra errores y desea corregirlos, puede abrir una solicitud de extracción en este repositorio y con gusto la aprobaré.

Recursos

Los recursos son archivos XML con extensión .resx que tienen una estructura clave/valor y se parecen a lo siguiente:

<?xml version="1.0" encoding="utf-8"?>
<root>
 <xsd:schema id="root" xmlns="" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:msdata="urn:schemas-microsoft-com:xml-msdata">
 <xsd:import namespace="http://www.w3.org/XML/1998/namespace" />
 <xsd:element name="root" msdata:IsDataSet="true">
 <xsd:complexType>
 <xsd:choice maxOccurs="unbounded">
 <xsd:element name="metadata">
 <xsd:complexType>
 <xsd:sequence>
 <xsd:element name="value" type="xsd:string" minOccurs="0" />
 </xsd:sequence>
 <xsd:attribute name="name" use="required" type="xsd:string" />
 <xsd:attribute name="type" type="xsd:string" />
 <xsd:attribute name="mimetype" type="xsd:string" />
 <xsd:attribute ref="xml:space" />
 </xsd:complexType>
 </xsd:element>
 <xsd:element name="assembly">
 <xsd:complexType>
 <xsd:attribute name="alias" type="xsd:string" />
 <xsd:attribute name="name" type="xsd:string" />
 </xsd:complexType>
 </xsd:element>
 <xsd:element name="data">
 <xsd:complexType>
 <xsd:sequence>
 <xsd:element name="value" type="xsd:string" minOccurs="0" msdata:Ordinal="1" />
 <xsd:element name="comment" type="xsd:string" minOccurs="0" msdata:Ordinal="2" />
 </xsd:sequence>
 <xsd:attribute name="name" type="xsd:string" use="required" msdata:Ordinal="1" />
 <xsd:attribute name="type" type="xsd:string" msdata:Ordinal="3" />
 <xsd:attribute name="mimetype" type="xsd:string" msdata:Ordinal="4" />
 <xsd:attribute ref="xml:space" />
 </xsd:complexType>
 </xsd:element>
 <xsd:element name="resheader">
 <xsd:complexType>
 <xsd:sequence>
 <xsd:element name="value" type="xsd:string" minOccurs="0" msdata:Ordinal="1" />
 </xsd:sequence>
 <xsd:attribute name="name" type="xsd:string" use="required" />
 </xsd:complexType>
 </xsd:element>
 </xsd:choice>
 </xsd:complexType>
 </xsd:element>
 </xsd:schema>
 <resheader name="resmimetype">
 <value>text/microsoft-resx</value>
 </resheader>
 <resheader name="version">
 <value>2.0</value>
 </resheader>
 <resheader name="reader">
 <value>System.Resources.ResXResourceReader, System.Windows.Forms, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089</value>
 </resheader>
 <resheader name="writer">
 <value>System.Resources.ResXResourceWriter, System.Windows.Forms, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089</value>
 </resheader>
 <data name="Action_cancel" xml:space="preserve">
 <value>Finish</value>
 </data>
 <data name="Action_greeting" xml:space="preserve">
 <value>Hello</value>
 </data>
</root>

Estaremos creando recursos para dos idiomas diferentes: inglés y español, por lo que la nomenclatura de los archivos será: resources.ISOLANGUAGECODE.resx, por ejemplo: resource.es.resx para español y resource.resx para inglés, en caso de que luego queramos agregar alemán, el archivo se llamará resource.de.resx.

Recurso integrado

Los recursos integrados, cuando se compila el proyecto, se agregarán dentro del dll.

Aquí hay una imagen con un recurso incrustado, como puede ver, el archivo Resource.resx no se puede ver en la compilación.

Recurso externo

Por otro lado, los recursos externos o no integrados son recursos que se agregarán a la carpeta después de la compilación.

Los archivos de recursos (.resx) estarán dentro de la carpeta Properties

Construyendo el proyecto

Comencemos con un proyecto de consola en .NET Framework.

Creando el archivo de recursos incrustado

Agregue un archivo de recursos con algunas claves y asegúrese de que sea un recurso integrado, que luego usaremos para actualizar con recursos externos.

Creando el archivo de recursos externos

Para separar los recursos externos de los integrados, agregaremos los recursos externos dentro de una carpeta con un nombre para que podamos acceder a ellos fácilmente más adelante.

Consejo: para agregar una carpeta dentro de la carpeta Propiedades, créala afuera y muévela adentro, Visual Studio no te permite crearla

Haga lo mismo que hicimos para el recurso incrustado, luego vaya al properties del archivo y dentro de Advanced, Build action y cámbielo a: Content y cambie Copy to Output Dictionary a Copy if newer.

Así es como debería verse:

Agregar una clave a app.config

Debido a que somos desarrolladores geniales y nos gusta tener todo bien hecho y NO cambiar el código para cada cliente, agreguemos una clave al appconfig que tendrá el nombre de la carpeta en la que buscaremos los archivos de recursos.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
 <startup>
 <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.7.2" />
 </startup>
 <appSettings>
 <add key="CustomResources.Folder" value="John" />
 </appSettings>
</configuration>
```Más adelante, cuando busquemos los recursos, buscará en `Properties.John` en lugar de `Properties.Doe`.

Además, esto hace que sea más fácil cambiar cuando la aplicación ya está implementada, ya que puede cambiar app.config fácilmente.

## Acceder a archivos de recursos incrustados

Usar .NET Framework es bastante fácil, por lo que para acceder a las propiedades Embedded solo tenemos que usar el objeto `Properties`, que tendrá los archivos de recursos como propiedad, y dentro de ese objeto estará toda la clave/valor que tenemos en el archivo `resx`.

```csharp
static void Main(string[] args)
{
 var hello = Properties.Resource.Action_greeting;
 var bye = Properties.Resource.Action_cancel;

 Console.WriteLine($"Action_greeting value: {hello}, Action_cancel value: {bye}");

 Console.Read();
}

Al ejecutarlo debería mostrarnos algo como esto:

Action_greeting value: Hello, Action_cancel value: Cancel

Acceder a archivos de recursos externos

Esta parte es más o menos lo mismo, puedes acceder a los archivos de recursos mediante el objeto Properties.

var hello = Properties.Resource.Action_greeting;
var bye = Properties.Resource.Action_cancel;

var johnhello = Properties.John.Resource.Action_greeting;
var johnbye = Properties.John.Resource.Action_cancel;

var doehello = Properties.Doe.Resource.Action_greeting;
var doebye = Properties.Doe.Resource.Action_cancel;

Problema

El principal problema al utilizar este método es que cada clave es una propiedad dentro del objeto, por lo que tenemos que llamarla como vimos antes. Si queremos llamar a la clave Action_greeting del archivo de recursos de John tenemos que usar el siguiente Properties.John y luego Resource.Action_greeting.

Ahí está el problema.

Esto se debe a que si estamos desarrollando una aplicación para muchos clientes, es una mala idea cambiar la forma en que llamamos a los archivos de recursos para cada uno de ellos.

¿Te imaginas eso? Compilando la aplicación para cada cliente y cambiando John a Doe y luego a otra cosa. ¡Eso es una locura!

Solución

Nuestro líder de equipo pensó en un método bastante bueno, algo así como un sistema alternativo, debemos tener un modelo base de recursos, y luego para cada uno de los clientes tener un archivo de recursos que actualizará el archivo con sus recursos, y terminamos con una única lista de recursos.

Si el cliente no quiere recursos personalizados usamos los recursos base, y si los quiere, usamos los suyos.

Para poner esto en una lista de verificación, tenemos que hacer:

[] Encuentre una manera de asignar todas las claves/valores a un diccionario para los recursos integrados.
[] Encuentre una manera de asignar todas las claves/valores a un diccionario para los recursos externos
[] Mezclar ambos archivos y tener un único diccionario para cada idioma
[] Crea un método que accede al diccionario y devuelve el valor.

Diagrama

Codifiquemos

En primer lugar, creemos una clase separada donde tendremos toda nuestra lógica, desde obtener los archivos de recursos hasta mezclarlos y devolver el valor. Esa clase se llamará CustomResources.

Esto es lo que parece:

 class CustomResources
 {

 private static Dictionary<string, string> _ResourcesEnglish;
 private static Dictionary<string, string> ResourcesEnglish;

 private static Dictionary<string, string> _ResourcesSpanish;
 private static Dictionary<string, string> ResourcesSpanish;


 private static Dictionary<string, string> OverwriteDictionary(Dictionary<string, string> currentDictionary, Dictionary<string, string> newDictionary, bool addIfDoesntExist = false)
 {
 ...
 }

 private static Dictionary<string, string> GetDictionaryFromEmbedded(string embedded, string cultureInfoCode)
 {
 ...
 }

 private static Dictionary<string, string> GetDictionaryFromFile(string file)
 {
 ...
 }

 public static string GetText(string key)
 {
 ...
 }

 public static string GetText(string key, string language)
 {
 ...
 }
 }

Tenga en cuenta que estamos implementando la carga diferida para las propiedades, lo que ayuda a aumentar el rendimiento y hace que el diccionario se cargue una vez.

GetDictionaryFromEmbedded: devuelve un diccionario de recursos integrados.
GetDictionaryFromFile: devuelve un diccionario de recursos externos.
OverwriteDictionary: mezcla dos diccionarios y devuelve uno solo.
GetText: devuelve un valor dada una clave

Del recurso incrustado al diccionario

Tenemos que obtener todas las propiedades del archivo xml y devolver un diccionario:

private static Dictionary<string, string> GetDictionaryFromEmbedded(string embedded, string cultureInfoCode)
{
 Dictionary<string, string> res = new Dictionary<string, string>();

 try
 {
 ResourceManager rm = new ResourceManager(embedded, Assembly.GetExecutingAssembly());
 var resourceSet = rm.GetResourceSet(new CultureInfo(cultureInfoCode), true, true);

 var resourceDictionary = resourceSet.Cast<DictionaryEntry>()
 .ToDictionary(r => r.Key.ToString(),
 r => r.Value.ToString());
 res = resourceDictionary;
 }
 catch (Exception e)
 {
 string a = e.Message;
 // Error getting resource file
 }

 return res;
}

Dos cosas:- Tenga en cuenta que necesita un parámetro llamado embedded, que parementers es el nombre del archivo que puede ver en el diseñador, en nuestro caso es: resources-demo.Properties.Resource.

También tenemos un parámetro llamado cultreInfoCode, que es el código del idioma a seleccionar. Por suerte para nosotros, .NET Framework hace el trabajo por nosotros y no tenemos que hacer nada, simplemente configurar que queremos inglés o español, y seleccionará entre resource.es.resx o resource.resx

Del recurso externo al diccionario

Obtener un archivo un poco complicado pero no difícil, tenemos que obtener la ubicación actual del ejecutable, concatenar la ubicación del archivo de recursos y luego analizarlo en un diccionario.

Pero primero hay que añadir la referencia a System.Windows.Forms, para poder acceder a ResXResourceReader.

Ahora a nuestro método GetDictionaryFromFile:

private static Dictionary<string, string> GetDictionaryFromFile(string file)
{
 Dictionary<string, string> res = new Dictionary<string, string>();
 string currentPath = (System.IO.Path.GetDirectoryName(System.Reflection.Assembly.GetExecutingAssembly().GetName().CodeBase) + file).Replace("file:\\", "");

 try
 {
 using (ResXResourceReader resxReader = new ResXResourceReader(currentPath))
 {
 foreach (DictionaryEntry entry in resxReader)
 {
 res.Add((string)entry.Key, (string)entry.Value);
 }
 }
 }
 catch (Exception e)
 {
 string a = e.Message;
 }

 return res;
}

Los parámetros del archivo deben completarse con la ubicación desde el ejecutable hasta el archivo de recursos, en nuestro caso es: "\\Properties\\John\\Resource.resx".

Mezclar diccionarios

Ya casi hemos terminado, primero, recuerda agregar System.Configuration a las referencias para que puedas acceder a app.settings.

 private static Dictionary<string, string> OverwriteDictionary(Dictionary<string, string> currentDictionary, Dictionary<string, string> newDictionary, bool addIfDoesntExist = false)
{
 var identifier = ConfigurationManager.AppSettings["CustomResources.Folder"];
 if (String.IsNullOrEmpty(identifier))
 return currentDictionary;

 foreach (var item in newDictionary)
 {
 try
 {
 currentDictionary[item.Key] = item.Value;
 }
 catch (Exception)
 {
 if(addIfDoesntExist)
 currentDictionary.Add(item.Key, item.Value);
 }
 }

 return currentDictionary;
}

Obtener texto del diccionario

Cree un método público que llame a un método privado que seleccione un idioma:

private static string GetText(string key, string language)
{
 try
 {
 switch (language)
 {
 case "es":
 return ResourceSpanish[key];
 case "en":
 default:
 return ResourceEnglish[key];
 }
 }
 catch (Exception)
 {
 return $"No value with key: {key} and language: {language}";
 }
}

public static string GetText(string key)
{
 try
 {
 return GetText(key, Thread.CurrentThread.CurrentCulture.TwoLetterISOLanguageName);
 }
 catch (Exception)
 {
 return $"No value with key: {key}";
 }
}

Tenga en cuenta que debe modificar el interruptor si agrega más idiomas.

Agregar código al captador de propiedades

Como ahora tenemos todos los métodos, podemos modificar el captador de la propiedad pública para obtener los valores.

private static Dictionary<string, string> _ResourcesEnglish;
private static Dictionary<string, string> ResourcesEnglish
{
 get
 {
 if (_ResourcesEnglish == null)
 {
 var folderIndentifier = ConfigurationManager.AppSettings["CustomResources.Folder"]; ;
 var baseResources = GetDictionaryFromEmbedded("resources-demo.Properties.Resource");
 var customResources = GetDictionaryFromFile($"\\Properties\\{folderIndentifier}\\Resource.resx", "en");
 _ResourcesEnglish = OverwriteDictionary(baseResources, customResources);
 }

 return _ResourcesEnglish;
 }
}

private static Dictionary<string, string> _ResourcesSpanish;
private static Dictionary<string, string> ResourcesSpanish
{
 get
 {
 if (_ResourcesSpanish == null)
 {
 var folderIndentifier = ConfigurationManager.AppSettings["CustomResources.Folder"]; ;
 var baseResources = GetDictionaryFromEmbedded("resources-demo.Properties.Resources");
 var customResources = GetDictionaryFromFile($"\\Properties\\{folderIndentifier}\\Resources.es.resx", "es");
 _ResourcesSpanish = OverwriteDictionary(baseResources, customResources);
 }

 return _ResourcesSpanish;
 }
}

Primero obtenemos el identificador de la configuración de la aplicación.
Luego obtenemos los recursos base, los integrados.
Después de eso obtenemos los recursos personalizados y para eso necesitamos el nombre de la carpeta (que es el identificador).
Luego los mezclamos y devolvemos el valor.

Todo esto se hará una vez, por ejemplo, la carga diferida.

Pruebas

Todo lo relacionado con el código está terminado, así que ahora probémoslo, para obtener un valor del diccionario tenemos que llamar al método CustomResources.GetText(string key) que devuelve el valor.

Actualización de archivos de recursos completos

Esta prueba es un caso en el que queremos actualizar toda la clave/valor de los archivos de recursos, como puede ver en las imágenes, tenemos las mismas claves pero diferentes valores.

Probaremos John y, para configurarlo, tendremos app.config configurado en <add key="CustomResources.Folder" value="John" />.

Ahora revisemos nuestro archivo de recursos base (Properties/Resource.es.resx):

Y luego nuestro archivo de recursos externos (Properties/John/Resource.es.resx):

Bien, con todo configurado, ejecutamos la aplicación de consola, paremos en la parte get de las propiedades y verifiquemos todo.

folderIdentifier tiene el valor del appsetting:

baseResources tiene el valor de los recursos base, los incrustados:

customResources tiene los valores de los recursos externos dentro de la carpeta John:

Y finalmente, _ResourcesSpanish tiene el valor mezclado desde los recursos base hasta los recursos externos.

Actualizando solo uno

Ahora probemos lo mismo pero con un escenario diferente, simplemente actualice una clave y deje que la otra sea la misma.

Como puede ver, los archivos tienen el mismo significado de valor para Action_greeting pero un valor diferente para Action_cancel, por lo que debería actualizarse solo Action_cancel.

Falta el archivo de recursos

Si no proporcionas el archivo de recursos externo no importa en absoluto porque como esperamos tener un archivo, si falla devolverá un diccionario vacío y al mezclar ambos diccionarios terminará con el base.

Falta par en recurso incrustado

Si tiene un par en el archivo de recursos externo, de forma predeterminada no lo agregará al diccionario final, puede cambiar eso llamando al método OverwriteDictionary() al mezclar ambos diccionarios y estableciendo el parámetro addIfDoesntExist en true.

Diferentes idiomas

Como puede ver, no especificamos ningún idioma, porque todo eso lo hace la función GetText(string key) que llama a GetText(string key, string language), y el parámetro language se completa con TwoLetterISOLanguageName que devuelve el idioma actual de nuestro hilo.

En mi caso tengo el español como idioma predeterminado y por eso siempre lo muestra en español, pero podemos intentar usar inglés también.

Codifiquemos un poco y construyamos algo para verificar tanto en español como en inglés.

static void Main(string[] args)
{

 // System.Threading.Thread.CurrentThread.CurrentUICulture = new CultureInfo("en-US");
 System.Threading.Thread.CurrentThread.CurrentCulture = new CultureInfo("en-US");
 WriteText("Action_greeting");
 WriteText("Action_cancel");

 // System.Threading.Thread.CurrentThread.CurrentUICulture = new CultureInfo("es-ES");
 System.Threading.Thread.CurrentThread.CurrentCulture = new CultureInfo("es-ES");
 WriteText("Action_greeting");
 WriteText("Action_cancel");

 Console.Read();
}

private static void WriteText(string key) {
 Console.WriteLine($"[Culture: {System.Threading.Thread.CurrentThread.CurrentCulture}] Key: {key} -> value: {CustomResources.GetText(key)}");
}

Al ejecutar esto, el resultado debería ser algo como esto:

[Culture: en-US] Key: Action_greeting -> value: Hello
[Culture: en-US] Key: Action_cancel -> value: Finish
[Culture: es-ES] Key: Action_greeting -> value: Hola
[Culture: es-ES] Key: Action_cancel -> value: Terminar

Los primeros dos valores son de resources.resx que están en inglés y los últimos ambos están en español y los valores se recuperan de resources.es.resx.

Eso es todo

En este tutorial encontramos una manera de combinar recursos integrados y externos para idiomas, esta fue una solución para un problema que teníamos en el equipo y ha estado funcionando desde entonces sin ningún problema.

Puedes consultar el código fuente aquí.

Si tienes alguna pregunta, no dudes en enviarme un tweet a @emimontesdeocaa y te responderé cuando tenga tiempo.

Prueba de integración usando Bot Framework y DirectLine para casos de flujo

Wed, 25 Apr 2018 00:00:00 +0000

Introducción

En publicaciones de blog anteriores, hicimos algunas pruebas de integración para casos individuales. Los “casos únicos” son aquellos casos en los que después de preguntarle algo al bot, este responderá solo una vez y luego comparamos los resultados.

Esta guía no explica cómo se realizan la autenticación y las llamadas API. Si desea consultarlo, consulte la guía de casos individuales.

¿Qué pasa con las conversaciones fluidas?

Usando la forma actual no tenemos ningún tipo de flujo en la conversación, por ejemplo, si quieres pedir ayuda y luego aparece un menú con diferentes opciones, y luego de seleccionar una de ellas, otro menú. Esto haría como 2 o más responses. Esto significa que usar la solución de prueba de integración que usamos antes no funcionará.

A continuación se muestra un diagrama de cómo funciona la prueba de integración para casos individuales.

Y aquí hay un diagrama de cómo vamos a adaptar la solución de prueba de integración actual a los casos de flujo.

La siguiente explicación no cubrirá toda la información básica sobre cómo funciona Bot Framework. Si no lo comprende, consulte la documentación oficial.

Caso de ejemplo

Para la siguiente guía, usaré un bot con una conversación fluida creada por mí, que pide ayuda y luego selecciona diferentes opciones.

Nueva estructura JSON

Ahora que tenemos más de un request al hablar con el bot, necesitamos modificar nuestra estructura json para agregar todos los request que estaremos haciendo.

{
 "secret": "direct-line-secret",
 "directlineGenerateTokenEndpoint":
 "https://directline.botframework.com/v3/directline/tokens/generate",
 "directlineConversationEndpoint":
 "https://directline.botframework.com/v3/directline/conversations/",
 "entries": [
 {
 "name": "PedirAyuda",
 "requests": [
 {
 "type": "message",
 "text": "Ayuda",
 "from": {
 "id": "default-user",
 "name": "User"
 },
 "locale": "es",
 "textFormat": "plain",
 "timestamp": "2018-04-09T08:04:37.195Z",
 "channelData": {
 "clientActivityId": "1523261059363.6264723268323733.0"
 },
 "entities": [
 {
 "type": "ClientCapabilities",
 "requiresBotState": true,
 "supportsTts": true,
 "supportsListening": true
 }
 ],
 "id": "61hacck8j6jg"
 },
 {
 "type": "message",
 "text": "Telefono",
 "from": {
 "id": "default-user",
 "name": "User"
 },
 "locale": "es",
 "textFormat": "plain",
 "timestamp": "2018-04-09T08:04:37.195Z",
 "channelData": {
 "clientActivityId": "1523261059363.6264723268323733.0"
 },
 "entities": [
 {
 "type": "ClientCapabilities",
 "requiresBotState": true,
 "supportsTts": true,
 "supportsListening": true
 }
 ],
 "id": "61hacck8j6jg"
 },
 {
 "type": "message",
 "text": "Oficina",
 "from": {
 "id": "default-user",
 "name": "User"
 },
 "locale": "es",
 "textFormat": "plain",
 "timestamp": "2018-04-09T08:04:37.195Z",
 "channelData": {
 "clientActivityId": "1523261059363.6264723268323733.0"
 },
 "entities": [
 {
 "type": "ClientCapabilities",
 "requiresBotState": true,
 "supportsTts": true,
 "supportsListening": true
 }
 ],
 "id": "61hacck8j6jg"
 },
 {
 "type": "message",
 "text": "Tenerife",
 "from": {
 "id": "default-user",
 "name": "User"
 },
 "locale": "es",
 "textFormat": "plain",
 "timestamp": "2018-04-09T08:04:37.195Z",
 "channelData": {
 "clientActivityId": "1523261059363.6264723268323733.0"
 },
 "entities": [
 {
 "type": "ClientCapabilities",
 "requiresBotState": true,
 "supportsTts": true,
 "supportsListening": true
 }
 ],
 "id": "61hacck8j6jg"
 }
 ],
 "response": {
 "type": "message",
 "timestamp": "2018-04-09T08:04:37.901Z",
 "localTimestamp": "2018-04-09T09:04:37+01:00",
 "serviceUrl": "http://localhost:50629",
 "channelId": "emulator",
 "from": {
 "id": "j98bbdf097a",
 "name": "Bot"
 },
 "conversation": {
 "id": "eabcie4be8ak"
 },
 "recipient": {
 "id": "default-user"
 },
 "locale": "es",
 "text": "922920252",
 "attachments": [],
 "entities": [],
 "replyToId": "61hacck8j6jg",
 "id": "47me557ikbf7"
 },
 "assert": "Request.Text == Response.Text"
 }
 ]
}

Como puedes ver, hay un cambio importante, request ahora es requests. Eso significa que ahora tenemos un List<Activity> en lugar de un único activity.

Nuevos objetos

Anteriormente teníamos nuestros objetos configurados para casos únicos: TestEntry y TestEntryCollection. Para casos de flujo crearemos nuevos objetos: TestEntryFlow y TestEntryFlowCollection.

`TestEntryFlow`

Este objeto es para cada entrada que tenemos en la colección, mira que el objeto Requests ahora es un List<Activity> en lugar de un solo Activity como mencioné antes.

Dado que le preguntaremos al bot varias veces, necesitamos tener varios activities que se enviarán a la conversación.

public class TestEntryFlow
{
 /// <summary>
 /// Entry name
 /// </summary>
 [JsonProperty("name")]
 public string Name { get; set; }
 /// <summary>
 /// Activity requested by the entry
 /// </summary>
 [JsonProperty("requests")]
 public List<Activity> Requests { get; set; }
 /// <summary>
 /// Activity response expected by the entry
 /// </summary>
 [JsonProperty("response")]
 public Activity Response { get; set; }
 /// <summary>
 /// Assert value in string
 /// </summary>
 [JsonProperty("assert")]
 public string Assert { get; set; }
}

`TestEntiresCollection`

Este objeto contendrá la información relevante para DirectLine como el secret y los puntos finales, además de la lista de Entries que estaremos probando.

Tenga en cuenta que el Entries ahora es una lista de TestEntryFlow y no TestEntry.

public class TestEntryFlowCollection
{
 /// <summary>
 /// DirectLine Secret
 /// </summary>
 [JsonProperty("secret")]
 public string Secret { get; set; }
 /// <summary>
 /// Endpoint to get the token using the secret for DirectLine
 /// </summary>
 [JsonProperty("directlineGenerateTokenEndpoint")]
 public string DirectLineGenerateTokenEndpoint { get; set; }
 /// <summary>
 /// Endpoint for a conversation in DirectLine
 /// </summary>
 [JsonProperty("directlineConversationEndpoint")]
 public string DirectLineConversationEndpoint { get; set; }
 /// <summary>
 /// Entries list
 /// </summary>
 [JsonProperty("entries")]
 public List<TestEntryFlow> Entries { get; set; }
}

Creando el `TestMethod` para casos de flujo

Nuevo flujo

En primer lugar, eche un vistazo nuevamente al diagrama (es el mismo que publiqué arriba).

Como puedes ver, la estructura de flujo para realizar la prueba es prácticamente la misma:

Obtener información
Autenticar
Crea una conversaciónY aquí lo que cambia, ahora tenemos que enviar varias veces todas las solicitudes a la conversación. Para hacer esto, tenemos que realizar un bucle para cada solicitud, enviarla al bot y luego comparar la última respuesta con nuestra respuesta esperada.
Enviar todas las solicitudes
Recibe todos los mensajes
Obtenga la última respuesta
Comparar con la respuesta esperada
Afirmar el resultado

Código

En primer lugar, necesitamos obtener la información del archivo, esto es lo mismo que hicimos antes con los casos individuales.

// Load entries from file
var path = System.IO.File.ReadAllText(@"C:\dataFlow.json");

// Deserialize to object
var data = JsonConvert.DeserializeObject<TestEntryFlowCollection>(path);

Ahora tenemos que hacer un bucle para cada TestEntryFlow, del data.entries, con eso podemos seguir el mismo flujo que hicimos en los casos individuales hasta la nueva parte, donde hacemos un bucle en el requests.

/// Arrange with current requested values
string token, newToken, conversationId;
Activity latestResponse = new Activity();

/// Act for step

/// 1 - Get token using secret from DirectLine in BotFramework panel
token = Utils.uploadString<DirectLineAuth>(data.Secret, data.DirectLineGenerateTokenEndpoint, "").token;

/// 2 - Create a new conversation
var createdConversation = Utils.uploadString<DirectLineAuth>(token, data.DirectLineConversationEndpoint, "");

// This returns a new token and a conversationId
newToken = createdConversation.token;
conversationId = createdConversation.conversationId;

/// 3 - Send an activity to the conversation with new token and conversationId
string directlineConversationActivitiesEndpoint = data.DirectLineConversationEndpoint + conversationId + "/activities";

El siguiente paso es bastante simple, tenemos que realizar un bucle en el entry.requests y enviar cada activity a la conversación.

foreach (Activity step in entry.Requests)
{
 if (step.Type == ActivityTypes.Message)
 {
 /// Step
 Utils.uploadString<DirectLineAuth>(newToken, directlineConversationActivitiesEndpoint, JsonConvert.SerializeObject(step));

 /// 4 - Get all activities, we get a List<activity> and a watermark
 var getLastActivity = Utils.downloadString<ActivityResponse>(newToken, directlineConversationActivitiesEndpoint);

 /// 5 - Get the latest activity which is the response we should be expecting
 latestResponse = getLastActivity.activities[Int32.Parse(getLastActivity.watermark)];
 }
}

Usamos watermark para obtener el último mensaje, watermark es un valor que la API de DirectLine devuelve cuando solicita la información de la conversación.

Después de eso, solo nos queda llenar el globals con nuestro latestReponse y expectedResponse.

/// Arrange with new values
var globals = new Objects.Globals { Request = entry.Response, Response = latestResponse };

Y para finalizar el caso, evaluamos la cadena assert en el entry.

/// Assert
Assert.IsTrue(await CSharpScript.EvaluateAsync<bool>(entry.Assert, globals: globals));

Código final

[TestMethod]
public async Task ShouldTestFlowCases()
{
 // Load entries from file
 var path = System.IO.File.ReadAllText(@"C:\dataFlow.json");

 // Deserialize to object
 var data = JsonConvert.DeserializeObject<TestEntryFlowCollection>(path);

 /// Flow: Arrange -> Act -> arrange -> assert
 foreach (TestEntryFlow entry in data.Entries)
 {
 /// Arrange with current requested values
 string token, newToken, conversationId;
 Activity latestResponse = new Activity();

 /// Act for step

 /// 1 - Get token using secret from DirectLine in BotFramework panel
 token = Utils.uploadString<DirectLineAuth>(data.Secret, data.DirectLineGenerateTokenEndpoint, "").token;

 /// 2 -Create a new conversation
 var createdConversation = Utils.uploadString<DirectLineAuth>(token, data.DirectLineConversationEndpoint, "");

 // This returns a new token and a conversationId
 newToken = createdConversation.token;
 conversationId = createdConversation.conversationId;

 /// 3 - Send an activity to the conversation with new token and conversationId
 string directlineConversationActivitiesEndpoint = data.DirectLineConversationEndpoint + conversationId + "/activities";

 foreach (Activity step in entry.Requests)
 {
 if (step.Type == ActivityTypes.Message)
 {
 /// Step
 Utils.uploadString<DirectLineAuth>(newToken, directlineConversationActivitiesEndpoint, JsonConvert.SerializeObject(step));

 /// 4 - Get all activities, we get a List<activity> and a watermark
 var getLastActivity = Utils.downloadString<ActivityResponse>(newToken, directlineConversationActivitiesEndpoint);

 /// 5 - Get the latest activity which is the response we should be expecting
 latestResponse = getLastActivity.activities[Int32.Parse(getLastActivity.watermark)];
 }
 }

 /// Arrange with new values
 var globals = new Objects.Globals { Request = entry.Response, Response = latestResponse };

 /// Assert
 Assert.IsTrue(await CSharpScript.EvaluateAsync<bool>(entry.Assert, globals: globals));
 }

 await Task.CompletedTask;
}

Mejoras

Creo que podría ser posible un mejor flujo, pero esta mejora significará que la estructura JSON también debería cambiarse. Además, para que esto suceda, el json debe estar más lleno.

Para mejorar esta prueba, deberíamos tener un response para cada request y deberíamos afirmarlo cada vez que enviemos un mensaje. La forma en que lo estamos haciendo ahora es almacenando todos los requests y el [[TOK_56]]] final.

Hice un diagrama para mostrar cómo se vería esto.

Creo firmemente que de esta manera es mucho mejor en general para la integridad de la prueba, ya que se prueban prácticamente todos los comportamientos en el flujo en lugar de simplemente probar la respuesta final.

Bueno, eso es todo por esta guía, recuerde que esta guía pretende ser una continuación de la guía de casos individuales, si se siente perdido, consulte esa guía que es más larga y tiene más explicaciones para todo.

Recuerde que todo el código está almacenado en mi github en este repositorio.

¡Que tenga un buen día!

Prueba de integración usando Bot Framework y DirectLine (1)

Tue, 24 Apr 2018 00:00:00 +0000

Desde que comencé a trabajar en una empresa por un corto período de tiempo, me asignaron trabajar en pruebas de integración para Bot Framework.

Mi trabajo en el grupo es hacer que el bot sea lo más estable posible, pero primero, ¿qué es Bot Framework?

Cree, conecte, implemente y administre bots inteligentes para interactuar naturalmente con sus usuarios en un sitio web, aplicación, Cortana, Microsoft Teams, Skype, Slack, Facebook Messenger y más. Comience rápidamente con un entorno completo de creación de bots, mientras paga solo por lo que usa.

Puede encontrar más información sobre Bot Framework directamente aquí.

La siguiente explicación no cubrirá toda la información básica sobre cómo funciona Bot Framework. Si no lo comprende, consulte la documentación oficial.

¿Por qué necesito una prueba de integración?

Las pruebas de integración son necesarias porque cada vez que uno de mis compañeros de trabajo implementa una solución, una nueva característica o incluso un nuevo error, estas pruebas se ejecutarán antes de enviar el código a producción y, si alguna de las pruebas falla, el código no pasará a producción, lo que significa que el usuario final no tendrá el error.

¿Prueba de integración en bots?

Creo que en los bots las pruebas de integración son bastante importantes. No puede tener un bot donde algunos de sus menús no funcionan o algunas de las funciones no devuelven nada.

Las empresas están utilizando bots para sus clientes porque no quieren que la gente esté ocupada con sus problemas; si un bot puede ayudar a un usuario, los demás trabajadores podrán utilizar su tiempo para hacer algo más importante.

Descripción general de la solución.

Para que esto funcione, utilicé un proyecto de prueba en Visual Studio, que utilizará WebClient para API Rest y un archivo Json, donde almacenaremos nuestros casos.

archivo JSON

{
 "secret": "direct-line-secret",
 "directlineGenerateTokenEndpoint": "https://directline.botframework.com/v3/directline/tokens/generate",
 "directlineConversationEndpoint": "https://directline.botframework.com/v3/directline/conversations/",
 "entries": [
 {
 "name": "DecirHola",
 "request": {
 "type": "message",
 "text": "Hola",
 "from": {
 "id": "default-user",
 "name": "User"
 },
 "locale": "es",
 "textFormat": "plain",
 "timestamp": "2018-04-09T08:04:37.195Z",
 "channelData": {
 "clientActivityId": "1523261059363.6264723268323733.0"
 },
 "entities": [
 {
 "type": "ClientCapabilities",
 "requiresBotState": true,
 "supportsTts": true,
 "supportsListening": true
 }
 ],
 "id": "61hacck8j6jg"
 },
 "response": {
 "type": "message",
 "timestamp": "2018-04-09T08:04:37.901Z",
 "localTimestamp": "2018-04-09T09:04:37+01:00",
 "serviceUrl": "http://localhost:50629",
 "channelId": "emulator",
 "from": {
 "id": "j98bbdf097a",
 "name": "Bot"
 },
 "conversation": {
 "id": "eabcie4be8ak"
 },
 "recipient": {
 "id": "default-user"
 },
 "locale": "es",
 "text": "No tengo respuesta para eso.",
 "attachments": [],
 "entities": [],
 "replyToId": "61hacck8j6jg",
 "id": "47me557ikbf7"
 },
 "assert": "Request.Text == Response.Text"
 }
 ]
}

Como puedes ver tenemos:

Secreto de línea directa -> secreto del bot publicado
Punto final de generación de token de Directline -> punto final para obtener el token usando el secreto
Punto final de conversación de línea directa -> punto final para jugar con la conversación
Entrada -> el caso de prueba
- Solicitar -> qué enviamos a la conversación
- Respuesta -> qué esperamos obtener
- Afirmar -> qué estamos comparando

Deserialización

Tenemos el archivo json perfectamente formateado, ahora tenemos que cargarlo en la solución, por lo que usaremos JSON.NET y algunas clases. Primero tenemos la colección de entradas, que lo tiene todo, y luego tenemos, para cada colección, una lista de entradas.

 /// <summary>
 /// Object to parse from the file
 /// </summary>
 public class TestEntriesCollection
 {
 /// <summary>
 /// DirectLine Secret
 /// </summary>
 [JsonProperty("secret")]
 public string Secret { get; set; }
 /// <summary>
 /// Endpoint to get the token using the secret for DirectLine
 /// </summary>
 [JsonProperty("directlineGenerateTokenEndpoint")]
 public string DirectLineGenerateTokenEndpoint { get; set; }
 /// <summary>
 /// Endpoint for a conversation in DirectLine
 /// </summary>
 [JsonProperty("directlineConversationEndpoint")]
 public string DirectLineConversationEndpoint { get; set; }
 /// <summary>
 /// Entries list
 /// </summary>
 [JsonProperty("entries")]
 public List<TestEntry> Entries { get; set; }
 }

Y este es el objeto que tiene el nombre, solicitud, respuesta y afirmación para el caso de prueba.


 public class TestEntry
 {
 /// <summary>
 /// Entry name
 /// </summary>
 [JsonProperty("name")]
 public string Name { get; set; }
 /// <summary>
 /// Activity requested by the entry
 /// </summary>
 [JsonProperty("request")]
 public Activity Request { get; set; }
 /// <summary>
 /// Activity response expected by the entry
 /// </summary>
 [JsonProperty("response")]
 public Activity Response { get; set; }
 /// <summary>
 /// Assert value in string
 /// </summary>
 [JsonProperty("assert")]
 public string Assert { get; set; }
 }

Análisis de json a objeto en el caso de prueba

Tener las clases para el objeto de análisis es bastante fácil ya que necesitamos leer como objeto.

// Load entries from file
var path = System.IO.File.ReadAllText(@"C:\data.json");

// Deserialize to object
var data = JsonConvert.DeserializeObject<TestEntriesCollection>(path);

Ahora, con esta colección, podremos recorrerla y obtener la información usando, por ejemplo, un foreach.

 foreach (TestEntry entry in data.Entries)
 {
 ....
 }

Y eso es todo por esta parte, la siguiente parte incluirá la autorización para DirectLine, recuerde que todo el código está almacenado en mi github en este repositorio.

Prueba de integración usando Bot Framework y DirectLine (2)

Tue, 24 Apr 2018 00:00:00 +0000

En esta parte, realizaremos la autorización de DirectLine y obtendremos los valores de la respuesta del bot.

Ahora que hemos deserializar, es hora de obtener la información de la colección y los archivos completos que usaremos para obtener autorización, realizar las llamadas a la API y afirmar el resultado.

La siguiente explicación no cubrirá toda la información básica sobre cómo funciona Bot Framework. Si no lo comprende, consulte la documentación oficial.

Realizar llamadas API usando WebClient

Para facilitarnos el llamado a la API, creé una clase utils, donde guardamos las funciones que usaremos varias veces, esta clase incluye uploadString para POST y downloadString para GET.

 public class Utils
 {
 /// <summary>
 /// Uploads to an URL and gets result
 /// </summary>
 /// <typeparam name="T">Type of object you are receiving</typeparam>
 /// <param name="bearer">Token</param>
 /// <param name="url">Url</param>
 /// <param name="serializedJson">Serialized JSON to send</param>
 /// <returns></returns>
 public static T uploadString<T>(string bearer, string url, string serializedJson)
 {
 string serializedResult = "";

 /// Webclient
 using (var client = new WebClient())
 {
 /// Add headers
 client.Headers.Add("Content-Type", "application/json");
 client.Headers.Add("Authorization", $"Bearer {bearer}");

 /// Upload string
 serializedResult = client.UploadString(url, serializedJson);
 }

 /// Get result and return it as an object
 return JsonConvert.DeserializeObject<T>(serializedResult);
 }

 /// <summary>
 /// Downloads from URL
 /// </summary>
 /// <typeparam name="T">Type of object you are receiving</typeparam>
 /// <param name="bearer">Token</param>
 /// <param name="url">Url</param>
 /// <returns></returns>
 public static T downloadString<T>(string bearer, string url)
 {
 string serializedResult = "";

 /// Webclient
 using (var client = new WebClient())
 {
 /// Add headers
 client.Headers.Add("Content-Type", "application/json");
 client.Headers.Add("Authorization", $"Bearer {bearer}");

 /// Download string
 serializedResult = client.DownloadString(url);
 }

 /// Get result and return it as an object
 return JsonConvert.DeserializeObject<T>(serializedResult);
 }
 }

Autorización de línea directa

Si lees la documentación oficial podrás encontrar cómo hacerlo, y es bastante fácil, usando nuestras funciones es aún más fácil. Primero que nada recuerda que estamos dentro de la sentencia foreach, ya que estamos haciendo la autenticación para cada caso, en caso de que se nos acabe el tiempo, lo que significará que la prueba fallará.

/// Arrange with current requested values
string token, newToken, conversationId;
/// Act

/// 1 - Get token using secret from DirectLine in BotFramework panel
token = Utils.uploadString<DirectLineAuth>(data.Secret, data.DirectLineGenerateTokenEndpoint, "").token;

Ahora tenemos el token, que se utilizará para realizar todas las siguientes llamadas al punto final de la conversación.

Creando una conversación.

Para hablar con el bot, primero debemos crear una conversación, esta conversación devolverá un nuevo token que incluye la identificación de la conversación.

/// 2 -Create a new conversation
var createdConversation = Utils.uploadString<DirectLineAuth>(token, data.DirectLineConversationEndpoint, "");

// This returns a new token and a conversationId
newToken = createdConversation.token;
conversationId = createdConversation.conversationId;

Además, almacenamos newToken y conversationId, ambos serán necesarios para que el usuario envíe mensajes al bot.

Enviar actividad a la conversación

Ahora, con el conversationId y el conversationEndpoint, podemos crear el punto final para enviar un Activity que es el request del archivo json.

/// 3 - Send an activity to the conversation with new token and conversationId
string directlineConversationActivitiesEndpoint = data.DirectLineConversationEndpoint + conversationId + "/activities";
Utils.uploadString<DirectLineAuth>(newToken, directlineConversationActivitiesEndpoint, JsonConvert.SerializeObject(entry.Request));

Obtener el último mensaje

En el historial de mensajes, después de que enviamos la actividad, el bot ya debería haber respondido, por lo que tenemos que obtener todos los mensajes con la marca de agua y luego, usando esa marca de agua, filtrar el último mensaje/actividad.

/// 4 - Get all activities, we get a List<activity> and a watermark
var getLastActivity = Utils.downloadString<ActivityResponse>(newToken, directlineConversationActivitiesEndpoint);

/// 5 - Get the latest activity which is the response we should be expecting
var latestResponse = getLastActivity.activities[Int32.Parse(getLastActivity.watermark)];

Y eso es todo por esta parte, la siguiente parte incluirá la parte donde obtenemos el texto de assert en el json, lo convertimos a código como si usamos eval() en Javascript pero en C#, y luego usamos Assert.isTrue() para obtener el resultado final de la prueba.

Recuerde que todo el código está almacenado en mi github en este repositorio.

Prueba de integración usando Bot Framework y DirectLine (3)

Tue, 24 Apr 2018 00:00:00 +0000

Esta es la última parte de la guía; en esta parte evaluaremos el texto de la afirmación en el json.

Ahora que usamos request y lo enviamos como activity al bot, obtuvimos el response y tenemos que comparar lo que assert en el json (la respuesta que hemos almacenado en el json, esta es la respuesta esperada) con la respuesta que obtuvimos del bot.

La siguiente explicación no cubrirá toda la información básica sobre cómo funciona Bot Framework. Si no lo comprende, consulte la documentación oficial.

Agregar Microsoft.CodeAnalysis a la solución

En primer lugar, debemos incluir CodeAnalysis como un paquete NuGet.

Después de la instalación, recuerde agregar el paquete al archivo .cs.

using Microsoft.CodeAnalysis.CSharp.Scripting;

Creando un objeto `Globals`

Para evaluar, tenemos que pasar los parámetros al evaluador. Este evaluador necesita un archivo de configuración.

 /// <summary>
/// Object to pass parameters to Roslyn compiler
/// </summary>
public class Globals
{
 /// <summary>
 /// ExpectedResponse
 /// </summary>
 public Activity Request;
 /// <summary>
 /// ReceivedResponse
 /// </summary>
 public Activity Response;
}

Esta parte es muy importante, en ese archivo de configuración incluiremos qué objetos compararemos, por lo que debemos pasarle la respuesta esperada y la respuesta recibida.

Con esa información estará usando el assert en el archivo json y estará evaluando lo que dice.

/// Arrange with new values
var globals = new Objects.Globals { Request = entry.Response, Response = latestResponse };

/// Assert
Assert.IsTrue(await CSharpScript.EvaluateAsync<bool>(entry.Assert, globals: globals));

El EvaluateAsync<T> evalúa y devuelve T, en nuestro caso pasamos el string a evaluar y el globals, que tiene los datos donde evaluará.

Voy a intentar explicar esto con un ejemplo, usando una entrada (que tiene un nombre, solicitud, respuesta y afirmación).

{
 "name": "DecirHola",
 "request": {
 "type": "message",
 "text": "Hola",
 "from": {
 "id": "default-user",
 "name": "User"
 },
 "locale": "es",
 "textFormat": "plain",
 "timestamp": "2018-04-09T08:04:37.195Z",
 "channelData": {
 "clientActivityId": "1523261059363.6264723268323733.0"
 },
 "entities": [
 {
 "type": "ClientCapabilities",
 "requiresBotState": true,
 "supportsTts": true,
 "supportsListening": true
 }
 ],
 "id": "61hacck8j6jg"
 },
 "response": {
 "type": "message",
 "timestamp": "2018-04-09T08:04:37.901Z",
 "localTimestamp": "2018-04-09T09:04:37+01:00",
 "serviceUrl": "http://localhost:50629",
 "channelId": "emulator",
 "from": {
 "id": "j98bbdf097a",
 "name": "Bot"
 },
 "conversation": {
 "id": "eabcie4be8ak"
 },
 "recipient": {
 "id": "default-user"
 },
 "locale": "es",
 "text": "No tengo respuesta para eso.",
 "attachments": [],
 "entities": [],
 "replyToId": "61hacck8j6jg",
 "id": "47me557ikbf7"
 },
 "assert": "Request.Text == Response.Text"
 }

Obtengamos las cosas importantes de esta entrada, primero la afirmación "assert": "Request.Text == Response.Text", esto significa que comparará el Request.Text con el Response.Text y devolverá el valor como booleano.

Pero cuando llamamos a la función await CSharpScript.EvaluateAsync<bool>(entry.Assert, globals: globals) estamos pasando 2 parámetros:

string cadena a evaluar -> "Request.Text == Response.Text"
globals datos para el evaluador -> en este caso tenemos que dar un Request y un Response, la solicitud es nuestra respuesta esperada y la respuesta es la respuesta recibida.

Mientras completamos los datos en el evaluador, ahora podemos usar la cadena y evaluar, por lo que devolverá true o false.

Hecho

Hemos terminado, aquí puedes ver el TestMethod terminado

[TestMethod]
public async Task ShouldTestSingleCases()
{
 // Load entries from file
 var path = System.IO.File.ReadAllText(@"C:\data.json");

 // Deserialize to object
 var data = JsonConvert.DeserializeObject<TestEntriesCollection>(path);

 /// Flow: Arrange -> Act -> arrange -> assert

 foreach (TestEntry entry in data.Entries)
 {
 /// Arrange with current requested values
 string token, newToken, conversationId;

 if (entry.Request.Type == ActivityTypes.Message)
 {
 /// Act

 /// 1 - Get token using secret from DirectLine in BotFramework panel
 token = Utils.uploadString<DirectLineAuth>(data.Secret, data.DirectLineGenerateTokenEndpoint, "").token;

 /// 2 -Create a new conversation
 var createdConversation = Utils.uploadString<DirectLineAuth>(token, data.DirectLineConversationEndpoint, "");

 // This returns a new token and a conversationId
 newToken = createdConversation.token;
 conversationId = createdConversation.conversationId;

 /// 3 - Send an activity to the conversation with new token and conversationId
 string directlineConversationActivitiesEndpoint = data.DirectLineConversationEndpoint + conversationId + "/activities";
 Utils.uploadString<DirectLineAuth>(newToken, directlineConversationActivitiesEndpoint, JsonConvert.SerializeObject(entry.Request));

 /// 4 - Get all activities, we get a List<activity> and a watermark
 var getLastActivity = Utils.downloadString<ActivityResponse>(newToken, directlineConversationActivitiesEndpoint);

 /// 5 - Get the latest activity which is the response we should be expecting
 var latestResponse = getLastActivity.activities[Int32.Parse(getLastActivity.watermark)];

 /// Arrange with new values
 var globals = new Objects.Globals { Request = entry.Response, Response = latestResponse };

 /// Assert
 Assert.IsTrue(await CSharpScript.EvaluateAsync<bool>(entry.Assert, globals: globals));
 }
 }
 await Task.CompletedTask;
}

Diagrama

Aquí hay un diagrama de todo el flujo que seguimos para llegar a este punto; con suerte, si no entendiste algo, esto lo aclarará.

Y eso es todo, esto se hace para casos únicos donde el caso es 1 a 1, el usuario envía un activity y el bot devuelve otro activity.

Espero que les haya gustado, el próximo serán los casos de flujo de prueba con más de una respuesta.

Recuerde que todo el código está almacenado en mi github en este repositorio.

Charlas

Mon, 01 Jan 0001 00:00:00 +0000

Soy un ponente frecuente en conferencias tecnológicas internacionales, con enfoque en .NET, Azure, IA y desarrollo cloud-native. He sido reconocido como Sessionize Most Active Speaker en 2023, 2024 y 2025, y poseo la certificación Microsoft MVP en Tecnologías para Desarrolladores.

Si deseas que hable en tu evento, hablemos!

2026

Blazor en 2026

Un vistazo al estado actual de Blazor en 2026 y cómo ha evolucionado junto a .NET 10. Revisamos los últimos cambios y mejoras, su impacto en el desarrollo de aplicaciones del mundo real, y qué modelo de hosting de Blazor encaja mejor en cada escenario.

Potenciando el Soporte de Nivel 3 con IA: Azure Functions + OpenAI en Acción

Cómo Azure Functions, las alertas de Azure Monitor y Azure OpenAI trabajan juntos para acelerar el soporte de Nivel 3. Desde el triage automático de alertas hasta el análisis inteligente de logs — una mirada práctica a agregar IA a los flujos de soporte reales.

Del dashboard al agente: el siguiente paso de la observabilidad

Una sesión práctica que conecta el mundo de los agentes IA y la observabilidad en producción. Desde Semantic Kernel hasta agentes autónomos que consultan datos de OpenTelemetry, interactúan con Grafana vía MCP y ayudan a operar y optimizar sistemas reales.

Próximamente: Global Azure 2026 — Abril 2026, Madrid, España

2025

El Framework de Agentes de Microsoft para salvar la Navidad

Construcción y coordinación de múltiples agentes IA usando el Microsoft Agent Framework para encontrar los regalos de Navidad perfectos. Cada agente se especializa — desde la generación de ideas de regalos hasta la comparación de precios — trabajando juntos para compras navideñas más inteligentes.

Potenciando el soporte de Nivel 3 con IA: Azure Functions + Semantic Kernel en acción

Azure Functions, Azure Monitor y Semantic Kernel trabajando juntos para hacer el soporte de Nivel 3 más rápido y eficiente — desde la detección automática de alertas hasta el análisis inteligente de logs.

¿Qué hay de nuevo en Blazor con .NET 10?

Explorando las principales nuevas funcionalidades de Blazor para .NET 10, incluyendo mejoras de rendimiento, formularios, estado persistente e interoperabilidad con JavaScript más potente.

IA Híbrida con C#, Semantic Kernel y Gemini: Construye Apps Empresariales más Inteligentes

Orquestación de flujos de trabajo de IA híbrida en C# — combinando modelos locales (Phi-3) con Gemini Pro/Ultra vía Vertex AI, construyendo agentes cognitivos con plugins de Semantic Kernel y diseñando arquitecturas adaptativas.

.NET Aspire: Construyendo Apps Cloud-Native sin Dolores de Cabeza

Una sesión práctica construyendo microservicios cloud-first que nacen escalables, resilientes y observables. Explorando cómo .NET Aspire elimina el 70% del boilerplate de cloud.

.NET Aspire: Cloud-Native sin el Caos

Ejemplos del mundo real de diseño de aplicaciones que nacen escalables — con observabilidad y resiliencia automática integradas desde el primer commit.

2024

IA Encuentra SQL: Construyendo una Pizzería Inteligente con .NET y Semantic Kernel

Interacciones de IA en lenguaje natural que entienden tu código y tus datos — construyendo una pizzería inteligente impulsada por .NET y Semantic Kernel.

.NET Aspire: Aplicaciones Cloud-Native sin complicaciones

Construyendo microservicios cloud-first sin complicaciones — una sesión práctica y con demos que muestra cómo .NET Aspire simplifica el desarrollo cloud-native.

Power Platform: El viaje del Low-code a las tecnologías Pro-code

Transición desde Power Apps de bajo código hasta componentes pro-code avanzados usando TypeScript, todo dentro de la misma plataforma.

Automatización Inteligente: Transforma tus aplicaciones empresariales con IA integrada

Llevando las aplicaciones .NET al siguiente nivel — combinando lógica tradicional con razonamiento basado en IA usando Semantic Kernel y .NET Aspire.

De Low-Code a Pro-Code: Enfoques para el desarrollo de IA en soluciones empresariales

Explorando diferentes enfoques para soluciones empresariales — desde Power Platform con IA hasta desarrollo tradicional con Semantic Kernel.

Controlando los gastos de viajes con Azure

Usando Azure AI Vision, Document Intelligence y OpenAI con Semantic Kernel para automatizar la gestión de gastos de viaje.

Insignias y Reconocimientos

�� Sessionize Most Active Speaker 2025
🏆 Sessionize Most Active Speaker 2024
🏆 Sessionize Most Active Speaker 2023
🏅 Microsoft MVP en Tecnologías para Desarrolladores

Ver todas las sesiones en Sessionize →

Sobre mí

Mon, 01 Jan 0001 00:00:00 +0000

Sobre mí

Soy Emiliano Montesdeoca, un desarrollador de software uruguayo-español, Microsoft MVP en Tecnologías para Desarrolladores, y orgulloso padre radicado en Tenerife, Islas Canarias.

Me encanta enfrentar desafíos técnicos complejos y construir soluciones cloud escalables con tecnologías Microsoft. Mi kit de herramientas diario gira en torno a .NET, Azure, IA con Semantic Kernel y arquitecturas modernas como .NET Aspire.

Qué hago

Como Cloud Solutions Team Lead en Intelequia Technologies, lidero el diseño y la entrega de aplicaciones cloud-native — combinando visión estratégica con ejecución práctica. Me desenvuelvo en la intersección de la arquitectura y el código, asegurando que nuestro equipo entregue soluciones elegantes y listas para producción.

Comunidad

Soy un ponente internacional frecuente, reconocido como Sessionize Most Active Speaker en 2023, 2024 y 2025. Comparto perspectivas prácticas del mundo real a través de charlas en conferencias mundiales y en mis blogs.

También soy el creador de The .NET Blog — un recurso para la comunidad .NET — y escribo regularmente en este blog sobre lo que aprendo y construyo.

La mentoría y la construcción de comunidad son parte esencial de quien soy. Devolver algo al ecosistema que formó mi carrera es algo que tomo muy en serio.

Conectemos

Siempre estoy abierto a hablar en eventos, colaborar en proyectos o charlar sobre arquitectura cloud e IA. ¡No dudes en contactarme!

Email: emimontesdeoca@outlook.es
GitHub: @emimontesdeoca
X / Twitter: @emimontesdeocaa
LinkedIn: emimontesdeoca
Instagram: @emimontesdeoca
Sessionize: emimontesdeoca

Emiliano Montesdeoca

Blazor desde cero: Capítulo 3 — Componentes que escalan

Qué es realmente un componente en Blazor

Paso 1: Empieza con un componente enfocado

Paso 2: Usa parámetros para hacer explícito el comportamiento

Paso 3: Usa RenderFragment para composición de layout

Paso 4: Prefiere composición sobre páginas gigantes

Paso 5: Equilibra markup y lógica

Paso 6: Estructura de carpetas práctica

Errores comunes al empezar con Blazor

Próxima entrega

Blazor desde cero: Capítulo 2 — Tu primera app Blazor

Paso 1: Crear el proyecto

Paso 2: Ejecutarla en local

Paso 3: Entender la estructura del proyecto

Paso 4: Haz tu primer cambio

Paso 5: Leer Program.cs una vez

Problemas comunes

Próxima entrega

Blazor desde cero: Capítulo 1 — ¿Qué es Blazor?

Un poco de historia

Qué es Blazor realmente

Los modelos de renderizado

SSR estático

Servidor interactivo

WebAssembly interactivo

Modo Auto

Mezclar modos en la misma app

Cómo se compara Blazor con los frameworks de JavaScript

Qué necesitas para seguir la serie

Próxima entrega

Blazor desde cero: una nueva serie

A quién va dirigida esta serie

Qué vamos a ver

Por qué una serie, por qué ahora

Cómo seguir la serie

Tipos de sindicatos de C#: los sindicatos discriminados finalmente están llegando

¿Qué son los sindicatos discriminados?

Cómo simulamos los sindicatos hoy

Registros abstractos con herencia

Enumeración manual + patrón de datos

La propuesta de C#: la palabra clave union

Miembros de valor exclusivo

Uniones genéricas

Uniones con métodos

Coincidencia de patrones anidados

Cláusulas de protección

Ejemplos prácticos

El patrón de resultados: reemplazar excepciones por errores esperados

Modelado de dominio: tipos de pago

Máquinas de estados

Consideraciones de serialización e interoperabilidadUna de las preguntas prácticas que surge inmediatamente con los tipos de sindicatos es: ¿cómo se serializan? Si está creando API o almacenando datos, necesita la serialización JSON para funcionar correctamente.

Cómo probarlo

Comparación con enfoques existentes

Qué significa esto para el ecosistema .NET

Conclusión

Construyendo un sistema RAG en C# con Semantic Kernel

Introducción

Cómo funciona RAG

Requisitos previos

Configurando el kernel

Definiendo el modelo de datos

Dividir documentos

Ingesta de documentos

Buscando fragmentos relevantes

Generando respuestas con contexto

Utilizándolo

Pasando a producción

Creación de flujos de trabajo de agentes con Microsoft Agent Framework

Introducción

¿Qué son los flujos de trabajo de los agentes?

Requisitos previos

Construyendo un flujo de trabajo secuencial

Definiendo los agentes

Ejecutando secuencialmente

Ejecución paralela

Ramificación condicional

Agregar complementos a los agentes de flujo de trabajo

Manejo de errores en flujos de trabajo

Mejores prácticas

Paso 3: Usa `RenderFragment` para composición de layout

La propuesta de C#: la palabra clave `union`