martes, 21 de abril de 2015
Seguro que ya todos conocéis la fórmula mágica mediante la cual podemos activar la compilación de vistas en versiones de ASP.NET MVC anteriores a la 6. Los que no sepáis de qué os hablo, podéis echar un vistazo a este vídeo que publiqué en el blog de CampusMVP hace algún tiempo: VIDEO: Activar la compilación de vistas en ASP.NET MVC.
Muy resumidamente, el asunto consistía en editar manualmente el archivo de proyecto de Visual Studio, con extensión .csproj, y establecer el contenido del tag
A partir de ese momento, y tras recargar el proyecto, Visual Studio comienza a compilar las vistas como parte del proceso de construcción de la solución. Obviamente este proceso tardará un poquito más, pero al menos de esta forma tenemos la seguridad de que las vistas no van a explotar en tiempo de ejecución por errores de compilación.
Por otra parte, sabemos que el nuevo ASP.NET Core viene con bastantes novedades, entre las que destaca la desaparición y de muchos archivos clásicos, como el web.config, el global.asax… y también el .csproj. Y dado que era en éste donde activábamos la compilación de vistas, ¿dónde ha ido a parar ahora esa característica?
Pero antes de continuar, el tradicional disclaimer: en estos momentos ASP.NET Core y MVC se encuentran en fase de desarrollo, y todo lo que digamos a partir de ahora puede quedar en agua de borrajas.
Bien, pues la respuesta a la pregunta anterior la encontramos en Roslyn. Creo que todavía nos falta mucho hasta llegar a comprender el potencial y las posibilidades que se abren tras la llegada de este nuevo compilador, pero que lo que vamos a ver ahora es seguro un buen ejemplo.
Resulta que con Roslyn es posible introducir código personalizado en el momento de la compilación, y MVC aprovecha esta característica para insertar la compilación de las vistas Razor en el proceso.
Si observamos un proyecto ASP.NET Core generado usando la plantilla de Visual Studio 2015, podemos ver que existe un archivo RazorPreCompilation.cs en la carpeta /Compiler/Preprocess, como se muestra en la captura de pantalla adjunta.
En su interior, encontramos una clase llamada
Durante la compilación, Roslyn busca en esa carpeta exacta módulos de preproceso, que en la práctica son archivos con clases que implementan
La clase que añadimos a nuestra aplicación en esa carpeta puede tener cualquier nombre, pero lo importante es que herede de
Resumiendo, lo único que necesitamos para que las vistas de nuestra aplicación se precompilen es crear una clase cualquiera que herede de
Publicado en Variable not found.
Muy resumidamente, el asunto consistía en editar manualmente el archivo de proyecto de Visual Studio, con extensión .csproj, y establecer el contenido del tag
<MvcBuildViews>
a true.A partir de ese momento, y tras recargar el proyecto, Visual Studio comienza a compilar las vistas como parte del proceso de construcción de la solución. Obviamente este proceso tardará un poquito más, pero al menos de esta forma tenemos la seguridad de que las vistas no van a explotar en tiempo de ejecución por errores de compilación.
Por otra parte, sabemos que el nuevo ASP.NET Core viene con bastantes novedades, entre las que destaca la desaparición y de muchos archivos clásicos, como el web.config, el global.asax… y también el .csproj. Y dado que era en éste donde activábamos la compilación de vistas, ¿dónde ha ido a parar ahora esa característica?
Pero antes de continuar, el tradicional disclaimer: en estos momentos ASP.NET Core y MVC se encuentran en fase de desarrollo, y todo lo que digamos a partir de ahora puede quedar en agua de borrajas.
Actualización (Feb-2016): efectivamente, así ha sido. El soporte para la precompilación de vistas ha sido descartado para la primera versión de ASP.NET Core.
Bien, pues la respuesta a la pregunta anterior la encontramos en Roslyn. Creo que todavía nos falta mucho hasta llegar a comprender el potencial y las posibilidades que se abren tras la llegada de este nuevo compilador, pero que lo que vamos a ver ahora es seguro un buen ejemplo.
Resulta que con Roslyn es posible introducir código personalizado en el momento de la compilación, y MVC aprovecha esta característica para insertar la compilación de las vistas Razor en el proceso.
Si observamos un proyecto ASP.NET Core generado usando la plantilla de Visual Studio 2015, podemos ver que existe un archivo RazorPreCompilation.cs en la carpeta /Compiler/Preprocess, como se muestra en la captura de pantalla adjunta.
En su interior, encontramos una clase llamada
RazorPreCompilation
, que hereda de la clase suministrada por MVC RazorPreCompileModule
, que a su vez implementa el interfaz ICompileModule
proporcionado por Roslyn. El código que trae esta clase por defecto es el siguiente:Durante la compilación, Roslyn busca en esa carpeta exacta módulos de preproceso, que en la práctica son archivos con clases que implementan
ICompileModule
, y les cede el control antes y después de compilar, dándoles la oportunidad de introducir entradas al árbol sintáctico resultante de la compilación o mensajes de diagnóstico y error al resultado.La clase que añadimos a nuestra aplicación en esa carpeta puede tener cualquier nombre, pero lo importante es que herede de
RazorPreCompilation
(definido en Microsoft.AspNet.Mvc
), pues se trata de la implementación de ICompileModule
que utiliza internamente el precompilador de vistas de Razor para generar los resultados. Resumiendo, lo único que necesitamos para que las vistas de nuestra aplicación se precompilen es crear una clase cualquiera que herede de
RazorPreCompileModule
en la carpeta /Compiler/Preprocess del proyecto, y Roslyn se encargará del resto :)Publicado en Variable not found.
Aún no hay comentarios, ¡sé el primero!
Enviar un nuevo comentario