Aspnetcore: Habilite las transformaciones web.config para proyectos AspNetCore en VS

FWIW, estoy de acuerdo. Solo debemos tener claro que es para la configuración de IIS. La otra cosa es el hecho de que nos hemos alejado de tener un web.config predeterminado en la plantilla, por lo que sería necesario resolverlo.

/ cc @sayedihashimi

Sin embargo, ¿esto es solo para IIS? Creo que el meollo del problema es el uso de la variable ASPNETCORE_ENVIRONMENT fullstop para que un sitio web sepa en qué entorno se encuentra.

Creo que un escenario bastante común es que varios entornos de prueba / control de calidad se alojen en el mismo cuadro en la misma instancia de IIS. Puede haber 3 equipos, todos con sus propios "entornos" en los que pueden implementar para probar su código (digamos, implementar una rama en particular), pero todos están usando la misma caja.

Si tomamos algún código de ejemplo sobre cómo se cambia appsettings.json por entorno:

public Startup(IHostingEnvironment env) { var builder = new ConfigurationBuilder() .SetBasePath(env.ContentRootPath) .AddJsonFile("appsettings.json", optional: true, reloadOnChange: true) .AddJsonFile($"appsettings.{env.EnvironmentName}.json", optional: true) .AddEnvironmentVariables(); Configuration = builder.Build(); }
El escenario anterior no funcionará porque la variable de entorno es para todo el sistema. Podría ser IIS, nginix, etc., sentado frente a él y el intercambio de configuración no funcionará.

La mayoría de las veces que he visto surgir lo anterior, han surgido sugerencias para usar Docker o usar algo como Puppet / Chef para administrar la configuración de la aplicación, por lo que no hay configuraciones de aplicaciones. {Env} .json, pero creo que eso hace que la ruta sea completa framework MVC mucho más difícil.

@mindingdata De hecho, puedes controlar la lógica que determina de dónde viene el entorno en tu Program.cs . La variable de entorno es solo una forma de declarar eso (la forma principal). Si desea hacer otra cosa basada en algún archivo mágico o en la hora del día, llame a UseEnvironment(environmentName) en el WebHostBuidler

Solo para aclarar, esto es absolutamente solo para la configuración de IIS. El sistema de configuración JSON actual para la configuración de la aplicación es bastante bueno y lo recomiendo totalmente.

Para enturbiar aún más las cosas: encuentro que cuando uso web.config para intentar anular la configuración del entorno del sistema, simplemente no funciona. Cuando la configuración del entorno de mi sistema está configurada en "Desarrollo" e intento configurarla en "Producción" usando web.config (como se muestra a continuación), la aplicación todavía cree que se está ejecutando en Desarrollo. (Aplicación ASP.NET Core que se ejecuta en IIS).

<environmentVariables>
      <environmentVariable name="ASPNETCORE_ENVIRONMENT" value="Production" />
</environmentVariables>

Creo que este es el lugar indicado. Construyo una demostración de N niveles y parece que no puedo averiguar cómo inyectar IHostingEnvironment en mi proyecto de capa de acceso a datos. Ese proyecto es donde accedo a mi base de datos y la única forma en que obtuve la cadena de conexión a esa capa fue anular el método OnConfiguring con una cadena mágica del archivo de configuración.

También miré al guepardo lento, pero eso parece ir alrededor del método actual de "Depurar, Liberar" o "Desarrollo, Producción" dependiendo de si estás usando el método VS o las variables de entorno.

Debe haber información que me falta. MS no puede querer que todos creen aplicaciones de un solo nivel.

protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
           var builder = new ConfigurationBuilder().SetBasePath(Directory.GetCurrentDirectory()) .AddJsonFile("appsettings.json");

            var config = builder.Build();
            var connstr = config.GetConnectionString("connStr");            
            optionsBuilder.UseSqlServer(connstr);
        }

entonces, ¿ha habido algún progreso en esto?

deberíamos poder configurar el env en la configuración de una aplicación sin recurrir a la magia

Sí, también me gustaría progresar en esto. Actualmente no tengo idea de cómo se supone que debo publicar proyectos separados en la misma caja usando diferentes variables de entorno.

Terminé encontrando una solución bastante simple. En el archivo principal appsettings.json, especifico mi entorno deseado:

{
  "Logging": {
    "IncludeScopes": false,
    "LogLevel": {
      "Default": "Warning"
    }
  },
  "ActiveEnvironment": "Development"
}

En Program.CS, luego construyo una IConfiguration y establezco el nombre del entorno en el valor del 'ActiveEnvironment', antes de cargar el archivo de configuración específico del entorno.

public static void Main(string[] args)
{
    WebHost.CreateDefaultBuilder()
    .ConfigureAppConfiguration((hostingContext, config) =>
    {
        // Get the environment from our hostContext.
        var env = hostingContext.HostingEnvironment;
        config.AddJsonFile("appsettings.json", optional: false, reloadOnChange: true);

        // Build an initial configuration.
        IConfiguration Configuration = config.Build();

        // Set the environment name.
        env.EnvironmentName = Configuration.GetSection("ActiveEnvironment").Value;

        // Load the configuration file for our specific environment.
        config.AddJsonFile($"appsettings.{env.EnvironmentName}.json", optional: false, reloadOnChange: true)
        .AddEnvironmentVariables();
    })
    .UseStartup<Startup>()
    .Build()
    .Run();
}

Obviamente, al publicar en diferentes entornos, el 'ActiveEnvironment' debe cambiarse en consecuencia.

@DaleMckeown Iba a hacer algo similar pero tenía una pregunta sobre su implementación. Veo que está utilizando Microsoft.AspNetCore.WebHost para crear la configuración predeterminada. ¿Este enfoque todavía se aplica a una aplicación de consola sin componentes web?

@Swazimodo No he probado esta solución en el contexto de una aplicación de consola, así que no estoy seguro. Lo mejor es ver si hay una forma alternativa de configurar las variables de entorno para las aplicaciones de consola.

Nos ocupamos de esto de una manera diferente. Configuramos nuestro agente de compilación para que tome
el archivo de configuración específico del entorno y sobrescriba el archivo de configuración raíz
con eso. Nuestra compilación crea un archivo zip separado para cada entorno que
desplegar a.

El jueves 26 de octubre de 2017 a las 12:48 p.m., Dale Mckeown [email protected]
escribió:

@Swazimodo https://github.com/swazimodo No he probado esta solución
int el contexto de una aplicación de consola, así que no estoy seguro. La mejor apuesta es
ver si hay una forma alternativa de configurar las variables de entorno para
aplicaciones de consola.

-
Estás recibiendo esto porque estás suscrito a este hilo.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/aspnet/Home/issues/2019#issuecomment-339728441 , o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/AAx4bT20JSb0XSzNBIAiiubq9mTVKbW5ks5swLf6gaJpZM4NMx25
.

¿Parece que todas las soluciones requieren algún tipo de ajuste posterior a la compilación / publicación? Terminé colocando un archivo de texto vacío en la raíz de la aplicación y lo pasé como entorno. ¿Yo me perdí algo?

Totalmente de acuerdo con el primer post. Es por diseño bastante flexible, pero al final resultó ser muy difícil de automatizar. Por ejemplo, tengo una aplicación que publico en IIS en otro servidor. También se ejecuta en IIS local (a través de carpeta de publicación). Así que configuré el entorno de desarrollo en web.config. Pero luego necesito cambiarlo a Producción o lo que sea durante la publicación. Tarea bastante común, supongo. Creo que es imposible, ¿verdad? Tengo que editar manualmente web.config en servidores remotos.

Lo ideal es que la configuración del entorno sea compatible a través de "dotnet publish" (para cualquier destino de publicación):

dotnet publish ... -environment=Production

dotnet publish podría buscar archivos web.%Enviroment%.config (Web.Production.config, Web.Development.config) y fusionarlos (transformarlos) con web.config. Al final tendríamos el valor correcto de ASPNETCORE_ENVIRONMENT:

    <environmentVariables>
        <environmentVariable name="ASPNETCORE_ENVIRONMENT" value="value passed to publish" />
    </environmentVariables>         

@ evil-shrike echa un vistazo a https://github.com/nil4/dotnet-transform-xdt para ver las transformaciones de configuración de tiempo de compilación / publicación.

Quizás un caso de uso. Necesito que los registros se escriban en. \ App_Data porque el ejecutor de mi aplicación tiene acceso de lectura / escritura a todo lo que se encuentra en. \ App_Data, pero solo puede leer todo lo demás en. \. Uso la implementación web y me gustaría poder implementar un web.config como este con la carpeta de registros en App_Data:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <handlers>
      <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />
    </handlers>
    <aspNetCore processPath=".\<assembly>.exe" stdoutLogEnabled="true" stdoutLogFile=".\App_Data\logs\stdout" />
  </system.webServer>
</configuration>

Podría preguntar, ¿por qué no simplemente poner esas configuraciones en un archivo web.config en lugar de web.release.config? Bueno, processPath=".\<executable>.exe" no es donde vive el ejecutable cuando estoy desarrollando localmente contra IIS Express. Así que aparece el error "Error HTTP 502.5 - Fallo del proceso".

Automatizamos nuestras compilaciones usando Jenkins y nuestra forma actual de realizar la configuración de vars por entorno en proyectos de NetFramework es a través de transformaciones web.config. Así que pensamos que también podríamos hacerlo en dotnet.

¡Resulta que msbuild sigue siendo compatible con aspnet core csproj para realizar transformaciones web.config!

Podemos agregar la tarea de publicación TransformXml en el csproj de Asp.Net Core:

<UsingTask TaskName="TransformXml" AssemblyFile="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v15.0\Web\Microsoft.Web.Publishing.Tasks.dll" />

Agregue los objetivos de transformación específicos:

<Target Name="ConfigDev">
    <TransformXml Source="web.config" Transform="web.dev.config" Destination="web.config" /></Target>

Realice algunas transformaciones, por ejemplo, en la variable ASPNETCORE_ENVIRONMENT en web.dev.config :

<system.webServer>
    <aspNetCore processPath="dotnet" arguments=".\Test.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" >
      <environmentVariables>
        <environmentVariable xdt:Locator="Match(name)" name="ASPNETCORE_ENVIRONMENT" value="dev" xdt:Transform="SetAttributes" />
      </environmentVariables>
    </aspNetCore>
</system.webServer>

Transforme web.config usando msbuild antes de ejecutar la publicación:

msbuild Test.csproj /t:ConfigDev

"Permítanme anteponer esto diciendo que no soy fanático de web.config, pero la experiencia de publicar aplicaciones AspNetCore en IIS es realmente pobre".

No podría estar más de acuerdo con este hilo.

Después de la simplicidad de las transformaciones de configuración en ASP.Net normal, toda esta dependencia de una variable ASPNETCORE_ENVIRONMENT de toda la

Incluso los propios ejemplos de Microsoft dicen que podemos usar, digamos, un archivo _appsettings.Production.json_, simplemente agregando esta línea ...

            .AddJsonFile($"appsettings.{env.EnvironmentName}.json", optional: true);

... pero no presta atención al NOMBRE de la configuración que hemos elegido. Entonces, incluso cuando haya elegido mi configuración de producción, seguirá intentando abrir appsettings.development.json. Y no, no quiero tener que editar manualmente la variable ASPNETCORE_ENVIRONMENT yo mismo cada vez que publico en un entorno diferente. Eso es solo buscar problemas.

Todavía tengo que ver un ejemplo simple y funcional del uso de archivos _appsettings.XXXX.json_.
No puedo esperar a que esto finalmente esté terminado. (Suspiro...)

¡Sí, por favor arregle esto !

Acabo de implementar mi primer sitio principal de dotnet de producción y ahora me enfrento al problema de que no puedo tener fácilmente una instancia de prueba en el mismo servidor porque no sé cómo publicar mi aplicación en el mismo cuadro sin que recoja el ajustes de producción.

Creo que voy a probar la solución @DaleMckeown por ahora, creo que funcionará, pero se siente como una solución alternativa en lugar de una solución. Las variables de entorno son excelentes, pero SOLO si tiene una proporción de 1 a 1 de servidores a entornos, y fuera de la empresa, dudo que eso suceda con frecuencia.

@willapp Mi sugerencia es definitivamente una solución. Pero funciona: he tenido varias versiones de la misma aplicación ejecutándose en el mismo servidor durante un tiempo y no he tenido ningún problema.

Solo recuerde cambiar la configuración de 'ActiveEnvironment' antes de publicar y debería estar bien.

Me estoy enfrentando exactamente a lo que mencionó dkent600:

<environmentVariables>
      <environmentVariable name="ASPNETCORE_ENVIRONMENT" value="Production" />
</environmentVariables>

no funciona en el servidor de producción. La aplicación sigue usando los valores "appsettings.Development.json", que, en última instancia, anula los beneficios de la transformación xml al publicar.

Probaré la solución alternativa sugerida por DaleMckeown.

la única forma razonable de cambiar ASPNETCORE_ENVIRONMENT es usando web.config

Realmente no. Si necesita ejecutar varias instancias del mismo sitio en la misma máquina, aquí hay una forma mucho más sencilla

• MyCoreSite
  
  
  
  • compartimiento
  
  
  • registros
  
  
• env. lo que sea

Apunte su aplicación IIS a bin y en program.cs

.UseEnvironment(ReadEnvExtensionFromParentFolder())

Eso es. Puede tener tantos sitios como desee, implementar en el contenedor sin preocuparse por la transformación e incluso cambiar de entorno cambiando el nombre de env.Whenver.

Yo voto a favor de esto. Tengo reescrituras de URL configuradas para el servidor de producción que no funcionan en el entorno de prueba. No he encontrado una manera de publicar para seleccionar el archivo web.config correcto para la implementación, tengo que copiarlo manualmente.

Eche un vistazo a https://github.com/nil4/xdt-samples/ y la herramienta CLI para aplicar transformaciones en el momento de la publicación .

¿Hay algún progreso en esto? Han pasado 13 meses desde el informe inicial, 2.1.0 está aquí ahora, y las cosas siguen siendo bastante malas con el alojamiento IIS tradicional. Las cosas funcionan de maravilla si usa Azure, pero actualmente esa no es una opción para una gran parte de los sitios que estoy alojando.

Parece que para el alojamiento IIS tradicional sería beneficioso establecer el entorno deseado en la línea de comando (como @ evil-shrike expuso anteriormente), y también dentro de los perfiles de publicación .pubxml . Como dijo @davidfowl , debería quedar claro que esto solo funcionaría usando web.config e IIS, pero eso seguramente todavía cubre una parte sustancial de la base de instalación.

Por el momento, tengo una solución muy frágil que usa la traducción Microsoft.DotNet.Xdt.Tools y web.config , pero requiere una configuración de compilación por entorno para que funcione y acaba de romperse después de actualizar a v2.1.0.

Sería genial saber si hay planes en esta área y, de ser así, ¿cuáles son? Si no hay planes, o si están muy lejos, entonces seguramente hay una mejor solución provisional que las formas frágiles / semimanuales que actualmente nos vemos obligados a emplear. Especialmente para la implementación en QA y puesta en escena, realmente me gustaría poder presionar un botón en VS y saber que está sucediendo lo correcto, y no tener que depender del conocimiento de la cabeza y los procesos manuales.

Actualmente no tenemos ningún plan, pero esta herramienta https://github.com/nil4/xdt-samples/ de @ nil4 se ve bastante bien.

@svallis ¿lo has probado?

¿Lo principal que la gente quiere es establecer el entorno?

@davidfowl Sí, mi solución actual está usando la herramienta que vinculó, pero para un proyecto con múltiples destinos para publicar, se requiere una configuración de compilación por entorno. Necesita las diferentes configuraciones de compilación para tener algo a lo que aferrarse en la configuración csproj , y para mis propósitos, generalmente es una relación 1 a 1 con sus entornos. Por ejemplo:

• Configuración de compilación: Debug = Environment: Development
• Configuración de compilación: Staging = Environment: Staging
• Configuración de compilación: Lanzamiento = Entorno: Producción

Para los dos últimos, tengo los web.{Build configuration}.config y appsettings.{Environment}.json , y el web.{Build configuration}.config es literalmente solo un XDT para decirle al web.config que termine con el variable de entorno apropiada ASPNETCORE_ENVIRONMENT . Entonces, por ejemplo, continuando con el ejemplo anterior, web.Release.config ve así:

<?xml version="1.0" encoding="utf-8"?>
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
  <system.webServer>
    <aspNetCore>
      <environmentVariables>
        <environmentVariable name="ASPNETCORE_ENVIRONMENT" value="Production" xdt:Transform="SetAttributes" xdt:Locator="Match(name)" />
      </environmentVariables>
    </aspNetCore>
  </system.webServer>
</configuration>

En realidad, todo esto funciona bastante bien desde la línea de comandos. Ejecutar dotnet publish -c Staging o lo que sea produce una carpeta con la salida correcta y el web.config transformado según sea necesario. Sin embargo, parece que podría simplificarse. Si hubiera un cambio -iisenvironment en dotnet publish que hiciera esto por nosotros, y luego se expusiera como un cuadro de texto simple en la publicación de VS, eliminaría la necesidad de administrar configuraciones de compilación, XDT, etc manualmente para situaciones de alojamiento IIS tradicionales.

Sin embargo, desde dentro de VS, actualmente parece problemático. Sin embargo, actualmente no podemos publicar desde VS, e incluso cuando funcionó en v2.0.0, tuvimos que seleccionar manualmente la configuración de compilación correcta antes de publicar.

@davidfowl Desde mi perspectiva, lo ideal sería configurar el entorno como parte del perfil de publicación cuando utilizo Web Deploy.

Yo apoyaría eso, una opción sobre la publicación sería ideal. Ni siquiera estoy usando la solución alternativa descrita por @svallis, ya que prefiero publicar a través de VS IDE y no a través de la línea de comandos.

@willapp La solución que estoy usando funciona en Visual Studio, pero tengo otros problemas con la solución que estoy probando que están causando problemas en VS (https://github.com/aspnet/Home/issues/3190) . Lo siento si no lo dejé claro. Todo está configurado usando herramientas en csproj , que tanto la línea de comando como VS deben respetar.

Finalmente probé la herramienta sugerida anteriormente por

Simplemente siga las instrucciones aquí https://github.com/nil4/dotnet-transform-xdt en la sección "Herramienta a nivel de proyecto" (ya que todavía no estoy en 2.1.0). Tuve que crear un Web.config predeterminado yo mismo ya que no lo tenía (solo lo copié del que VS genera cuando lo implementa), luego creé un Web.Debug.config con una transformación para establecer ASPNETCORE_ENVIRONMENT en Desarrollo, y oye ¡presto! Implementa la configuración transformada y el sitio ahora se inicia correctamente.

Sería bueno si el apoyo para esto se hiciera oficial, pero por ahora esto está funcionando.

@davidfowl El enlace que señaló debe publicarse mediante la línea de comandos. Me gustaría publicar usando la herramienta VS GUI. No quiero que mis desarrolladores necesiten instalar herramientas cli para publicar el proyecto. No tiene sentido poder especificar ASPNETCORE_ENVIRONMENT en web.config si las transformaciones no son compatibles. Al ver cuántos votos a favor tiene este problema, debería ir a la lista de trabajos pendientes.

@ orobert91 VS es solo una GUI envuelta alrededor de las herramientas de línea de comando. Estoy usando https://github.com/nil4/xdt-samples/ para transformar web.config durante la publicación desde VS. Si lo configura correctamente para su proyecto, se transformará correctamente tanto desde la línea de comandos como dentro de su IDE.

@svallis De hecho, leyó mal los documentos. He resuelto mi problema con una simple tarea de copia:

  <Target Name="CopyFiles" AfterTargets="Publish">  
      <Copy SourceFiles="web.$(Configuration).config" DestinationFiles="web.config" />  
  </Target>   

Hay una propiedad msbuild que publica honores para el nombre del entorno:

$ (EnvironmentName)

(https://github.com/aspnet/websdk/blob/d7d73e75918ec3168bd3e5d519d0decc04675faf/src/Publish/Microsoft.NET.Sdk.Publish.Targets/netstandard1.0/TransformTargets/Microsoft.NET. ).

En este momento, cuando se establece esta propiedad, todo lo que hacemos es crear appsettings.$(EnvironmentName).json y agregar la información de la cadena de conexión a ese archivo (si se solicita).

En el futuro, cuando esta propiedad se establece durante la publicación, también podemos actualizar el web.config publicado para tener la siguiente entrada también:

<environmentVariables>
      <environmentVariable name="ASPNETCORE_ENVIRONMENT" value="$(EnvironmentName)" />
</environmentVariables>

¿Funcionaría esto para la mayoría de los escenarios mencionados aquí?

Para los escenarios fuera de la configuración de environmentVariable, veremos la viabilidad de portar las transformaciones web.config ( Xdt ) para proyectos centrales.

Se me ocurrió una solución que parece cubrir los escenarios que necesito; quería publicarla aquí en caso de que sea útil para alguien más.

En mi caso, tengo mi entorno de desarrollo localmente y tanto mi entorno de ensayo como el de producción en un servidor remoto (mismo servidor). Pude extraer la URL de la aplicación del IApplicationBuilder y usarla en una declaración switch para establecer el EnvironmentName .

Parece mucho menos "alternativa" que algunas de las otras soluciones ofrecidas, pero ciertamente se reduce a preferencias.

En Startup.cs :

        public void Configure(IApplicationBuilder app, IHostingEnvironment env)
        {
            env.DetectAndSet(app);

            ... other config method stuff here ...
        }

El método anterior es una extensión que armé en función de la colección de propiedades dentro de IApplicationBuilder . El método de extensión (y la clase) se ve así:

using Microsoft.AspNetCore.Builder;
using Microsoft.AspNetCore.Hosting;
using Microsoft.AspNetCore.Http.Features;
using Microsoft.AspNetCore.Hosting.Server.Features;
using System.Linq;

namespace MyRootNamespace.Common.Extensions
{
    public static class IHostingEnvironmentExtensions
    {
        /// <summary>
        /// Detects the current hosting url and sets the <see cref="IHostingEnvironment.EnvironmentName"/> accordingly.
        /// </summary>
        /// <param name="env">The <see cref="IHostingEnvironment"/> to set.</param>
        /// <param name="app">The <see cref="IApplicationBuilder"/> used to retrieve the current app url.</param>
        public static void DetectAndSet(this IHostingEnvironment env, IApplicationBuilder app)
        {
            var _appUrl = string.Empty;

            try
            {
                _appUrl = ((FeatureCollection)app.Properties["server.Features"]).Get<IServerAddressesFeature>()?.Addresses?.FirstOrDefault();
            }
            catch { }

            switch (_appUrl)
            {
                case "https://www.myurl.com":
                case "http://www.myurl.com":
                    env.EnvironmentName = EnvironmentName.Production;
                    break;
                case "https://staging.myurl.com":
                case "http://staging.myurl.com":
                    env.EnvironmentName = EnvironmentName.Staging;
                    break;
                default:
                    env.EnvironmentName = EnvironmentName.Development;
                    break;
            }
        }
    }
}

Espero que esto pueda ser de alguna utilidad para la gente (en aquellos casos en los que una transformación web.config no sea deseable).

¡Salud!

Estoy marcando este problema como una discusión porque no se planean funciones / correcciones relacionadas con esto en este momento. Si las personas aún tienen solicitudes de funciones específicas, presente los problemas para ellos y los priorizaremos.

No estaba realmente satisfecho con las soluciones que vi en este hilo, así que tomé un enfoque diferente. Me encontré con este hilo Stack Overflow: https://stackoverflow.com/questions/31049152/publish-to-iis-setting-environment-variable/36836533#36836533. Habla sobre la modificación de ApplicationHost.config en el servidor como un lugar para almacenar la variable ASPNETCORE_ENVIRONMENT.

Nuestros servidores IIS internos son administrados por nuestro equipo de operaciones, por lo que los desarrolladores de nuestra organización no crean esos sitios de todos modos. El equipo de operaciones usa un script de PowerShell para crear estos sitios. Solo les pedí que modificaran ese script para que también realice los cambios relevantes en ApplicationHost.config en el momento en que se aprovisiona el sitio. Ahora puedo implementarlo allí y no preocuparme por administrar el entorno .NET Core. Funcionó bien para nuestra situación.

Creo que en un verdadero entorno de DevOps probablemente estarías usando Azure de todos modos, lo que hace que sea muy fácil configurar la variable de entorno.

Con el último Sdk, puede simplemente pasar la propiedad msbuild $(EnvironmentName) y las herramientas se encargarán de establecer ASPNETCORE_ENVIRONMENT en este valor.

por ejemplo: si EnvironmentName está configurado como ensayo, entonces web.config tendrá la siguiente entrada:

      <aspNetCore processPath="dotnet" arguments=".\WebApplication242.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout">
        <environmentVariables>
          <environmentVariable name="ASPNETCORE_ENVIRONMENT" value="Staging" />
        </environmentVariables>
      </aspNetCore>

PR con la solución:
https://github.com/aspnet/websdk/pull/377

@vijayrkn Parece un comienzo prometedor. ¿Esto eventualmente tendrá soporte integrado en VS WebDeploy / publicación de perfiles, etc.?

En este momento no tenemos una interfaz de usuario en VS para hacer esta selección de nombre de entorno, pero si esto se agrega al archivo del proyecto o al pubxml, tanto la publicación desde VS como la línea de comandos lo respetarán.

También buscaremos agregar compatibilidad con la interfaz de usuario para esto.

@vijayrkn Esta es solo una solución para aquellos que publican con un archivo web.config , ¿es correcto?

@vijayrkn Sí, obtener soporte en el formato pubxml sería el momento en el que esto sería útil para nuestro caso de uso. En ese punto, podríamos eliminar todas las cosas de transformación XML y solo especificar las cadenas de entorno apropiadas en cada pubxml . La compatibilidad con la interfaz de usuario podría llegar en una fecha posterior, pero esa sería la guinda del pastel.

@challamzinniagroup : no, no necesita un web.config para esta funcionalidad.
Todo lo que necesita hacer es agregar lo siguiente al archivo pubxml y las herramientas de publicación se encargarán del resto.

<EnvironmentName>YourCustomEnvironment</EnvironmentName>

@challamzinniagroup , @vijayrkn

A menos que tenga alguna configuración que solo se puede hacer en web.config y debe transformarse entre entornos, de lo contrario, deje web.config solo. Con 2 líneas de código, puede leer variables de entorno desde cualquier lugar. Y no necesita ningún ajuste en el perfil de publicación o el código publicado, solo una lista de ajustes de aplicaciones coincidentes.XYZ.json

@ThisNoName

Te refieres a cadenas de conexión de base de datos, puntos finales de servicio, credenciales o cualquier cantidad de otras cosas que cambiarían de desarrollo-> puesta en escena-> producción.

Si está ejecutando varias instancias en el mismo entorno ( muy común fuera de la nube), necesita absolutamente la flexibilidad de las transformaciones web.config. Es bastante ridículo que Microsoft no cumpliera con este requisito de fábrica con el núcleo de dotnet, simplemente asumieron que todos estaban alojados en Azure y tenían una relación de 1-1 entre la instancia y el entorno.

Las variables de entorno realmente apestan fuera de la nube, ya que termina con una configuración separada de su aplicación, lo que dificulta la administración de las implementaciones.

El cambio principal aquí es que esos secretos nunca deben almacenarse en el control de código fuente y, en cambio, deben configurarse en el entorno mismo. Las transformaciones van en contra de las buenas prácticas porque asumen que usted comprende el objetivo de implementación en el momento de la publicación, lo cual no siempre es el caso (especialmente cuando tiene múltiples entornos). ¿Realmente necesita volver a implementar cuando cambia un ajuste de configuración para una de esas N implementaciones?

Ahora, la parte desafortunada es que con IIS, las variables de entorno deben configurarse en el archivo de configuración para que el grupo de aplicaciones pueda verlas. No creo que alguna vez tuvimos la intención de que las personas configuraran la configuración de toda la máquina en las máquinas de destino (aunque he visto a personas hacer eso).

@willapp ¿Por qué no usas appsettings.json ?

@willapp

M $ tiene la solución perfecta, pero la mayoría de la gente se quedó con el concepto de transformación web.config.

Esta es una forma en que puede tener varios sitios uno al lado del otro. Solo necesita lanzar el valor de su entorno en cualquier lugar fuera del directorio binario de IIS y leerlo / configurarlo desde program.cs

• IISRoot
  
  
  
  • MySiteDEV
  
  
  • compartimiento
    
    
    
    
    
    • appsettings.json
    
    
    
    • appsettings.DEV.json
    
    
    
    • appsettings.PROD.json
    
    
    
    • web.config
    
    
    
  
  
  • registros
  
  
  • env.DEV
  
  
  • MySitePROD
  
  
  • compartimiento
    
    
    
    
    
    • appsettings.json
    
    
    
    • appsettings.DEV.json
    
    
    
    • appsettings.PROD.json
    
    
    
    • web.config
    
    
    
  
  
  • registros
  
  
  • env.PROD
  
  

@davidfowl

¿Le está diciendo a la gente que es lamentable que el núcleo de ASP.NET no funcione bien con IIS? ¿Como arquitecto de Microsoft .NET Core?

El cambio de paradigma aquí con cualquier cosa Core es multiplataforma. IIS es claramente una utilidad de Windows, por lo que se deben esperar algunos problemas de crecimiento. Las soluciones, en un caso como este, deben esperarse y aceptarse a medida que avanzan las cosas. Haber tomado decisiones de diseño intencionales en Core para admitir una función de Windows habría sido contrario a la intuición, en mi opinión.

Editar para agregar:
Este es un pensamiento sobre si Core debería tener un mejor soporte listo para usar para IIS. La discusión sobre el uso de variables de entorno es una buena alternativa a pesar de ...

@davidfowl

Y esta es exactamente la diferencia entre la arquitectura empresarial y la PYME. Trabajo para un FTSE100 y sí, separar la implementación del código tiene sentido, pero también ejecuto varios sitios de forma independiente y es más fácil y rentable tener un solo servidor en el que alojo todos mis sitios. El uso de Web Deploy + Transforms es un mecanismo probado y comprobado para cambios en el código de entrega, simplemente funciona. No estoy diciendo que no haya mejores alternativas en algunos casos, pero Microsoft debería tener soporte continuo para las transformaciones sabiendo que la mayoría de los usuarios quieren estar familiarizados al migrar de .net framework a core.

Ahora tengo mi solución de antes en este hilo, así que estoy lo suficientemente feliz. Creo que dejaron caer la pelota un poco sin incluir esto como estándar.

@willapp

Creo que transform se basa en la idea de compilar desde la fuente y publicar por separado para cada entorno. Me alegro de que M $ lo haya dejado porque la alternativa es mucho más elegante.

Con la nueva configuración, solo publicas tu código una vez usando Release config. Todas las instancias en ejecución son copias binarias idénticas del original. La implementación debe ser una simple sincronización de archivos con el siguiente entorno DEV => TEST => Staging => PROD.

¿Le está diciendo a la gente que es lamentable que el núcleo de ASP.NET no funcione bien con IIS? ¿Como arquitecto de Microsoft .NET Core?

Estoy diciendo que la gente no piensa inmediatamente en el hecho de que se supone que las variables de entorno que se utilizan de esta manera son por proceso en lugar de por máquina. Históricamente, en Windows, la gente identifica las variables de entorno como en toda la máquina en lugar de por proceso y eso ha causado confusión. IIS 10 agregó soporte para agregar variables de entorno por grupo de aplicaciones. El módulo ASP.NET Core también admite la configuración de variables de entorno por proceso.

Aún así, esta capacidad ha estado ahí. Creo que sobre todo ha habido un cambio filosófico en el pensamiento aquí. No queremos hacer nada que facilite la especificación de secretos en el momento del desarrollo.

@challamzinniagroup buen resumen

Este es un pensamiento sobre si Core debería tener un mejor soporte listo para usar para IIS. La discusión sobre el uso de variables de entorno es una buena alternativa a pesar de ...

Correcto. El flujo de trabajo para configurar la información específica del entorno debe seguir estando en el entorno específico. La pregunta es cómo conseguirlo. ¿Es parte del despliegue?

Dicho todo esto, creo que estamos agregando soporte para esto en las herramientas en 2.2.

cc: @vijayrkn

@davidfowl

Cuando dice "Históricamente en Windows, la gente identifica las variables de entorno como en toda la máquina en lugar de por proceso", ¿se refiere a las variables de entorno de Windows, como en la línea de comandos SET?

Porque mi comprensión del "entorno" dentro del contexto central de .NET es solo una variable. De forma predeterminada, lee ASPNETCORE_ENVIRONMENT desde el sistema o web.config. Pero puede sobrescribirlo y obtenerlo de cualquier fuente según cualquier convención.

¿Hay algo intrínsecamente incorrecto en ese enfoque? Porque si la posición oficial del equipo de Microsoft .NET es no hacerlo, tendríamos que reconsiderarlo seriamente. Pero terminaría diciéndole a la gente que ejecute .NET core bajo IIS, pero desafortunadamente, no hay una manera fácil de configurar esas aplicaciones. Espero que ese no sea el caso.

Gracias.

@ThisNoName

Cuando dice "Históricamente en Windows, la gente identifica las variables de entorno como en toda la máquina en lugar de por proceso", ¿se refiere a las variables de entorno de Windows, como en la línea de comandos SET?

Sí, esto es exactamente de lo que se trata este hilo. (Ver aquí ). Como dice David, estos pueden ser por proceso, pero en mi experiencia, la mayor parte de la documentación en dotnet core asume que los configura a nivel de máquina, por lo tanto, tenemos este problema en el que no puede implementar fácilmente varias instancias de aplicaciones en el mismo servidor, ya que recogerán los mismos valores de entorno, por lo que no podrá distinguir entre dev / staging / prod.

El hecho de que IIS10 admita configurarlos por grupo de aplicaciones es genial ... si tiene Server 2016 disponible. Estoy corriendo el 2012, así que esta no es una opción. Una vez más, mi problema no es que Microsoft esté tratando de mover las cosas en una mejor dirección, pero abandonar el soporte 'heredado' para algo que mucha gente daba por sentado al implementar aplicaciones ASP.NET me parece un error. Por supuesto, introduzca nuevos patrones y anime a las personas a adoptarlos, pero no elimine el comportamiento heredado hasta que esté seguro de que pocas personas lo necesitan. De lo contrario, todo lo que está haciendo es poner barreras para los clientes que desean un núcleo dotnet pero encuentran que la ruta de migración es demasiado dolorosa.

@willapp

Esa es solo la configuración predeterminada lista para usar. Puede leer y configurar el entorno de la forma que desee. Al menos eso es lo que tengo entendido, a menos que alguien señale algún defecto grave en este enfoque.

   public class Program   {
        public static void Main(string[] args)   {
            CreateWebHostBuilder(args).Build().Run();
        }

        public static IWebHostBuilder CreateWebHostBuilder(string[] args)   {
               return WebHost.CreateDefaultBuilder(args)
                .UseEnvironment(ReadEnvFromWherever())
                .UseStartup<Startup>()
        }

        private string ReadEnvFromWherever() { 
              // Get and return whatever by your own convention
              return "DEV";
        }
    }

@ThisNoName

La falla grave es, ¿cómo se logra que el método "ReadEnvFromWherever" devuelva un valor diferente cuando se implementa mediante Web Publish desde VSTS, según la configuración de la solución? Supongo que podría usar directivas de preprocesador (#if RELEASE ...) pero eso se siente bastante sucio.

En el "viejo mundo" (marco completo de ASP.NET) usted crea un perfil de publicación, y parte de eso es seleccionar una configuración de solución para construir. Basado en esa configuración, luego aplicó una transformación de configuración que le permitió especificar una configuración diferente en función de si estaba publicando en dev / staging / prod.

Acepto que este flujo de trabajo no encaja en una canalización de CI moderna, en la que se toma un solo paquete de compilación y lo empuja a través de cada entorno; en este caso, desea algo como la canalización de versiones de VSTS para inyectar la configuración en el momento de la implementación, o primero su instancia de servidor con las variables de entorno correctas, en cuyo caso simplemente suelte el paquete en la caja y funcionará automáticamente por arte de magia. Sin embargo, una vez más, creo que muchas PYMES y bandas unipersonales no están en este lugar y quieren un proceso de implementación desde Visual Studio que produzca el resultado que desean.

Solo para agregar que esto también es importante para implementar proyectos pequeños en plataformas de hospedaje compartido que se ejecutan en IIS y tradicionalmente ofrecían hospedaje ASP.NET. No tienen ninguna facilidad para establecer variables de entorno por sitio web a través de sus paneles de control de alojamiento, por lo que el único enfoque realista es usar transformaciones y web.config .

Sin embargo, parece que todo esto tendrá una solución decente en la próxima versión, y con el soporte VS integrado un poco más adelante. Con suerte, eso ayudará a las personas con flujos de trabajo existentes que dependen de esta funcionalidad hasta que los proveedores de alojamiento y los sistemas heredados puedan actualizarse o mejorarse.

@willapp

Por convención. Si sigue el ejemplo que publiqué anteriormente, puede leer env.DEV desde la carpeta principal y usar la extensión de archivo como variable de entorno. Pero puede seguir cualquier convención, como nombrar la raíz de su aplicación como MySiteDEV, MySitePROD, etc. y analizar el nombre de la carpeta para obtener el nombre del entorno.

Si su código varía según el entorno, puede leer el valor del entorno de IHostingEnvironment .EnvironmentName

Esto no es una diferencia con el núcleo de .NET que lee ASPNETCORE_ENVIRONMENT desde la variable del sistema o web.config.

@ThisNoName

Pero, ¿cómo se coloca _env.DEV_ en la carpeta principal, además de copiarlo manualmente? Veo lo que está tratando de decir, pero creo que se está perdiendo el punto: solía haber una solución lista para

Entiendo _por qué_ se eliminó (porque hay mejores alternativas si tiene un proceso de CI decente), pero creo que fue bastante miope cuando muchos usuarios que migran aún lo querrían.

@willapp

Lo copia una vez durante la configuración inicial y todas las implementaciones futuras van a la carpeta bin. Sin recompilar, sin publicar, sin transformar. Así debe ser, se necesitan 3 líneas adicionales de código, ¿y qué? Es M $. Hasta hace 3 meses, ni siquiera se podía llamar a Active Directory en .NET Core.

@ThisNoName ¿

Su sugerencia no tiene ningún sentido en el contexto de una implementación web en una plataforma de alojamiento compartido. Ni siquiera estoy seguro de lo que está argumentando a favor o en contra, la funcionalidad se agregará en la próxima versión de ASP.NET Core para que se pueda especificar una variable de entorno en el perfil de publicación, sin necesidad de ninguna transformación ni nada. Tampoco hay necesidad de enfoques no estándar con nombres de carpeta, que pueden estar o no bajo su control.

@willapp , @svallis
La solución que publiqué un poco más arriba funciona en algunos casos. Puede extraer la URL y establecer el entorno en función de eso. En cualquier entorno de alojamiento, tiene el control total de sus URL. Me doy cuenta de que esto sigue siendo "pirateado" y una solución alternativa, pero generalmente debería funcionar la mayor parte del tiempo. En el caso de mi empresa de alojamiento, la URL que recibía era localhost: port base ("127.0.0.1:7777"), por lo que resultó no ser ideal para mí. Pero también tengo la capacidad de establecer rutas de carpeta raíz en mis diversos entornos, ya que las tengo configuradas como subdominios, y extraer la ruta de la aplicación raíz también es bastante simple:

        public static string DetectAndSet(this IHostingEnvironment env, ILogger logger)
        {
            switch (env.ContentRootPath)
            {
                case "h:\\root\\home\\www\\api":
                    env.EnvironmentName = EnvironmentName.Production;
                    break;
                case "h:\\root\\home\\www\\api-staging":
                    env.EnvironmentName = EnvironmentName.Staging;
                    break;
                default:
                    env.EnvironmentName = EnvironmentName.Development;
                    break;
            }

            logger.LogInformation($"Application root path discovered as '{env.ContentRootPath}'. Environment set to '{env.EnvironmentName}'");

            return env.EnvironmentName;
        }

La elección de si el entorno debe determinarse o no dentro del código, en el momento de la implementación o predeterminado directamente en el entorno antes de tiempo no es la discusión que estoy tratando de abordar; simplemente estoy ofreciendo una solución razonable para esas PYME / personas que tienen un control de alojamiento limitado y necesitan una solución. En mi caso, este es un código de una vez y se olvida, exactamente lo que necesito.

Más adelante, puedo extraer fácilmente valores de configuración de un archivo appsettings.json sin necesidad de transformaciones, simplemente incluyendo:

"{configName}.{environmentName}": "{value}"

en el archivo de configuración y con 3 entradas por configuración, una para cada entorno. Solo tengo una cantidad muy pequeña de configuraciones en este archivo, por lo que la duplicación no es un gran problema.

¡Espero que esto ayude!

@challamzinniagroup Es más fácil usar la ruta de carpeta relativa y el nombre por convención.

@svallis Todo el concepto es publicar una vez y desplegar a nivel binario. Entonces, incluso si puede establecer una variable por perfil de publicación, ese no es el camino a seguir.

@ThisNoName Para usted, tal vez sea más fácil, pero no asuma tales cosas por los demás. En mi caso, tengo configuraciones para borrar los directorios de destino antes de publicar / copiar, por lo que, para su solución, tendría que volver a cargar cada archivo de entorno manualmente, cada vez. Definitivamente, no es más fácil.

@challamzinniagroup De acuerdo. Cada situación es diferente. La conclusión es que el entorno es solo una variable, puede controlarlo como mejor le parezca, en lugar de esperar a que Microsoft ofrezca la mejor opción. Y lo que sea que surja, es solo otra solución basada en convenciones de todos modos: leer algún valor del sistema o web.config y establecer el entorno.

Por cierto, todavía puedes usar la convención. No se puede decir que la configuración de la aplicación tenga que usar una sola palabra intermedia y que la puesta en escena / producción no tenga significados especiales. Puede hacer algo como esto fácilmente y pasar el nombre de la carpeta para que coincida.

appsettings.api.json
appsettings.api-staging.json

Con la solución basada en convenciones, puede iniciar nuevas instancias sin tener que volver a compilar y / o volver a publicar.

@vijayrkn, ¿ podría dar más detalles sobre el uso de pubxml?
Actualicé mi SDK a 2.1.302 (x64) cambié mi pubxml pero no puedo ver ninguna diferencia en web.config publicado.

@wggley : la corrección no está disponible en 2.1.302. Debería estar disponible en la próxima versión.

Puede probar la versión de vista previa del cli que contiene la solución desde aquí: https://dotnetcli.blob.core.windows.net/dotnet/Sdk/release/2.1.4xx/dotnet-sdk-latest-win-x64.exe

Avíseme si tiene algún problema con la versión de vista previa anterior.

Gracias @vijayrkn . Esperaré el próximo lanzamiento e intentaré usarlo en una nueva publicación.
Me gustaría señalar que la solución de @frankhoffy funcionó para mí como un encanto:
https://stackoverflow.com/questions/31049152/publish-to-iis-setting-environment-variable/36836533#36836533
Busque la primera respuesta (la respuesta más votada).

La compatibilidad con la transformación de la configuración web durante la publicación ahora está disponible en la vista previa 2.21 https://www.microsoft.com/net/download/dotnet-core/2.2

@vijayrkn, ¿hay una muestra básica en alguna parte? Sería genial señalar a las personas el equivalente de hello world utilizando una transformación básica que establece ASPNETCORE_ENVIRONMENT.

Para configurar ASPNETCORE_ENVIRONMENT, los usuarios pueden configurar la propiedad msbuild '$ (EnvironmentName)'. Agregaré una muestra que muestra cómo configurar otras variables env usando transformaciones web.config.

Aquí hay un repositorio de muestra: https://github.com/vijayrkn/webconfigtransform

Léame tiene detalles sobre cómo funciona esto:
https://github.com/vijayrkn/webconfigtransform/blob/master/README.md

¡Espero que esto ayude!

@Eilon - Podemos cerrar este problema. Esto está arreglado y disponible en la última vista previa.

@vijayrkn ¿ No está claro cómo configurar la configuración de publicación para establecer el entorno desde el cuadro de diálogo Configuración de publicación? ¿Qué se puede cambiar realmente en este cuadro de diálogo para distinguir un sitio de ensayo de un sitio de producción, si ambos sitios se están implementando en el mismo servidor?

Este aspecto del núcleo de .NET parece muy complicado. Debe ser mucho más fácil especificar el entorno por carpeta. Una variable de entorno de servidor completo no puede funcionar en absoluto para nuestra situación. No todo el mundo puede ejecutar sus sitios de ensayo en servidores diferentes a sus sitios de producción.

La configuración es por aplicación.

Lo siento, pero eso realmente no responde a mi pregunta. Quizás estoy malinterpretando algo.

Hay algo de pseudo documentación aquí https://github.com/vijayrkn/webconfigtransform/blob/master/README.md ( @vijayrkn necesitamos

@vijayrkn ¿Cuánto apoyo hay para esto en el cuadro de diálogo de publicación?

Actualmente, el cuadro de diálogo de publicación no tiene soporte para configurar los entornos de publicación, pero los entornos se pueden configurar manualmente en el perfil de publicación o se pueden aplicar transformaciones específicas.

@ nmg196 : si solo desea establecer el 'ASPNETCORE_ENVIRONMENT' en web.config, todo lo que tiene que hacer es agregar el nombre del entorno al publishprofile.

ejemplo:
https://github.com/vijayrkn/webconfigtransform/blob/master/Properties/PublishProfiles/FolderProfile.pubxml#L18

Para escenarios avanzados (además de configurar la variable de entorno ASPNETCORE_ENVIRONMENT), se pueden aplicar transformaciones web.config como se menciona en la documentación anterior.

@davidfowl : Angelos tiene un elemento para documentar el soporte de transformación web.config.

@vijayrkn ¿Cómo usarlo en CI / CD de TFS? No pude usar la publicación dotnet con p: CustomTransformFileName en TFS

Puede pasar esta propiedad de msbuild a dotnet publish.

Puede consultar este ejemplo aquí: https://github.com/vijayrkn/webconfigtransform/blob/master/publish.cmd

Esto pasa la propiedad CustomTransformFileName a dotnet publish

dotnet publish /p:Configuration=Release /p:EnvironmentName=Staging /p:CustomTransformFileName=custom.transform

@vijayrkn
He leído su documentación y no puedo hacer que web.config se transforme. He probado básicamente todos los comandos que tiene en el archivo readme.md y ninguno de ellos da como resultado que se realice la transformación.

Sin embargo, he podido escribir un script de PowerShell que usa Microsoft.Web.XmlTransform.dll para realizar la transformación por separado de la operación de publicación.

Mi pregunta es ¿qué versión de msbuild y dotnet estás usando?
Estoy usando:
dotnet --versión 2.1.104
dotnet msbuild -versión 15.6.84.34536

Gracias

@ stephenarsenault1
Debe instalar cualquiera de las compilaciones desde aquí para que se encienda la función: https://www.microsoft.com/net/download/dotnet-core/2.2

Más reciente: https://www.microsoft.com/net/download/thank-you/dotnet-sdk-2.2.100-preview3-windows-x64-installer

@davidfowl escribió:

Hay algo de pseudo documentación aquí https://github.com/vijayrkn/webconfigtransform/blob/master/README.md ( @vijayrkn necesitamos

@vijayrkn ¿Cuánto apoyo hay para esto en el cuadro de diálogo de publicación?

¿Sabe si esto se agregó alguna vez a los documentos reales? Si es así, ¿tiene el enlace, por favor?

Ahora pasamos al uso de <EnvironmentName> en nuestros perfiles de publicación. Sin embargo, sería bueno tener una interfaz de usuario además de esto para que sea más visible. ¿Supongo que esto vendrá en una fecha posterior?

Creo que es un cambio importante habilitar de forma predeterminada las transformaciones web.config en dotnet publish. Después de instalar .NET Core SDK 2.2.101, rompió nuestro escenario de CI / CD. Nuestra canalización está configurada para crear artefactos publicados usando dotnet publish solo una vez para cualquier versión ( regla de compilación única ), la transformación se aplica automáticamente en la implementación real (realizada por Octopus). No pude encontrar ninguna mención en la documentación sobre este cambio. Pasé un poco de tiempo tratando de averiguar cuál era el motivo de los bloques de configuración duplicados en web.config después de la implementación. Aparentemente, la transformación se aplicó dos veces: por dotnet publish y por la herramienta de administración de versiones.

Después de deshabilitar las transformaciones web.config con la configuración <IsTransformWebConfigDisabled>true</IsTransformWebConfigDisabled> , TransformWebConfig también se saltó (junto con TransformXml), lo que da como resultado que las variables %LAUNCHER_PATH% y %LAUNCHER_ARGS% no se reemplacen durante el proceso de publicación. ¿Existe una configuración para controlar estos pasos de forma independiente?

¿Funciona esto en una aplicación de consola con el archivo App.Config?

¿Podemos ver un ejemplo?

@dmitryshunkov puede establecer $ (RunXdt) en falso para omitir la ejecución de la transformación Xml personalizada.

@auserx : si es un proyecto de estilo sdk, entonces debería funcionar.