Saltar al contenido

Artículos, tutoriales, trucos, curiosidades, reflexiones y links sobre programación web ASP.NET Core, MVC, Blazor, SignalR, Entity Framework, C#, Azure, Javascript... y lo que venga ;)

17 años online

el blog de José M. Aguilar

Inicio El autor Contactar

Artículos, tutoriales, trucos, curiosidades, reflexiones y links sobre programación web
ASP.NET Core, MVC, Blazor, SignalR, Entity Framework, C#, Azure, Javascript...

¡Microsoft MVP!
Mostrando entradas con la etiqueta middlewares. Mostrar todas las entradas
Mostrando entradas con la etiqueta middlewares. Mostrar todas las entradas
martes, 25 de enero de 2022
ASP.NET Core

El middleware de gestión de errores DeveloperExceptionPageMiddleware ha estado con nosotros desde la llegada de .NET Core, allá por 2016, ayudándonos a mostrar información detallada de las excepciones producidas en tiempo de ejecución mientras estábamos desarrollando. De hecho, era frecuente encontrar un código como el siguiente en las clases Startup de las aplicaciones ASP.NET Core, pues se incluía por defecto en todas las plantillas de proyecto de este tipo:

...
public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    if (env.IsDevelopment())
    {
        app.UseDeveloperExceptionPage();
    }
    ... // Otros middlewares
}

El extensor UseDeveloperExceptionPage() era el encargado de añadir el middleware DeveloperExceptionPageMiddleware al pipeline, de forma que éste podía capturar las excepciones y mostrar una página amigable y con información útil para los desarrolladores.

Sin embargo, si echamos un vistazo al código de configuración del pipeline en los proyectos ASP.NET Core 6 (que, por cierto, sabréis que ya no se encuentra en Startup.cs sino en Program.cs), vemos que ya no aparece ninguna referencia a este middleware. ¿Qué ha pasado? ¿Qué has hecho con nuestro DeveloperExceptionPage, ASP.NET Core 6?

martes, 5 de febrero de 2019
ASP.NET Core Tradicionalmente los middlewares de ASP.NET Core los hemos implementado como clases independientes más o menos con la siguiente pinta:
public class MyCustomMiddleware
{
    private readonly RequestDelegate _next;
    public MyCustomMiddleware(RequestDelegate next)
    {
        _next = next;
    }
 
    public async Task Invoke(HttpContext context)
    {
        // Hacer algo antes de pasar el control al siguiente middleware
        await _next(context); // Pasar el control al siguiente middleware
        // Hacer algo después de ejecutar el siguiente middleware
    }
}
Estas clases no heredan de ninguna otra ni implementan interfaces proporcionadas por el framework, aunque atienden a convenciones simples, como la recepción en el constructor del delegado al siguiente middleware en el pipeline, o la existencia de un método Invoke() o InvokeAsync(), que es donde introduciremos nuestra lógica, recibiendo el contexto HTTP.

La ausencia de interfaces o clases base aporta flexibilidad, pero elimina las ayudas propias del tipado fuerte y puede ser fuente de problemas si no atendemos a estas convenciones con cuidado. Es decir, si en lugar del método Invoke() por error escribimos Invke(), nada fallará en compilación. Tendremos que esperar a ejecutar la aplicación para que explote.

También es importante tener en cuenta que una clase middleware sólo es instanciada una vez, cuando la aplicación está arrancando; luego, en cada petición será ejecutado su método Invoke() sobre la misma instancia, lo que es a priori muy poco intuitivo y puede causarnos algún dolor de cabeza si no somos cuidadosos.
martes, 26 de abril de 2016
ASP.NET Core
Al hilo de lo tratado en el último post sobre la ramificación del pipeline de ASP.NET Core utilizando los extensores Map() y MapWhen(), el amigo Fernando V. dejaba una pregunta interesante en los comentarios del blog:
"[…] Igual que hemos visto cómo ramificar el pipeline, sería posible volver a unir las distintas ramas en una sola?"
Tampoco creo que sea muy habitual crear este tipo de estructuras en el pipeline, pero la verdad es que me ha parecido un reto muy interesante, lo suficiente como para dedicarle un post ;D
martes, 19 de abril de 2016
ASP.NET Core pipeline
Al representar gráficamente el pipeline de ASP.NET Core, lo habitual es hacerlo como una tubería única en las que colocamos estratégicamente los middlewares que procesarán las peticiones que entrarán por ella.

Incluso a nivel de código, la inserción de middlewares se realiza normalmente invocando métodos del tipo UseXXX() sobre la instancia de IApplicationBuilder que recibimos en el método Configure() de la clase Startup de nuestras aplicaciones ASP.NET Core.

Esto parece dar a entender que el pipeline es lineal, y que todas las peticiones serán procesadas de la misma forma y por los mismos middlewares, salvo que alguno de ellos decida cortocircuitar la petición.

Ramas en el pipeline de ASP.NET CoreSin embargo, aunque eso será lo más frecuente, no es obligatoriamente así. Ya desde los tiempos de Katana tenemos la posibilidad de dividir el pipeline en branches o ramas en función de determinados criterios, permitiéndonos crear configuraciones mucho más complejas y potentes que las que habitualmente suelen mostrarse.

Como ejemplo, en el diagrama lateral podemos observar un pipeline en cuya entrada se encuentra un middleware de gestión de errores, y que a continuación se divide en función de la ruta de la petición de entrada. Así, las peticiones cuyas rutas comiencen por "/SignalR" serán procesadas por los middlewares configurados en la rama de la izquierda; las que comiencen por "/API" serán procesadas a lo largo de la rama derecha, y el resto continuará su proceso por la rama central.

Vamos a ver cómo conseguir crear estas estructuras, pero, como siempre, tened en cuenta que estamos aún trabajando con una versión preliminar de ASP.NET Core y hay detalles que podrían cambiar en la versión definitiva.
martes, 5 de abril de 2016
ASP.NET CoreEn la primera entrega de esta serie comentamos las diferencias que encontramos entre ASP.NET 4.x y ASP.NET Core a la hora de procesar peticiones dirigidas hacia recursos estáticos de nuestro sitio web, que pasaba de ser una funcionalidad integrada en IIS a convertirse en un módulo opcional que tenemos que incluir y configurar expresamente cuando necesitemos esta característica.

Para entrar en materia, en dicho post presentamos StaticFilesMiddleware, el componente proporcionado por ASP.NET Core que, insertado convenientemente en el pipeline, es capaz de capturar las peticiones cuya ruta coincide con un recurso estático presente en el sistema de archivos y retornar su contenido al cliente.

Sin embargo, el paquete Nuget Microsoft.AspNetCore.StaticFiles contiene otros middlewares que cubren necesidades que podemos encontrar con frecuencia cuando en nuestras aplicaciones necesitemos gestionar contenidos estáticos.

Y aún a riesgo de resultar cansino, antes de continuar os recuerdo que seguimos trabajando con versiones preliminares de ASP.NET Core, por lo que todavía podrían introducirse cambios en el producto.