asp.net core - tutorial - ¿Cómo publicar aplicaciones específicas del entorno en la aplicación central.Net?

netcore 2.2 sdk (8)

Debe agregar las variables de entorno, de acuerdo con el tutorial oficial :

var builder = new ConfigurationBuilder() .SetBasePath(env.ContentRootPath) .AddJsonFile($"appsettings.{env.EnvironmentName}.json", optional: false, reloadOnChange: true) // do not forget to add environment variables to your config! .AddEnvironmentVariables();

Tengo 3 archivos de appsettings específicos del appsettings en mi aplicación .Net Core

en project.json he configurado publishOptions como esta. (basado en sugerencia here )

"publishOptions": { "include": [ "wwwroot", "appsettings.development.json", "appsettings.staging.json", "appsettings.production.json", "web.config" ] },

Tengo 3 clases de inicio correspondientes que utilizan aplicaciones apropiadas basadas en el entorno

var builder = new ConfigurationBuilder() .SetBasePath(env.ContentRootPath) .AddJsonFile($"appsettings.{env.EnvironmentName}.json", optional: false, reloadOnChange: true);

Sin embargo, cuando publico la aplicación, los 3 archivos de configuración terminan en todos los entornos. ¿Cómo publico un archivo de configuración de entorno específico?

En VS2017 Añadiendo múltiples entornos

Pasos, haga clic con el botón derecho en el proyecto -> Agregar -> NewItem - seleccione json file - escriba el nombre del archivo como ''appsettings.staging.json'' o ''appsettings.production.json''

Agregar el archivo appsettings.staging.json

La salida parece

La forma más fácil que he encontrado hasta ahora es desplegar todos los archivos de configuración y luego eliminar los archivos adicionales una vez finalizada la implementación. Solo agregue algunas líneas adicionales al final de su shell de implementación o script por lotes.

Puede usar las condiciones de MSBuild para incluir opcionalmente archivos en la salida de compilación (o salida publicada).

<ItemGroup Condition="''$(Configuration)''==''Release''"> <Content Remove="appsettings.Development.json;appsettings.Staging.json" /> <None Include="appsettings.Development.json;appsettings.Staging.json" /> </ItemGroup>

Lo anterior ignora las variantes del archivo appsettings.json de Development and Staging cuando la configuración de destino de la compilación es Release.

Resolví esta pregunta con este paquete nuget: https://github.com/Microsoft/slow-cheetah/blob/master/doc/transforming_files.md

Es muy fácil de instalar y usar todas las configuraciones en la configuración de la solución activa (en mi caso, agregué una nueva configuración de "Prueba" para la implementación de la prueba).

Después de esto, puede instalar esta extensión en VS: https://marketplace.visualstudio.com/items?itemName=vscps.SlowCheetah-XMLTransforms .

Ahora mismo puede crear un nuevo subarchivo de configuración para los ajustes de configuración de la aplicación .xml o .json en VS con esta herramienta (como en el manual). Por ejemplo, tengo archivos de depuración, prueba y lanzamiento (appsettings.Debug.json y etc.)

Paso siguiente: configurar los perfiles de publicación para cada configuración y después de la publicación, tendrá un solo archivo con todas las transformaciones necesarias.

Las transformaciones funcionan como una transformación de entorno .json clásica en las aplicaciones web principales .net.

Si alguien más se está preguntando cómo usar diferentes ajustes para múltiples entornos, aquí hay una posible solución.

dotnet publish --configuration [Debug|Release] copiará el archivo appsettings.json apropiado en la carpeta de publicación si *.csproj tiene una lógica condicional para estos archivos:

Primero en el archivo de perfil de publicación .pubxml (se puede encontrar en Properties -> .pubxml publicación de Visual Studio) deshabilite que todos los archivos de contenido estén incluidos de manera predeterminada

<PropertyGroup> <TargetFramework>netcoreapp2.1</TargetFramework> <EnableDefaultContentItems>false</EnableDefaultContentItems> </PropertyGroup>

Luego especifique la lógica de depuración / liberación condicional

Finalmente dentro de Startup.cs intenta cargar ambos archivos.

public Startup(IHostingEnvironment env) { var builder = new ConfigurationBuilder() .SetBasePath(env.ContentRootPath) .AddJsonFile($"appsettings.prod.json", optional: true, reloadOnChange: true) .AddJsonFile($"appsettings.json", optional: true, reloadOnChange: true) .AddEnvironmentVariables(); Configuration = builder.Build(); }

Espero que esta solución, haya sido de ayuda.

Sinceramente, creo que esa no es la tarea correcta para construir un oleoducto. También las características de publicación de la dotnet cli son muy limitadas. Ve a herramientas externas como Tseng te mostró. El despliegue es otro dominio con un conjunto propio de complejidad que la construcción.

¡No hay una compilación en modo dotnet cli más allá del uso de herramientas externas!

Una forma posible sería ejecutar scripts / comandos prepublish o postpublic, por ejemplo ejecutando una tarea dotnet publish-iis ejecutando dotnet publish-iis (como alternativa, utilice una tarea en la sección prepublish de scripts para copiar los archivos antes de la publicación).

Agrega esto a tu proyecto.json:

"scripts": { "postpublish": [ "gulp cleanconfig", "dotnet publish-iis --publish-folder %publish:OutputPath% --framework %publish:FullTargetFramework%" ] }

También puede ejecutar un comando cmd o shell aquí. Pero en realidad no debería haber ninguna razón por la cual querría hacer esto en primer lugar, simplemente envíe los 3 archivos de appconfig, porque en el Servicio de aplicaciones de Azure, puede cambiar el modo dependiendo de las variables de entorno que se regulan a través de El Portal de Azure y cuando se publiquen, las ranuras de puesta en escena y producción se intercambiarán, pero las variables ambientales se mantendrán.

Sin embargo, no debe almacenar secretos dentro de appsettings.json (lo cual supongo que usted hace y la razón por la que desea eliminar los archivos). En su lugar, use "secretos de usuario" para el desarrollo y variables ambientales para establecer cadenas de conexión, etc. para la producción. Funciona a la perfección, especialmente con los servicios de aplicaciones de Azure y los contenedores docker.