Mostrando entradas con la etiqueta aspnetcore. Mostrar todas las entradas
Mostrando entradas con la etiqueta aspnetcore. Mostrar todas las entradas
martes, 14 de marzo de 2017
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>
martes, 14 de febrero de 2017
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.
martes, 24 de enero de 2017
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.
martes, 20 de diciembre de 2016
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.
martes, 29 de noviembre de 2016
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.
martes, 22 de noviembre de 2016
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! ;)).
martes, 4 de octubre de 2016
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
- …
martes, 27 de septiembre de 2016
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.
martes, 19 de julio de 2016
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.
martes, 12 de julio de 2016
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.
martes, 28 de junio de 2016
¡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…
miércoles, 22 de junio de 2016
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.
miércoles, 15 de junio de 2016
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! ;DUno 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.
miércoles, 8 de junio de 2016
Uno de los cambios que ha introducido ASP.NET Core RC2 respecto a la anterior Release Candidate es que dejaremos de utilizar HttpPlatformHandler para redirigir las peticiones desde IIS hacia Kestrel que, como sabemos, es finalmente el que ejecuta nuestra aplicación.El problema es que este componente era un redirector genérico, no ligado a ninguna tecnología concreta, lo que impedía el uso de algunas características interesantes o necesarias para la correcta ejecución de ASP.NET Core en todos los entornos, como el soporte para directorios virtuales de IIS o el reenvío de certificados de cliente.
miércoles, 1 de junio de 2016
Va un post rapidito, sólo para informar de un pequeño cambio que ha introducido ASP.NET Core RC2, recientemente lanzado, relativo al nombrado de variables de entorno de sistema operativo.Desde RC2, los nombres de las variables de entorno de sistema operativo que permiten configurar ciertos aspectos, como definir si el entorno de ejecución es "Development" o "Production" usan ahora el prefijo "ASPNETCORE_":
No es la primera vez que cambia, de hecho creo recordar tres o cuatro prefijos diferentes a lo largo de la vida del producto desde sus primeras betas, así que espero que esta sea la definitiva :)
Publicado en Variable not found.
martes, 24 de mayo de 2016
Como sabéis, hace unos días se lanzaron las respectivas versiones Release Candidate 2 de .NET Core y los frameworks ASP.NET Core y EF Core.Los detalles ya los comentamos en un post anterior, ahora vamos a centrarnos en ver algunos cambios importantes que llaman la atención cuando empezamos a jugar con esta nueva entrega de ASP.NET Core.
martes, 17 de mayo de 2016
Como adelantábamos hace unos días, ya tenemos entre nosotros la segunda Release Candidate de .NET Core y los frameworks ASP.NET Core y EF Core, versiones que llegan con bastante retraso sobre lo previsto pero con la intención de ser una propuesta sólida y casi definitiva antes de lanzarse las versiones finales a finales del próximo mes de junio. Esta release viene cargada de novedades, comenzando por ser la primera en alinearse con el nombre "core" en los frameworks anunciado hace algunos meses, la migración desde DNX al nuevo .NET CLI (interfaz de línea de comandos de .NET), revisión profunda del modelo de hosting y arranque de aplicaciones, muchos cambios en los API (sí, no debería haber pasado desde la RC1, pero pasó...), mejoras espectaculares en rendimiento, centenares de bugs corregidos, etc.
lunes, 9 de mayo de 2016
Hace un par de días, Scott Hunter, Program Manager de .NET en Microsoft, desvelaba las fechas de aparición y otros detalles sobre las próximas releases de ASP.NET Core, de las que no teníamos noticias desde el pasado mes de febrero, momento en que decidieron retrasar los lanzamientos previstos.
Veamos cómo queda ahora la cosa.
miércoles, 4 de mayo de 2016
Nota: existe una actualización de este post a la RC2 de ASP.NET Core. Mejor que leas esa ;)
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 framework o 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 funcionalidades básicas 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 este componente no es un gran candidato a cambiar dada las pocas actualizaciones que ha sufrido en los últimos meses, es 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.
martes, 26 de abril de 2016
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
