Mostrando entradas con la etiqueta netcore. Mostrar todas las entradas
Mostrando entradas con la etiqueta netcore. Mostrar todas las entradas
martes, 22 de mayo de 2018
Recordaréis que hace un par de semanas iniciamos un pequeño viaje en el que nuestro objetivo era renderizar una vista Razor de forma totalmente manual, desde procesos externos a ASP.NET Core y, por supuesto, introduciendo el menor número posible de dependencias hacia este framework. Ya comentamos entonces que este proceso consistía básicamente en:- Procesar la plantilla CSHTML y obtener código C# que permita renderizarla.
- A continuación, compilar dicho código para obtener un componente ejecutable.
- Por último, ejecutar el código para renderizar la plantilla.
¡Seguimos! ;)
martes, 8 de mayo de 2018
Hace poco un alumno de mi curso de ASP.NET Core MVC en CampusMVP me preguntaba sobre las posibilidades de utilizar Razor desde una aplicación de consola con el fin de aprovechar dicha sintaxis a la hora de componer emails. Ya en un artículo anterior vimos cómo podíamos conseguirlo desde una aplicación ASP.NET Core MVC, pero en este caso lo que vamos a ver es cómo conseguirlo desde fuera de ASP.NET Core, es decir, desde una aplicación de consola pura sin apenas dependencias a dicho framework.El problema que tiene intentar usar Razor de esta forma es que estamos muy malacostumbrados ;) ASP.NET Core hace mucho trabajo por nosotros y puede hacernos ver que renderizar una vista es algo trivial, pero no lo es; la vista debe ser parseada para obtener de ella un código C# que más adelante será compilado al vuelo para generar un ensamblado que será anexado a nuestra aplicación de forma dinámica y que será utilizado en cada renderización. Y todo ello, de forma rápida y eficiente en recursos.
La renderización de una vista Razor desde una aplicación de consola “pura” consiste en seguir estos mismos pasos, pero de forma manual. Lo que veremos a lo largo de un par de posts es:
- Cómo generar código C# parseando una plantilla Razor, es decir, un archivo
.cshtml. - Cómo compilar el código C# obtenido y generar un ensamblado con Roslyn.
- Cómo cargar dinámicamente dicho ensamblado en memoria.
- Cómo ejecutar una vista presente en dicho ensamblado y obtener el resultado.
Nota: el objetivo de estos posts es puramente didáctico, y su única intención es aprender algo sobre las tripas de ASP.NET Core. No nos meteremos en optimizar estas operaciones o introducir mejoras como cacheado o similares, ni en ofrecer una solución funcionalmente completa. Por tanto, lo que veremos aquí no será production ready, pero sí un buen punto de partida para que podáis crear vuestras propias soluciones.
martes, 6 de febrero de 2018
Todos tenemos bibliotecas o componentes escritos para .NET Framework que nos gustaría portar de alguna forma a .NET Core para poder utilizarlos en nuevos proyectos, o, al menos, saber si esto sería posible en un futuro.Aunque de forma intuitiva muchas veces tenemos la respuesta (sobre todo cuando ésta es un rotundo “no” ;D), sin duda es interesante disponer de información objetiva que indique cómo de lejos estamos de conseguirlo y cuáles son los principales impedimentos.
miércoles, 3 de mayo de 2017
Los que llevamos tiempo trabajando con paquetes NuGet, sabemos que la desinstalación de paquetes requería tradicionalmente entrar en la consola del gestor de paquetes, o bien usar el interfaz gráfico de este gestor de paquetes en Visual Studio, lo que era bastante lento y farragoso.
Y claro, como los humanos somos animales de costumbre, lo normal es que cuando damos el salto a ASP.NET Core continuemos haciéndolo de la misma forma, sin pararnos un segundo a replantearnos si hay mejores formas… lo que me recuerda a esta famosa imagen que anda por Internet desde hace bastante tiempo:
(Fuente: Ni idea)
Y claro, como los humanos somos animales de costumbre, lo normal es que cuando damos el salto a ASP.NET Core continuemos haciéndolo de la misma forma, sin pararnos un segundo a replantearnos si hay mejores formas… lo que me recuerda a esta famosa imagen que anda por Internet desde hace bastante tiempo:
(Fuente: Ni idea)
martes, 31 de enero de 2017
Hace unos días hablábamos de que próximamente veremos cambios en los archivos de proyecto de las aplicaciones .NET Core, que dejarán de utilizar el popular project.json para volver al tradicional .csproj, aunque rejuvenecido y potenciado para hacerlo más versátil y utilizable en los nuevos entornos.Para los que ya hemos comenzado a crear aplicaciones y bibliotecas ASP.NET Core, este cambio implica que en algún momento deberemos actualizarlas al nuevo formato de proyectos. Y como ya adelantamos, este proceso no va a resultar especialmente doloroso aunque obviamente tendremos que saber cómo hacerlo.
En este post vamos a tratar tres posibles escenarios de actualización:
Hey, pero antes de continuar, el tradicional disclaimer: tened en cuenta que tanto Visual Studio 2017 como el tooling de .NET Core está aún en preview, así que hay cosas que podrían variar en el futuro próximo.
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.
