Mercedes, parte de nuestro equipo, nos hizo el favor de redactar este artículo ya que conoce perfectamente el tema.
Solución:
pero, ¿qué es lo que ‘vincula’ la configuración para que anule appsettings.json cuando se publique la aplicación?
Los ajustes de la aplicación están configurados por WebHost en Program.cs
public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>
WebHost.CreateDefaultBuilder(args)
.UseStartup();
En la implementación de webhost.cs, el marco agrega la configuración de la aplicación al servidor web:
config.AddJsonFile("appsettings.json", optional: true, reloadOnChange: true)
.AddJsonFile($"appsettings.env.EnvironmentName.json", optional: true, reloadOnChange: true);
La segunda línea es donde agrega el entorno específico appsettings. Dentro de Visual Studio, esta variable de entorno se define en el Project Settings -> Debug pagina y se llama ASPNETCORE_ENVIRONMENT. De forma predeterminada, está configurado para Development por lo que cuando compila y ejecuta dentro de Visual Studio, el appsettings.development.json El archivo (si existe) se cargará y anulará cualquier configuración coincidente en el appsettings.json expediente.
Cuando publica su aplicación, puede anular este valor utilizando una variable de entorno del sistema operativo del mismo nombre. Hay una jerarquía de donde .NET Core lee los valores y tiene una política de “el último gana”.
La jerarquía es actualmente:
- Archivos (appsettings.json, appsettings. Environment.json, donde Environment es el entorno de alojamiento actual de la aplicación)
- Almacén de claves de Azure
- Secretos de usuario (Administrador de secretos) (solo en el entorno de desarrollo)
- Variables de entorno
- Argumentos de la línea de comandos
Entonces, cuando publica su aplicación, puede anular el entorno en el sistema operativo anfitrión usando una variable de entorno. Cuando .NET Core inicie su aplicación publicada, leerá esas variables y cargará las configuraciones de aplicación apropiadas. Archivo entorno.json. SI el valor no está establecido, o no existe ningún archivo para ese entorno, entonces la configuración en appsettings.json se aplicará.
Puedes leer más sobre el ASPNETCORE_ENVIROMENT ajuste aquí
… y desde mi comentario original, descubrí que las transformaciones de web.config son totalmente compatibles con VS 2017 y MS Build para .NET Core, una vez que se da cuenta de que los comandos de compilación de anidación y transformación no necesitan ser parte de el proyecto por más tiempo. No use “Agregar transformaciones de configuración” comando en su web.config por más tiempo, a menos que encuentre una solución que no dañe su archivo de proyecto. Simplemente agregue manualmente versiones de transformación de su web.config, y se anidarán y ejecutarán automáticamente al publicar. ¡Sí VS 2017!
Lo siguiente, en su web.Release.config funciona muy bien para configurar su Variable de entorno.
Además, con .NET Core 2.2, ya no necesita agregar las transformaciones de configuración de aplicaciones adicionales (desactivar su variable de entorno) a su clase de inicio. Este valor predeterminado…
public Startup(IConfiguration configuration)
Configuration = configuration;
…se encarga del código de la respuesta aceptada automáticamente.
La conclusión es que, como desarrollador de Microsoft que no se disculpa, todavía quiero asumir que mi aplicación solo se publicará en un servidor IIS, usando MS Build y Web Deploy, y me gustaría poder configurar mi aplicación a través de la propia configuración de la aplicación. ; y quiero poder hacer esto en Build, no como un comando de línea de comando de publicación o posterior a la publicación. Si Microsoft o alguien crea un complemento de compilación simple para Visual Studio que transformará mi archivo appsettings.json, por lo que solo publico lo que es necesario para el entorno dado, lo usaré con gusto, pero no he encontrado uno, o tenía el tiempo para escribir uno, todavía.
Y solo para asegurarme de responder la pregunta del OP directamente: AppSettings se puede transferir fácilmente desde web.config a appsettings.json, y probablemente debería hacerlo, siempre que comprenda que TODOS los archivos de appsettings.json se publican y se determinan en ejecución. -tiempo, a diferencia de un true transforme la solución donde solo se publican los archivos y configuraciones necesarios, según el perfil solicitado. Usando la transformación web.config solo para establecer la variable de entorno necesaria para determinar qué ajustes de aplicaciones. env.json para usar. Nuevamente, toda esta discusión sigue el camino del Dodo, si podemos transformar nuestro archivo apsettings.json de la misma manera que nuestro web.config, como solicitó el OP. Tengo la sensación de que llegará algún día, si es que no lo ha hecho ya.
Sí, pasar de un .NET Framework heredado a .NET Core puede ser un ejercicio divertido. .NET Core es un gran paso adelante, pero hay algunos obstáculos que superar; especialmente para aquellos que han estado en legado desde el principio.
Acuérdate de que tienes la opción de decir si te fue preciso.