Pues os voy a contar una historia que me ocurrió más de una vez al comenzar a utilizar ASP.NET Core 2. Y como supongo que no seré el único, creo que puede ser interesante compartirla por aquí para evitar pérdidas de tiempo innecesarias al resto de la humanidad ;)

Resulta que varias veces he publicado un proyecto ASP.NET Core y, tras finalizar y probar un poco la aplicación, he visto que me había dejado por detrás alguna chorradilla en una vista que tenía que corregir rápidamente. En lugar de volver a publicar el proyecto completo, cuando me ocurre esto suelo a retocar la vista y actualizar sólo ese archivo en el servidor, por ejemplo desde el menú contextual del archivo en Visual Studio:



Pero en este caso, una vez finalizó la subida del archivo al servidor, pulsé F5 en el navegador para comprobar que ya estaba todo correcto y… ¡vaya, todo seguía igual que antes! No pasa nada, pensé que no había publicado bien, por lo que volví a repetir el proceso y pocos segundos después pude comprobar que los cambios seguían sin ser aplicados en el servidor. ¿Qué podía estar ocurriendo?

Ah, claro, ¡el caché! La vista era retornada por una acción MVC decorada con el filtro ResponseCache, por lo que podría ser normal que continuara llegando al navegador la versión anterior. Eliminé caché, incluso probé desde otro navegador y ¡todo seguía igual que antes!

Ya lo único que se me ocurría es que la publicación hubiera fallado por algún siniestro bug de Visual Studio que no dejara rastro en las trazas, así que decidí ignorar al intermediario. Fui directamente al servidor para editar manualmente el archivo de la vista y… maldición, ¡no la encuentro! :-/

¿Qué está ocurriendo aquí?

Es relativamente frecuente encontrar aplicaciones en las que necesitamos disponer de un proceso en background ejecutándose de forma continua. Hace poco hablábamos de IApplicationLifetime, un servicio del framework que nos permitía introducir código personalizado al iniciar y detener las aplicaciones, y probablemente habréis pensado que éste sería un buen sitio para gestionar el inicio y finalización de estas tareas en segundo plano.

Y aunque es posible, ASP.NET Core proporciona otras fórmulas más apropiadas para conseguirlo: los hosted services. Mediante este mecanismo, podemos crear servicios que serán gestionados por el host, y que serán iniciados y finalizados automáticamente junto con la aplicación.

Imaginad una aplicación ASP.NET Core MVC en la que insertamos un enlace o botón que dirige el navegador hacia la siguiente acción, que realiza una operación compleja y retorna un resultado:

public async Task<IActionResult> GetTheAnswerToLifeUniverseAndEverything()
{
    await Task.Delay(30000); // Simulando un proceso costoso...
    return Content("42!");
}

Cuando nuestros usuarios pulsen dicho botón, necesariamente habrán de esperar varios segundos para obtener una respuesta. Pero como suelen ser seres poseídos por una entidad demoníaca impacientes, lo normal es que se lancen en un feroz ataque contra el sistema, refrescando la página o pulsando repetidamente el botón de envío como si no hubiera un mañana. Todos hemos escuchado y sufrido en nuestras carnes una agresión de este tipo: “espera, esto parece que no va: click-click-click-click-click-click-click…”

Obviamente, esto no hace sino empeorar las cosas. El servidor, que ya estaba ocupado intentando responder la primera petición, no tiene ya que atender a una, sino a todas las que se han generado tras este ataque, cuando en realidad no tiene sentido: para tranquilizar al usuario basta con entregarle el resultado de una de ellas, por lo que todos los hilos sobrantes simplemente están malgastando recursos del servidor realizando operaciones para obtener resultados que nadie va a consumir.

Estaría bien poder cancelar esas peticiones largas si tenemos la seguridad de que ningún cliente está esperándolas, ¿verdad?

Al dar el salto a una nueva tecnología como ASP.NET Core, en muchas ocasiones nos encontramos con el problema de no saber cómo hacer cosas que con las tecnologías tradicionales teníamos completamente controladas. Ya hemos comentado por aquí varios casos (como el Application_Start(), los custom errors o las variables de sesión) y hemos visto cómo se mapean estas funciones al nuevo framework, pero hay muchos más.

Otro ejemplo muy habitual lo encontramos con MapPath(), un método perteneciente a la clase HttpServerUtility de ASP.NET "clásico" que utilizábamos para obtener una ruta física a partir de la ruta virtual o relativa de un recurso. Por ejemplo, en el siguiente código mostramos cómo averiguar la ruta en disco de una imagen utilizando este método:

var path = HttpContext.Current.Server.MapPath("~/images/image.jpg");
// path = C:\inetpub\wwwroot\mysite\images\image.jpg

Pues bien, ni en ASP.NET Core ni en MVC tenemos disponible la clase System.Web.HttpContext, ni por tanto una propiedad Server de tipo HttpServerUtility que usábamos para invocar al método MapPath(). Sin embargo, disponemos de herramientas alternativas que nos permiten conseguir lo mismo, aunque, eso sí, de forma algo menos directa.

En las versiones clásicas de ASP.NET, el archivo Global.asax proporcionaba vías para implementar lógica personalizada cuando la aplicación arrancaba y era detenida, lo que podía resultar bastante útil, por ejemplo, para registrar estos eventos en un log, precargar cachés, inicializar bases de datos, “engancharnos” a servicios externos, etc.

Por ejemplo, en el siguiente código vemos cómo podíamos aprovechar los eventos Application_Start() y Application_End() para guardar un registro básico de estos sucesos:

public class MvcApplication : System.Web.HttpApplication
{
    private static string _logFile;
    protected void Application_Start()
    {
        ...
        _logFile = Server.MapPath("log.txt");
        File.AppendAllText(_logFile, DateTime.Now + ": Starting\n");
    }

    protected void Application_End()
    {
        File.AppendAllText(_logFile, DateTime.Now + ": Stopping\n");
    }
}

Sabemos que en ASP.NET Core no existe Global.asax, por lo esta fórmula ya no está disponible. Sin embargo, el nuevo framework ofrece una alternativa bastante razonable mediante el interfaz IApplicationLifetime, proporcionando, entre otras cosas, vías para suscribirnos a eventos relacionados con el ciclo de vida de una aplicación.

Como ya sabréis, hace algunas semanas Microsoft anunció la disponibilidad de, entre otras tecnologías, ASP.NET Core 2.0, y me complace anunciaros que hace pocos días hemos lanzado desde CampusMVP el curso que muchos andabais esperando para dar el salto: Desarrollo Web con ASP.NET Core 2 MVC.

Se trata de una revisión del curso sobre ASP.NET Core MVC, que tan buena acogida y críticas ha tenido hasta el momento, actualizando conceptos y reflejando las novedades en APIs, funcionalidades y herramientas con las que esta segunda versión del framework promete revolucionar nuestra forma de desarrollar aplicaciones y servicios para la web.

En este post intentaremos responder a las siguientes preguntas:

• ¿En qué consiste el curso de ASP.NET Core 2 MVC?
• ¿Cuáles son los contenidos del curso?
• ¿Es este curso para mi?
• ¿Qué conocimientos previos necesito para seguir el curso?
• ¿Y qué ocurre con MVC 5 o los demás frameworks basados en ASP.NET 4.x?
• Me convence, ¿cuándo empezamos?

¿En qué consiste el curso de ASP.NET Core 2 MVC?

Se trata de un curso impartido totalmente online a través de la prestigiosa plataforma de CampusMVP, sin horarios y a tu propio ritmo. La duración del curso está estimada en 12 semanas con una dedicación media de 7 u 8 horas semanales, y durante las cuales, dado que soy el tutor, contarás con mi asistencia para resolver tus dudas y ayudarte a lo largo de tu proceso de aprendizaje.

El temario consta de más de 150 temas que recorren exhaustivamente el framework ASP.NET Core 2.0 MVC desde su base, y que podrás descargar en formato PDF (más de 400 páginas) para utilizarlo como referencia al finalizar el curso. Además del contenido teórico, el curso está salpicado por numerosos ejercicios y prácticas propuestas que te ayudarán a asimilar mejor los conceptos principales, autoevaluaciones, recursos adicionales, aplicaciones de ejemplo, consejos y buenas prácticas, y más de tres horas de vídeo para ver en vivo el funcionamiento de algunas características.

Al finalizar el curso obtendrás un diploma que te permitirá acreditar su realización, así como incluirlo en tu perfil certificado de CampusMVP, un perfil online verificable por terceros donde puedes demostrar qué has aprendido con nosotros.

¿Cuáles son los contenidos del curso?

El curso realiza un recorrido completo por ASP.NET Core MVC partiendo desde cero. Y no podemos decir que nos andemos mucho por las ramas… Tras una breve bienvenida, empezamos presentando ASP.NET Core, describiendo su estructura, arquitectura y principios básicos de funcionamiento, y pasaremos rápidamente a la acción.

Veremos cómo se crean y configuran estos proyectos, y cómo utilizar su estructura modular para añadir componentes que aportarán funcionalidades a nuestras aplicaciones. Revisaremos muchas características que esta infraestructura proporciona a los frameworks de mayor abstracción como MVC: logging, caching, sessions, settings de aplicación, archivos estáticos, autenticación, etc.

Tras ello, nos tomaremos un pequeño respiro para presentar ASP.NET Core MVC, y volveremos al frente de batalla haciendo una pequeña incursión en el desarrollo con este framework. El objetivo en este punto es proporcionar una visión de alto nivel del funcionamiento de este tipo de aplicaciones que, sin entrar en demasiados detalles, nos permitan comprender sus principales “piezas” (modelo, vistas, controladores) y la forma de trabajar con ellas.

A continuación, recorreremos sucesivamente las capas Modelo, Controlador y Vista, detallando al máximo cómo trabajar con las herramientas que nos proporciona el framework MVC para la creación de aplicaciones web. Estudiaremos en profundidad aspectos como el sistema de routing, binders, validaciones, Razor, helpers, view components, buenas prácticas, uso de patrones…

También tendremos tiempo para profundizar en el desarrollo de servicios o APIs HTTP/REST, consumibles tanto desde aplicaciones web vía Ajax como desde sistemas externos, utilizando para ello las nuevas y potentes características de negociación de contenidos y binding selectivo.

Por último, tras ver algunos otros aspectos como el uso de áreas, Razor Pages, la creación de tests o la internacionalización de aplicaciones  presentaremos BlogMachineCore, una la aplicación de ejemplo en la que podrás ver implementadas muchas características vistas en el curso, cuyos detalles puedes leer en este artículo de CampusMVP: arquitectura desacoplada, inyección de dependencias, uso de DTOs, autenticación y autorización, áreas, asincronía, URL amigables, tag helpers, Ajax, páginas de error personalizadas, etc.

Se trata de un completo temario en el que hemos intentado no dejar nada por detrás. El objetivo es que al finalizar el curso estés en disposición de utilizar ASP.NET Core MVC en tus proyectos profesionales y dar el salto definitivo a las tecnologías “Core”.

Para saber más, puedes ver la ficha completa del curso en la web de CampusMVP.

¿Es este curso para mí?

Como seguro sabrás, ASP.NET Core MVC no es la siguiente versión del framework ASP.NET MVC. Se trata de un reboot en toda regla de la tecnología, que de hecho empezó nuevo desde su versión 1.0 con la intención de convertirse en el mejor framework para el desarrollo de aplicaciones y servicios web, aportando importantes características, algunas de ellas impensables hace sólo unos meses en la pila de tecnologías de Microsoft, como el ser multiplataforma, alto rendimiento, escalabilidad, orientación a la nube, libertad de herramientas de desarrollo, etc.

La oleada de tecnologías "Core" es probablemente el cambio más drástico que hemos sufrido los desarrolladores ASP.NET desde sus inicios, allá por el año 2002.

Pero claro, para conseguirlo han tenido que romper muchas cosas, comenzando por las bases. El nuevo framework MVC corre sobre la nueva infraestructura ASP.NET Core que, de la misma forma, ha sido reescrita desde cero y replanteada para dar cabida a los nuevos requisitos.

Por tanto, si vienes de trabajar con frameworks basados en versiones de ASP.NET iguales o anteriores a 4.x, para saltar a ASP.NET Core tendrás que olvidar muchas de las cosas que ya sabes y aprender a manejar la nueva infraestructura, que ha cambiado radicalmente. Una vez teniendo controlados los cimientos, ya podrás pasar a aprender tecnologías con un nivel de abstracción superior, como el proporcionado por el nuevo framework MVC.

En MVC, a primera vista parece que han cambiado menos cosas, puesto que conceptualmente siguen manteniéndose aspectos que ya se han demostrado válidos en las versiones anteriores del framework. Seguiremos teniendo componentes como controladores, acciones, binding o filtros y continuaremos usando sintaxis Razor para escribir las vistas, pero la práctica totalidad de características ha sufrido cambios.

Aparte, hay novedades muy interesantes como view componentes o tag helpers, el nuevo enfoque para desarrollar APIs HTTP, o las derivadas de la adopción de ASP.NET Core, como el uso de variables de sesión, inyección de dependencias, la autorización o internacionalización, por citar sólo algunas.

Todos estos cambios son los que hacen que este curso sea especialmente interesante, puesto que te permitirá aprender todo lo necesario para dominar primero la nueva plataforma ASP.NET Core, y luego el framework MVC, de forma estructurada y partiendo desde cero. Por tanto, resumidamente;

• Primero, independientemente de las tecnologías con las que hayas trabajado anteriormente, en el curso aprenderás a manejar con solvencia la nueva infraestructura ASP.NET Core.
• Y después, dependiendo de tu punto de partida:
• Si no has trabajado antes con MVC, aprenderás desde cero a construir aplicaciones basadas en el framework MVC sobre la infraestructura ASP.NET Core
• Si has trabajado antes con MVC <=5, aunque te sonarán muchos conceptos, el curso también te será útil porque aprenderás:
• Los cambios en características que ya conocías.
• Cómo afecta la introducción de ASP.NET Core al desarrollo de aplicaciones con el framework MVC.
• Y todas las novedades específicas del framework MVC, que no son pocas.
• Si ya conoces algo de ASP.NET Core pero lo has aprendido “de oídas” o de forma desestructurada, quizás el curso también podría resultarte interesante porque te ofrecerá una visión ordenada y profunda de esta tecnología.

En cambio, si ya hiciste el curso de ASP.NET Core 1.x con nosotros, probablemente no te valga la pena, pues aunque hay bastantes cambios, no son realmente rompedores. En este artículo de la documentación oficial puedes leer algo sobre ellos, y ver el detalle completo en Github.

¿Qué conocimientos previos necesito para seguir el curso?

Obviamente, al tratarse de un curso sobre una tecnología web, lo primero que necesitarás conocer, al menos a un nivel básico, es HTML, CSS y Javascript.

También es importante comprender las bases del funcionamiento de las aplicaciones web, es decir, saber identificar cliente y servidor, entender las responsabilidades de cada uno de estos extremos y conocer mínimamente los mecanismos de comunicación entre ellos, básicamente el protocolo HTTP. Si has trabajado antes con alguna tecnología de desarrollo para la web (ASP, ASP.NET Web Forms, MVC, PHP, Express…), probablemente ya conozcas todo lo necesario de estos aspectos.

También debes tener un cierto nivel de programación con .NET y C#. Por ejemplo, en el curso no vamos a explicar conceptos básicos como qué es una clase o una interfaz, ni otros aspectos del lenguaje como expresiones lambda, métodos extensores, tipos anulables, o tipos genéricos; se supone que todo eso debes conocerlo ya. Tampoco explicaremos qué es un List<T> o un StringBuilder, son piezas del framework con las que ya debes haber trabajado antes.

Aunque no es absolutamente imprescindible para completar el curso, sí que es totalmente recomendable conocer tecnologías de acceso a datos, pues para construir aplicaciones web que jueguen con datos seguro que vas a necesitarlas. A lo largo del temario veremos algunos ejemplos de uso de Entity Framework Core, pero no profundizaremos en ellos al escapar del objetivo del curso.

Por último, indicar que el curso comienza de cero en lo relativo al framework ASP.NET Core y MVC, por lo que en ningún momento se asume que tienes conocimientos en versiones anteriores de ASP.NET, ASP.NET Core u otras tecnologías concretas de desarrollo de aplicaciones web. Sin embargo, si las conoces tendrás algo de ventaja porque podrás "mapear" mentalmente algunos conceptos al nuevo framework y te costará mucho menos trabajo aprenderlos.

¿Y qué ocurre con MVC 5 y los demás frameworks basados en ASP.NET 4.x?

ASP.NET 4.x y los frameworks que descansan sobre él, como Web Forms, MVC, Web API o SignalR, continuarán siendo soportados e incluso podrán ser evolucionados ligeramente, por lo que su vida previsiblemente aún será larga. Hay muchas aplicaciones creadas con estos marcos de trabajo que durante mucho tiempo necesitarán mejoras, ampliaciones o mantenimiento, por lo que siguen siendo opciones razonables a día de hoy e incluso en determinados escenarios pueden ser idóneos para aplicaciones nuevas.

Oficialmente, Microsoft recomienda seguir utilizando tecnologías basadas en ASP.NET 4.x para aplicaciones existentes y ASP.NET Core 2.0 para aplicaciones nuevas.

Sin embargo, muy probablemente no veremos nunca nuevos productos versionados como ASP.NET 5, MVC 6 o Web API 3, puesto que la apuesta de Microsoft está principalmente centrada en la familia tecnológica "Core": .NET Core, ASP.NET Core, ASP.NET Core MVC y otros frameworks que irán apareciendo. Por tanto, la adopción de estas nuevas tecnologías de forma global es sólo cuestión de tiempo.

Y ya, sé que no es muy científico ni tiene validez para probar gran cosa, pero ahí os dejo una consulta rápida a Google Trends sobre las tendencias actuales de búsqueda sobre distintos "sabores" de ASP.NET, que os puede dar una idea del interés que está despertando el nuevo framework y por dónde pueden ir los tiros en el futuro:

Si por cualquier motivo debes aprender ASP.NET MVC 5, recuerda que en CampusMVP también tenemos un curso apropiado para tí ;) Pero recuerda que sólo una parte de los conocimientos que adquieras serán válidos cuando saltes a ASP.NET Core MVC más adelante.

Me convence, ¿cuándo empezamos?

Pues cuando tú quieras :) Sólo tienes que visitar la web de CampusMVP, inscribirte, y casi sobre la marcha te facilitarán las credenciales de acceso a la plataforma.

Y bueno, pues creo que con esto quedarán despejadas todas vuestras dudas sobre el curso, o al menos muchas de ellas. Si no es así, no dudéis en contactar con CampusMVP, donde seguro os atenderán de maravilla, o conmigo a través de un comentario, correo electrónico, o el formulario de contacto del blog.

¡Espero veros a muchos por allí!

Publicado en Variable not found.

A la hora de iniciar un nuevo proyecto ASP.NET Core, una de las primeras decisiones que debemos tomar es si el target de éste será .NET Core o .NET Framework.

Muchas veces esto dependerá de los requisitos y el entorno del proyecto; por ejemplo, si nos interesa la capacidad para ejecutarlo o desarrollarlo sobre entornos Linux o Mac, nos tendremos que decantar por .NET Core, pues el framework completo sólo está disponible para Windows. También podemos encontrarnos con que necesitamos (re)utilizar componentes o bibliotecas que aún no han sido portadas a .NET Core, por lo que en este caso el target será .NET Framework (bueno, esto cambiará bastante con la llegada de Net Standard 2.0, pero de momento es lo que hay).

En cualquier caso, la decisión la tomamos justo en el momento de crear el proyecto en Visual Studio, al seleccionar la plantilla que usaremos como base:



Sin embargo, conforme el proyecto avanza, puede que esta decisión que tomamos tan al principio no sea del todo válida: quizás en su momento elegimos .NET Core, pero ahora debemos cambiar a .NET Framework. O al contrario, porque ahora necesitamos que nuestra aplicación sea multiplataforma. O tal vez necesitemos las dos cosas al mismo tiempo por si acaso…

Nota: aunque aún pululan por ahí aplicaciones creadas con versiones preliminares del SDK, basadas en el difunto project.json, aquí utilizaremos la versión 1.0 del SDK, que ya utiliza el nuevo .csproj. Si todavía no has migrado, ya estás tardando ;)

El sistema de inyección de dependencias de ASP.NET Core es un potente mecanismo que viene de serie en el framework y, que de hecho, es uno de los principales pilares en los que se basa su funcionamiento.

Probablemente sabréis (y si no, podéis echar un vistazo a este post) que existen diversas fórmulas para añadir servicios o componentes al contenedor de dependencias, y una de ellas es la denominada "Scoped". Estos componentes quedan registrados asociados a un ciclo de vida específico (ServiceLifetime.Scoped), que indica que cada vez que haya que se solicite un objeto de este tipo se retornará la misma instancia dentro el ámbito actual, que normalmente coincide con el proceso de una petición específica.

O en otras palabras, dentro de la misma petición, la instancia del componente será compartida por todos los objetos que dependan de él. Además, al finalizar el proceso de la petición, el framework invocará su método Dispose() (si existe, claro), permitiendo liberar los recursos que haya utilizado. Por ejemplo, suele ser una buena práctica emplear esta técnica para reutilizar un contexto de datos entre los servicios que participan en el proceso de una petición que accede a una base de datos, y asegurar su liberación final para no dejar conexiones abiertas.

Pero este post no va de ver cómo registrar estos componentes o de cómo utilizarlos en nuestras aplicaciones, sino de responder una simple curiosidad: ¿quién se encarga de crear este scope cuando comienza una petición y de liberarlo cuando finaliza? Ya, sé que no tiene mucha utilidad práctica en el día a día, pero es una buena excusa para echar un vistazo y entender cómo funcionan las cosas por dentro ;)

<Disclaimer>Todo lo que comentaremos a continuación son detalles de la implementación actual del framework y son válidos en la versión 1.1 de ASP.NET Core, pero podrían cambiar en futuras versiones.</Disclaimer>

Hace algunos meses comentábamos por aquí cómo en ASP.NET Core es posible modificar los archivos de configuración de una aplicación en caliente, sin necesidad de detenerla, siendo los cambios aplicados de forma inmediata.

En aquél momento ya vimos que era realmente sencillo conseguirlo cuando usábamos settings no tipados, bastaba con añadir el parámetro reloadOnChanges a la hora de añadir el origen de configuración, como en el siguiente ejemplo:

public Startup(IHostingEnvironment env)
{
    var builder = new ConfigurationBuilder()
        .SetBasePath(env.ContentRootPath)
        .AddJsonFile("appsettings.json", optional: true, reloadOnChange: true)
        .AddJsonFile($"appsettings.{env.EnvironmentName}.json", optional: true)
        .AddEnvironmentVariables();
    Configuration = builder.Build();
}

Sin embargo, también vimos que conseguir lo mismo cuando queríamos acceder a los settings de forma tipada era algo más engorroso, puesto que había que configurar manualmente el proceso de recarga y bindeado de datos con la instancia de la clase de configuración, para poder acceder luego a ella a través de un objeto IOptions<T> disponible en el contenedor de dependencias.

Probablemente muchos recordaréis que cuando comenzaron a verse las primeras previews de ASP.NET Core, por entonces aún llamado ASP.NET vNext, una de las novedades más sorprendentes que pudimos descubrir fue la aparición de un nuevo archivo de proyecto, llamado project.json, que sustituiría al vetusto .csproj (o vbproj).

La comunidad se entusiasmó bastante con la idea porque el nuevo archivo de proyecto era bastante más simple y liviano que el tradicional .csproj, daría menos problemas con los sistemas de control de código fuente, era fácil de leer y de editar sin necesidad de disponer de Visual Studio o un IDE completo, y por tanto era muy portable entre plataformas. Y encima usaba el formato JSON, que sin duda resultaba mucho más cool que XML. ¿Qué más podíamos pedir?

Antes de continuar, permitidme un inciso: aunque conceptualmente todo lo que vamos a contar es cierto en este momento (enero/2017) y probablemente seguirá siéndolo, el tooling aún está en desarrollo y, por tanto, algunos detalles todavía podrían cambiar.

Comprimir el resultado de la ejecución de una acción puede ser una buena idea para acelerar la descarga y evitar un consumo innecesario de datos, y sobre todo en acciones donde se retorne una cantidad importante de información potencialmente comprimible, como texto plano, JSON o marcado HTML.

Aunque esta tarea es algo que pueden (y suelen) realizar servidores frontales como IIS o Apache, a veces puede ser interesante que sea nuestra aplicación la que se encargue de ello, por ejemplo si estamos ofreciendo servicios directamente desde los servidores Kestrel o WebListener, o si deseamos aplicar algún tipo de compresión personalizada.

Conceptualmente, la tarea de compresión del resultado de una acción es una buena candidata para ser implementada como filtro. Los filtros son capaces de tomar el control antes y después de la ejecución de las acciones, por lo que, al menos en teoría, serían un buen lugar para implementar la lógica de compresión y retorno al cliente de los resultados, y su uso tendría la siguiente pinta:

public class HomeController : Controller
{
    [Compress]
    public IActionResult Test()
    {
        var text = new string('x', 1000000);
        return Content(text);
    }
}

En este post vamos a ver cómo implementar ese filtro [Compress]. Y bueno, aunque implementarlo a mano y desde cero podría tener su gracia, lo que vamos a hacer es aprovechar dos de las últimas e interesantes novedades introducidas recientemente en ASP.NET Core 1.1: el middleware de compresión y la capacidad de utilizar middlewares como filtros de MVC.

Como vimos hace algún tiempo, ASP.NET Core viene equipado de serie con una potente infraestructura de logging que ofrece una fórmula sencilla para registrar trazas de lo que va ocurriendo en nuestra aplicación en tiempo de ejecución.

A la hora de registrar las trazas es posible indicar uno de los niveles definidos en la enumeración LogLevel, cuyos miembros son Trace, Debug, Information, Warning, Error y Critical. Estos miembros definen jerárquicamente la "importancia" de los acontecimientos que registramos, de forma que luego podemos configurar los proveedores para que sólo muestren o persistan mensajes a partir de un nivel determinado.

Como sabéis, hace unos días se presento en el evento Connect() la primera revisión de ASP.NET Core, versionada como 1.1.0.

A continuación desgranaremos un poco qué se incluye en esta entrega, pero gracias al uso de versionado semántico, sin entrar en más detalles ya podemos saber que esta nueva versión añade características adicionales y mejoras compatibles hacia atrás, por lo que no tendríamos que preocuparnos por romper algo si actualizamos a ella (¡al menos en teoría, claro! ;)).

En ASP.NET Core, sabemos que la clase Startup es donde introducimos el código de inicialización de nuestras aplicaciones. En sus métodos Configure() y ConfigureServices() encontraremos aspectos de todo tipo, como los siguientes, por citar sólo algunos:

• La configuración del sistema de settings
• Definición de destinos de logs y niveles de trazas
• Configuración de componentes de tratamiento de errores y sistemas de depuración y profiling adicionales
• Configuración de servicios como caching o estado de sesión
• Inserción y configuración de servicios y middlewares del framework, como los destinados al proceso de contenidos estáticos, internacionalización, CORS, u otros
• Middlewares personalizados
• Registro de servicios en el sistema de inyección de dependencias
• Inicializaciones específicas de la aplicación, como seeds de bases de datos o configuración de mapeos entre objetos
• Configuración de rutas de la aplicación
• …

Y todo esto, además, salpicado por la lógica para distinguir entre los distintos tipos de entorno de ejecución (development, staging…), o incluso condicionales basados en el contenido de archivos de configuración.

En más de una ocasión me he topado con artículos que sugerían que ASP.NET Core MVC es un middleware y de hecho, incluso en algunos momentos yo también he tenido la sensación de que podía serlo.

Sin embargo, y esta es la respuesta corta si quieres ahorrar tiempo de lectura, estrictamente hablando no lo es.

Continuamos lamiéndonos las heridas provocadas por los sucesivos terremotos que han supuesto las prereleases y releases públicas de ASP.NET Core, con objeto de ponernos al día en los cambios y novedades que vamos encontrando.

Hoy vamos a hablar de las variables de sesión, un tema que ya tratamos por aquí hace bastante tiempo, pero que conforme evolucionaba el producto ha cambiado lo suficiente como para dedicarle un nuevo post.

Cuando ASP.NET “clásico” modificábamos algún setting de la aplicación almacenado en el archivo web.config, esto traía como consecuencia directa el reciclado del pool, o en otras palabras, la aplicación se reiniciaba irremediablemente para recargar los nuevos valores de configuración.

Pero como sabemos, en ASP.NET Core el sistema de configuración ha cambiado para mejor, y ahora los settings podemos almacenarlos en archivos JSON independientes del resto de configuraciones del proyecto, así como en otros formatos y ubicaciones. Y ya que se ponían con el tema, el equipo de ASP.NET ha aprovechado para hacer que podamos modificar los settings sobre los archivos de configuración y que éstos sean aplicados sobre la marcha, sin necesidad  de volver a arrancar la aplicación.

¡Por fin! Tras un desarrollo muy largo y convulso, ayer se presentaron las respectivas versiones 1.0 RTM de .NET Core, ASP.NET Core y Entity Framework Core, junto con actualizaciones de una serie de productos relacionados.

La verdad es que hace tan sólo unos años, presentar la nueva versión de ASP.NET en la conferencia Red Hat DevNation habría resultado una auténtica osadía y probablemente habría acabado con tomates volando hacia el escenario. Pero esto es agua pasada, y este simple gesto es una prueba más de que realmente las cosas han cambiado en Microsoft.

Con el lanzamiento de la versión 1.0 de la infraestructura .NET Core y el conjunto de frameworks basados en ella (ASP.NET, MVC, Entity Framework), iniciamos una nueva época en la que aquél sueño de desarrollar o ejecutar fácilmente aplicaciones .NET en cualquier plataforma es ya una realidad, y con todo el soporte y las bendiciones del gigante de Redmond. Escenarios antes impensables, como desarrollar desde Mac para desplegar en Linux, o crear nuestras aplicaciones en Windows y explotarlas desde un contenedor Docker, son ya posibles.

Estamos ante un reboot en toda regla: todos estos frameworks han sido construidos desde cero teniendo en mente conceptos actuales que ni siquiera existían cuando empezaron a gestarse las versiones iniciales de .NET o ASP.NET "clásicos": la nube, alto rendimiento, escalabilidad, APIs, múltiples dispositivos y plataformas, contenedores, microservicios etc. Y creados usando principios y buenas prácticas que tampoco eran los habituales antaño: inyección de dependencias, clases con responsabilidades limitadas, modularidad, componibilidad, abstracciones basadas en interfaces, pruebas unitarias…

Conforme el desarrollo del nuevo framework ha ido avanzando, se han producido bastantes cambios en el sistema de hosting, que es, al fin y al cabo, quien determina la forma en que podemos cambiarle el nombre a "wwwroot". En el pasado hemos publicado varios posts al respecto (aquí y aquí), y ahora vamos a actualizar los conocimientos tras los cambios aparecidos en la RC2 (sí, esa en la que en teoría no iba a cambiar demasiado respecto a la RC1 ;D).

Como sabemos, en proyectos ASP.NET Core, la carpeta "wwwroot", también conocida como "Web root", ejerce como raíz para los contenidos estáticos de la web, es decir, es donde encontraremos todos los archivos que en algún momento enviaremos al lado cliente: javascript, CSS, favicons, imágenes, fonts, etc.

El nombre que se ha dado a la carpeta, "wwwroot", es por convención, y simplemente se trata del valor por defecto establecido por el framework, pero si no nos convence podemos cambiarlo por otro que nos parezca más conveniente. No es que vaya va a ser muy frecuente hacerlo en aplicaciones del mundo real, pero saber que se puede cambiar y cómo hacerlo es interesante porque, además de darnos la libertad de elegir, nos obliga a aprender un poco sobre las interioridades del framework.

Así, si deseamos cambiar el nombre de "wwwoot" por cualquier otro, los pasos serían básicamente tres:

• Renombrar la carpeta a nivel físico desde el IDE o desde el explorador de archivos.
   
• Cambiar la configuración de preprocesadores como Gulp, Grunt o WebPack para que utilicen vuestra nueva carpeta como directorio de salida, lo que podemos hacer fácilmente editando sus correspondientes archivos de configuración gulpfile.js, grunt.config, webpack.config.js o el que sea.
   
• Informar al framework de que esa nueva carpeta es la base para los recursos estáticos, lo que permitirá a otros componentes (por ejemplo, los middlewares encargados de retornar este tipo de contenidos) saber dónde se encuentran los archivos.

En este último punto es donde nos centraremos en el resto del post, viendo algunas fórmulas para conseguirlo.

Este post es una reedición de un contenido anterior para actualizarlo a la Release Candidate 2 de ASP.NET Core. ¡A ver si se calma todo un poco y conseguimos que los contenidos valgan más de un par de meses! ;D

Uno de los requisitos más habituales que tenemos en cualquier aplicación medianamente compleja es la creación de logs donde guardar información cuando ocurran determinados eventos.

En ASP.NET "clásico" teníamos varias opciones, como utilizar las propias herramientas de tracing del marco de trabajo, o bien frameworks especializados de terceros como los célebres Log4Net, NLog o muchos otros, pero al final la idea era la misma, poder disponer de un componente en el que poder registrar sucesos como el siguiente:

public ActionResult RemoveInvoice(string id)
{
    ... // Remove the invoice  
    _logger.LogInformation($"Invoice {id} was removed by {User.Identity?.Name}");
    return RedirectToAction("Index");
}

El nuevo ASP.NET Core viene equipado de serie con un sistema de logging interno, integrado en el propio marco de trabajo, que proporciona algunas funcionalidades pero, sobre todo, los mimbres básicos sobre los que montar sistemas de trazas más complejos y personalizables.

Dedicaremos este post a ver cómo se configura y utiliza este mecanismo que, como otros aspectos del framework, está construido pensando en su extensibilidad y hace uso intensivo del sistema de inyección de dependencias.

Nota: aunque la RTM se acerca, sigue siendo bueno recordar que todavía estamos utilizando una release candidate de ASP.NET Core y, por tanto, algunos detalles aún podrían variar antes de que aparezca la versión final del producto.