Las ventajas que te ofrece Microsoft Azure y el mundo.NET

Añadir ficheros y otros orígenes de configuración en una aplicación Web o Api

Ahora que tenemos .Net 6 disponible para desarrollar, es necesario que nos acostumbremos a ciertos cambios relativos a la configuración y ubicación de determinados fragmentos de código así como a nueva nomenclatura y significativos cambios que tienen el fin de simplificar el desarrollo.

Entre estos cambios, se encuentra el especificar los ficheros y otros orígenes de configuración de nuestras aplicaciones, es decir, de dónde se tomarán los valores de las variables de entorno y configuración a la hora de ejecutar las aplicaciones.

¿Dónde especificamos los orígenes de configuración de la aplicación?

Como ya vimos en un artículo anterior, el fichero Program.cs es resultado de la fusión con el antiguo Startup.cs  que ha cambiado bastante su apariencia y la forma de escribir código en él. No obstante, lo que no ha cambiado es que sigue siendo el lugar adecuado para especificar y configurar los ficheros y otros orígenes de configuración de las aplicaciones desarrolladas con .Net 6

¿Cómo se hacía en versiones anteriores?

Si echamos un vistazo a lo que hacíamos en versiones anteriores de .Net, aprovechábamos la declaración de una propiedad pública y estática de tipo IConfiguration donde definíamos los orígenes de la configuración.

En el código que os adjunto a continuación, correspondiente a .Net Core 3.1, establecemos que se busque en el fichero actual de la aplicación el fichero appsettings.json, indicando que es opcional su existencia. Posteriormente se, carga el fichero appsettings correspondiente al entorno de ejecución definido en una variable de entorno llamada ASPNETCORE_ENVIRONMENT o, en su defecto Production, que, en caso de contener variables ya cargadas anteriormente las sobreescribiría. Por último, se define un HostBuilder al que se le indica que levante el fichero que contiene la clase Startup que corresponde a Startup.cs


public static IConfiguration Configuration { get; } = new ConfigurationBuilder()
    .SetBasePath(Directory.GetCurrentDirectory())
    .AddJsonFile("appsettings.json", optional: false, reloadOnChange: true)
    .AddJsonFile($"appsettings.{Environment.GetEnvironmentVariable("ASPNETCORE_ENVIRONMENT") ?? "Production"}.json", optional: true)
    .AddEnvironmentVariables()
    .Build();
 
public static IHostBuilder CreateHostBuilder(string[] args) =>
    Host.CreateDefaultBuilder(args)
         .ConfigureWebHostDefaults(webBuilder =>
         {
             webBuilder
                 .UseContentRoot(Directory.GetCurrentDirectory())
                 .UseStartup<Startup>();
         });

Agregar el código con los ficheros y otros orígenes de configuración en .Net 6

Con el nuevo Program.cs, aunque el concepto es el mismo, la forma de trabajar es algo diferente. Vamos a analizar el código antes de ver cómo añadir los orígenes de configuración.

Tenemos una variable llamada builder que es la encargada de inicializar el constructor de la aplicación con los valores por defecto, en caso de que no se especifique lo contrario. Por lo tanto, la aplicación cargará el fichero appsettings.json y su variante appsettings.Development.json si estamos depurando. Pero, ¿qué ocurre si queremos cambiar este comportamiento y añadir nuevos ficheros?

Teniendo en cuenta que ya disponemos de un builder, sólo será necesario indicarle que debe cargar la configuración de la forma que queremos. Para ello, crearenos un ConfigurationBuilder donde establezcamos el orden como hacíamos en versiones anteriores de .Net

var configBuilder = new ConfigurationBuilder()
    .SetBasePath(Directory.GetCurrentDirectory())
    .AddJsonFile("appsettings.json", optional: false, reloadOnChange: true)
    .AddJsonFile($"appsettings.{Environment.GetEnvironmentVariable("ASPNETCORE_ENVIRONMENT") ?? "Production"}.json", optional: true)
    .AddEnvironmentVariables()
    .Build();

Finalmente, indicaremos al builder de la aplicación que la configuración la debe obtener de la variable anterior con la siguiente línea.


builder.WebHost.UseConfiguration(configBuilder);

Hecho esto, la aplicación Web o Api cargará los ficheros de configuración en el orden que le hemos especificado.

Añadir Azure App Configuration como origen de configuración

Si finalmente queremos añadir Azure App Configuration a nuestra aplicación, utilizaremos la variable «builder» principal para llamar al método AddAzureAppConfiguration que se encuentra dentro del espacio de nombres Configuration, tal y como se muestra en el código.


if (!builder.Environment.IsDevelopment())
{
    builder.Configuration.AddAzureAppConfiguration(options =>
    {
        options.Connect(builder.Configuration["AzureAppConfigurationUri"])
            .Select(KeyFilter.Any, null)
            .Select(KeyFilter.Any, "MY_APP_LABEL")
            .ConfigureRefresh(refresh =>
            {
                refresh.Register("Sentinel", refreshAll: true)
                    .SetCacheExpiration(new TimeSpan(0, 10, 0));
            });
    });
}

Como se puede observar, lo primero que hacemos es comprobar que no estamos en entorno de desarrollo, porque en este entorno, al menos desde mi punto de vista, no es AppConfiguration con lo que debemos trabajar. No será del todo productivo al no poder controlar en muchos casos las distintas variables de configuración.

Posteriormente, se realiza la conexión mediante la «connectionstring» que obtenemos de los ficheros de configuración (o configuración del propio App Service si lo tenemos publicado), se escogen las etiquetas que no tengan Label que yo uso como genéricas a todos los entornos, se sobrescriben las etiquetas que tengan el label «MY_APP_LABEL» y finalmente, se configura el refresco de los valores de las etiquetas seleccionadas cada 5 minutos.

Con esto, la configuración que pueda ser cargada mediante los ficheros de configuración, quedará sobrescrita por la que podamos tener en Azure App Configuration.

Resumen

Aunque se haya hecho un gran lavado de cara de .NET y ASP.NET Core 6 con esta nueva versión, podemos seguir realizando las mismas tareas, eso sí, con algún cambio que en principio es para mejor.

Espero que os sirva para continuar en la adopción de .Net 6 como nuevo framework para desarrollar vuestras aplicaciones de una forma más simple y eficiente.

Enjoy coding!

mm

Sobre Santiago Porras Rodríguez

Innovation Team Leader at ENCAMINA | MVP in Developer Technologies. Apasionado por las nuevas tecnologías. Colaboro con la comunidad de desarrolladores escribiendo artículos en mi blog personal y ocasionalmente en CompartiMOSS.com. Además, soy uno de los coordinadores de TenerifeDev, grupo de usuarios de .NET de Tenerife y de otros grupos como Comunidad Office 365. Puedes encontrarme en la red microparticipando en Twitter con el usuario @saintwukong
Esta entrada ha sido publicada en Sin categoría. Enlace permanente.
Suscríbete a Piensa en Sofware desarrolla en Colores

Suscríbete a Piensa en Sofware desarrolla en Colores

Recibe todas las actualizaciones semanalmente de nuestro blog

You have Successfully Subscribed!

ENCAMINA, piensa en colores