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 ;)

18 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!
martes, 21 de julio de 2015
En versiones anteriores de ASP.NET, podíamos utilizar la expresión HttpContext.Current.IsDebuggingEnabled para determinar si una aplicación web está ejecutándose en modo depuración o no, lo cual podía ser útil a la hora de introducir porciones de código específicas para cada caso.

Compilation debug en Web.configEl valor de esa propiedad estaba directamente relacionado con el de la propiedad debug del tag <compilation> presente en el archivo de configuración web.config.

Como sabemos, en ASP.NET Core esto no sería posible por tres motivos:
Bien, ¿y cómo podemos introducir código dependiente del entorno de ejecución? Pues tenemos varias fórmulas.


La primera y más obvia consiste en acceder directamente al nombre del entorno activo a través de una instancia de IHostingEnvironment proporcionada por el sistema de inyección de dependencias, como vemos en el siguiente ejemplo:

Uso de IHostingEnvironment para obtener el entorno de ejecución

La siguiente captura de pantalla muestra el contenido de la instancia de IHostingEnvironment, y el valor de su propiedad EnvironmentName cuando ejecutamos la aplicación en el entorno “Development”:

IHostingEnvironment

Por tanto, introducir código específico para un entorno concreto sería trivial:

Código

Por supuesto, podríamos eliminar fácilmente esas magic strings del nombre del entorno creando extensores directos sobre IHostingEnvironment (por ejemplo, algo como IsDevelopment() o IsStaging()) o estableciendo constantes globales para ello. De hecho, incluso sería bastante recomendable: por ejemplo, en el código anterior, estamos usando incorrectamente "development" (con minúsculas) en lugar de "Development".

¿Y si quisiéramos introducir ese código en la vista? ¡Sin problema, claro! Recordad que ahora las vistas también pueden recibir dependencias utilizando la nueva directiva @inject de MVC, por lo que todo sería bastante similar a lo visto anteriormente:

@inject en la vista

Otra posibilidad bastante interesante recae sobre los tag helpers, una nueva y espectacular característica presente en MVC que permitirá crear vistas mucho más limpias gracias a la introducción de tags preprocesados desde el lado servidor.

En la nueva versión, tendremos disponible un nuevo tag llamado <environment> que será procesado directamente en servidor, en cuyo interior introduciremos el código que habrá de ser incluido en la página si el entorno de ejecución coincide con los que indiquemos en su parámetro names.

Seguro que ve mucho mejor con un ejemplo. Como se puede intuir en el siguiente ejemplo, el <div> sólo será enviado al cliente cuando el entorno de ejecución actual sea “Development”:

Tag environment

Y veamos un ejemplo más de uso, donde aprovechamos el tag <environment> para cargar scripts distintos en función del entorno de ejecución:

Tag environment

Y para finalizar, un truquillo: podéis probar el cambio de entorno muy fácilmente, pues a estas alturas disponemos ya de tooling en Visual Studio 2015. Para ello, a través de las propiedades del proyecto podemos asignar a la variable de entorno ASPNET_ENV el nombre del entorno de ejecución que queramos utilizar:

ASPNET_ENV settings

Publicado en Variable not found.

Aún no hay comentarios, ¡sé el primero!