Aspnetcore: Habilitar transformações web.config para projetos AspNetCore no VS

FWIW, eu concordo. Só precisamos deixar claro que é para as configurações do IIS. A outra coisa é o fato de que deixamos de ter um web.config padrão no modelo para que isso precise ser descoberto.

/ cc @sayedihashimi

Isso é apenas para o IIS? Acho que o ponto crucial da questão é o uso da variável ASPNETCORE_ENVIRONMENT fullstop para permitir que um site saiba em que ambiente está.

Acho que um cenário bastante comum é que vários ambientes de teste / controle de qualidade sejam hospedados na mesma caixa na mesma instância do IIS. Pode haver 3 equipes, todas com seus próprios "ambientes" nos quais podem implantar para testar seu código (digamos, implantar um branch específico), mas todas estão usando a mesma caixa.

Se pegarmos algum código de exemplo de como appsettings.json é alternado por ambiente:

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(); }
O cenário acima não vai funcionar porque a variável de ambiente abrange todo o sistema. Poderia ser IIS, nginix etc. sentado na frente dele e a troca de configuração não vai funcionar.

Na maioria das vezes eu vi o acima aparecer, surgiram sugestões para usar o Docker ou usar algo como Puppet / Chef para gerenciar a configuração do aplicativo, então não há appsettings. {Env} .json, mas acho que isso torna o caminho completo framework MVC muito mais difícil.

@mindingdata Você pode realmente controlar a lógica que determina de onde vem o ambiente em seu Program.cs . A variável de ambiente é apenas uma forma de declarar isso (a forma principal). Se você quiser fazer outra coisa com base em algum arquivo mágico ou hora do dia, chame UseEnvironment(environmentName) no WebHostBuidler

Só para esclarecer, isso é absolutamente apenas para a configuração do IIS. O sistema de configuração JSON atual para configurações de aplicativos é muito bom e eu o recomendo totalmente.

Para complicar ainda mais: descobri que, quando uso o web.config para tentar substituir a configuração do ambiente do sistema, ele simplesmente não funciona. Quando minha configuração de ambiente de sistema está definida como "Desenvolvimento" e tento defini-la como "Produção" usando o web.config (como abaixo), o aplicativo ainda pensa que está sendo executado em Desenvolvimento. (Aplicativo ASP.NET Core em execução no IIS).

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

Eu acho que este é o lugar certo. Eu construo uma demonstração N-tier e não consigo descobrir como injetar IHostingEnvironment em meu projeto de camada de acesso a dados. Esse projeto é onde eu acesso meu banco de dados e a única maneira de obter a string de conexão para essa camada foi sobrescrever o método OnConfiguring por uma string mágica do arquivo de configuração.

Eu também olhei para slow-cheetah, mas parece que vai ao redor do método atual de "Depurar, Liberar" ou "Desenvolvimento, Produção" dependendo se você está usando o método VS ou as variáveis ​​de ambiente.

Deve haver informações que estou perdendo. A MS não pode querer que todos criem aplicativos de camada única.

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

então, houve algum progresso nisso?

devemos ser capazes de definir o env na configuração de um aplicativo sem recorrer a magia

Sim, eu gostaria de algum progresso nisso também. Atualmente não tenho ideia de como devo publicar projetos separados na mesma caixa usando diferentes variáveis ​​de ambiente.

Acabei encontrando uma solução bastante simples. No arquivo appsettings.json principal, eu especifico meu ambiente desejado:

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

Em Program.CS, eu construo uma IConfiguration e defino o nome do ambiente com o valor de 'ActiveEnvironment', antes de carregar o arquivo de configuração específico do ambiente.

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, ao publicar em ambientes diferentes, o 'ActiveEnvironment' precisa ser alterado de acordo.

@DaleMckeown Eu ia fazer algo semelhante, mas tenho uma dúvida sobre sua implementação. Vejo que você está usando o Microsoft.AspNetCore.WebHost para criar a configuração padrão. Essa abordagem ainda se aplica a um aplicativo de console sem componentes da web?

@Swazimodo Eu não tentei essa solução no contexto de um aplicativo de console, então não tenho certeza. A melhor aposta é ver se há uma maneira alternativa de definir as variáveis ​​de ambiente para aplicativos de console.

Cuidamos disso de uma maneira diferente. Nós configuramos nosso agente de construção para levar
o arquivo de configurações específicas do ambiente e sobrescrever o arquivo de configurações raiz
com isso. Nossa construção cria um arquivo zip separado para cada ambiente que
implantar para.

Em quinta-feira, 26 de outubro de 2017 às 12h48, Dale Mckeown [email protected]
escreveu:

@Swazimodo https://github.com/swazimodo Eu não tentei esta solução
no contexto de um aplicativo de console, então não tenho certeza. Melhor aposta é para
veja se existe uma maneira alternativa de definir as variáveis ​​de ambiente para
aplicativos de console.

-
Você está recebendo isto porque está inscrito neste tópico.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/aspnet/Home/issues/2019#issuecomment-339728441 ou mudo
o segmento
https://github.com/notifications/unsubscribe-auth/AAx4bT20JSb0XSzNBIAiiubq9mTVKbW5ks5swLf6gaJpZM4NMx25
.

Parece que todas as soluções requerem algum tipo de ajuste de pós-construção / publicação? Acabei deixando cair um arquivo de texto vazio na raiz do aplicativo e passei isso como ambiente. Eu perdi alguma coisa?

Concordo totalmente com a primeira postagem. Tem um design bastante flexível, mas no final acabou sendo muito difícil de automatizar. Por exemplo, tenho um aplicativo que publico no IIS em outro servidor. Também é executado no IIS local (via publicação de pasta). Portanto, configurei o ambiente de desenvolvimento em web.config. Mas então eu preciso mudar para Produção ou qualquer outra coisa durante a publicação. Tarefa bastante comum, eu acho. Eu acredito que é impossível, certo? Tenho que editar manualmente o web.config em servidores remotos.

Idealmente, a configuração do ambiente deve ser suportada por meio de "publicação dotnet" (para qualquer destino de publicação):

dotnet publish ... -environment=Production

dotnet publish poderia pesquisar web.%Enviroment%.config (Web.Production.config, Web.Development.config) arquivos e mesclá-los (transformar) com web.config. No final, teríamos o valor correto de ASPNETCORE_ENVIRONMENT:

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

@ evil-shrike dê uma olhada em https://github.com/nil4/dotnet-transform-xdt para as transformações de configuração de tempo de construção / publicação.

Um caso de uso, talvez. Preciso que os logs sejam gravados em. \ App_Data porque meu executor de aplicativo tem acesso de leitura / gravação a tudo em. \ App_Data, mas só pode ler tudo em. \. Eu uso web deploy e gostaria de poder implantar um web.config como este com a pasta logs em 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>

Você pode perguntar, por que não apenas colocar essas configurações em um arquivo web.config em vez de web.release.config? Bem, processPath=".\<executable>.exe" não é onde reside o executável quando estou desenvolvendo localmente no IIS Express. Portanto, recebo o bom e velho erro "HTTP Error 502.5 - Process Failure".

Automatizamos nossas compilações usando Jenkins e nossa forma existente de fazer a configuração vars por ambiente em projetos NetFramework é por meio de transformações web.config. Então pensamos que poderíamos fazer isso também no dotnet.

Acontece que msbuild ainda é compatível com aspnet core csproj para fazer transformações web.config!

Podemos adicionar a tarefa de publicação TransformXml no csproj Asp.Net Core:

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

Adicione os destinos de transformação específicos:

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

Faça algumas transformações, por exemplo na variável ASPNETCORE_ENVIRONMENT em 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 publicar:

msbuild Test.csproj /t:ConfigDev

"Deixe-me prefixar dizendo que não sou fã de web.config, mas a experiência de publicação de aplicativos AspNetCore no IIS é muito pobre."

Eu não poderia concordar mais com este tópico.

Após a simplicidade das transformações de configuração no ASP.Net regular, toda essa dependência de uma variável ASPNETCORE_ENVIRONMENT em toda a

Mesmo os próprios exemplos da Microsoft dizem que podemos usar, digamos, um arquivo _appsettings.Production.json_, apenas adicionando esta linha ...

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

... mas não dá atenção ao NOME da configuração que escolhemos. Portanto, mesmo depois de escolher minha configuração de produção, ele ainda tentará abrir appsettings.development.json. E não, eu não quero ter que editar manualmente a variável ASPNETCORE_ENVIRONMENT cada vez que eu publicar em um ambiente diferente. Isso é apenas procurar encrenca.

Ainda estou para ver um exemplo simples e funcional do uso de arquivos _appsettings.XXXX.json_.
Mal posso esperar para que tudo isso finalmente termine. (Suspirar...)

Sim, por favor ,

Acabei de implantar meu primeiro site de núcleo dotnet de produção e agora enfrento o problema de que não posso facilmente ter uma instância de teste no mesmo servidor porque não sei como publicar meu aplicativo na mesma caixa sem que ele pegue o configurações de produção.

Acho que vou tentar a solução @DaleMckeown por enquanto, acho que funcionará, mas parece uma solução alternativa, em vez de uma solução. As variáveis ​​de ambiente são ótimas, mas SOMENTE se você tiver uma proporção de 1-1 de servidores para ambientes, e fora da empresa, duvido que isso aconteça com frequência.

@willapp Minha sugestão é definitivamente uma solução alternativa. Mas funciona - eu tive várias versões do mesmo aplicativo em execução no mesmo servidor por um tempo e não tive nenhum problema.

Apenas lembre-se de alterar a configuração 'ActiveEnvironment' antes de publicar e você estará bem.

Estou enfrentando exatamente o que dkent600 mencionou:

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

não funciona no servidor de produção. O aplicativo continua usando valores "appsettings.Development.json", que, em última análise, anula os benefícios da transformação xml durante a publicação.

Vou tentar a solução alternativa sugerida por DaleMckeown.

a única maneira razoável de alterar ASPNETCORE_ENVIRONMENT é usando web.config

Na verdade, não. Se você precisa executar várias instâncias do mesmo site na mesma máquina, aqui está uma maneira muito mais simples

• MyCoreSite
  
  
  
  • bin
  
  
  • Histórico
  
  
• env.Whatever

Aponte seu aplicativo IIS para bin e em program.cs

.UseEnvironment(ReadEnvExtensionFromParentFolder())

É isso. Você pode ter quantos sites quiser, implantar no bin sem se preocupar com a transformação e até mesmo alternar o ambiente renomeando env.Whenver.

Eu voto positivo. Tenho regravações de URL configuradas para o servidor de produção que não funcionam no ambiente de teste. Não encontrei uma maneira de publicar para selecionar o arquivo web.config certo para implantação, tenho que copiá-lo manualmente.

Dê uma olhada em https://github.com/nil4/xdt-samples/ e a ferramenta CLI para aplicar transformações no momento da publicação .

Existe algum progresso nisso? Já se passaram 13 meses desde o relatório inicial, 2.1.0 está aqui agora, e as coisas ainda estão muito ruins com a hospedagem IIS tradicional. As coisas funcionam perfeitamente se você estiver usando o Azure, mas atualmente não é uma opção para grande parte dos sites que estou hospedando.

Parece que para a hospedagem IIS tradicional seria benéfico definir o ambiente desejado na linha de comando (como @ evil-shrike descrito acima) e também em quaisquer .pubxml perfis de publicação. Como @davidfowl disse, deveria ficar claro que isso funcionaria apenas usando web.config e IIS, mas isso certamente ainda cobre uma parte substancial da base de instalação.

No momento eu tenho uma solução muito frágil usando Microsoft.DotNet.Xdt.Tools e web.config tradução, mas requer uma configuração de compilação por ambiente para funcionar e acabou de quebrar após a atualização para v2.1.0.

Seria ótimo saber se existem planos nesta área e, em caso afirmativo, quais são? Se não houver planos, ou se eles estiverem muito distantes, então certamente haverá uma solução provisória melhor do que os métodos frágeis / semiamanuais que somos forçados a empregar atualmente? Especialmente para implantação para controle de qualidade e teste, eu realmente gostaria de poder apenas pressionar um botão no VS e saber que a coisa certa está acontecendo, e não ter que depender de conhecimento de cabeça e processos manuais.

Não temos planos atualmente, mas esta ferramenta https://github.com/nil4/xdt-samples/ por @ nil4 parece muito boa.

@svallis , você já experimentou?

É a principal coisa que as pessoas desejam definir o ambiente?

@davidfowl Sim, minha solução atual é usar a ferramenta que você vinculou, mas para um projeto com vários destinos para publicar nele, é necessária uma configuração de construção por ambiente. Você precisa das diferentes configurações de construção para ter algo em que se agarrar na configuração csproj e, para meus propósitos, geralmente é uma relação de 1 para 1 com seus ambientes. Por exemplo:

• Configuração de compilação: Debug = Ambiente: Desenvolvimento
• Configuração de compilação: Staging = Environment: Staging
• Configuração de compilação: Versão = Ambiente: Produção

Para os dois últimos, tenho então o web.{Build configuration}.config e appsettings.{Environment}.json , e o web.{Build configuration}.config é literalmente apenas um XDT para dizer ao web.config para terminar com o variável de ambiente ASPNETCORE_ENVIRONMENT apropriada. Então, por exemplo, continuando o exemplo acima, web.Release.config parece com isto:

<?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>

Na verdade, tudo funciona muito bem na linha de comando. Executando dotnet publish -c Staging ou qualquer outra coisa produz uma pasta com a saída correta e web.config transformado conforme necessário. Parece que poderia ser simplificado. Se houvesse um -iisenvironment switch em dotnet publish que fizesse isso por nós, e depois fosse exposto como uma caixa de texto simples na publicação do VS, removeria a necessidade de gerenciar configurações de compilação, XDTs, etc manualmente para situações de hospedagem IIS tradicionais.

De dentro do VS, atualmente parece problemático. No momento, não podemos publicar de forma alguma a partir do VS e, mesmo quando funcionou na v2.0.0, tivemos que selecionar manualmente a configuração de compilação correta antes de publicar.

@davidfowl Da minha perspectiva, idealmente, gostaria de definir o ambiente como parte do perfil de publicação ao usar o Web Deploy.

Eu concordo com isso, uma opção de publicação seria o ideal. Não estou nem usando a solução alternativa descrita por @svallis, pois prefiro publicar por meio do IDE do VS e não pela linha de comando.

@willapp A solução que estou usando funciona no Visual Studio, mas tenho outros problemas com a solução que estou testando e que estão causando problemas no VS (https://github.com/aspnet/Home/issues/3190) . Desculpe se não deixei isso claro. É tudo configurado usando ferramentas no csproj , que tanto a linha de comando quanto o VS devem respeitar.

Finalmente tentei a ferramenta sugerida acima por @davidfowl e

Basta seguir as instruções aqui https://github.com/nil4/dotnet-transform-xdt na seção "Ferramenta de nível de projeto" (já que não estou no 2.1.0 ainda). Tive de criar um Web.config padrão, pois não o tinha (apenas copiei de um que o VS gera quando você implanta), depois criei um Web.Debug.config com uma transformação para definir ASPNETCORE_ENVIRONMENT para Desenvolvimento e ei presto! Ele implanta a configuração transformada e o site agora é inicializado corretamente.

Seria bom se o suporte para isso fosse oficializado, mas por enquanto isso está funcionando.

@davidfowl O link que você apontou requer publicação usando a linha de comando. Eu gostaria de publicar usando a ferramenta VS GUI. Não quero que meus desenvolvedores precisem instalar ferramentas cli para publicar o projeto. Não há como especificar ASPNETCORE_ENVIRONMENT em web.config se as transformações não forem suportadas. Vendo quantos votos positivos esse problema tem, ele deve ir para o backlog.

@ orobert91 VS é apenas uma GUI envolvida nas ferramentas de linha de comando. Estou usando com sucesso https://github.com/nil4/xdt-samples/ para transformar web.config durante a publicação de dentro do VS. Se você configurá-lo corretamente para o seu projeto, ele se transformará corretamente na linha de comando e no IDE.

@svallis Na verdade, interpretou mal a documentação. Resolvi meu problema com a tarefa de cópia simples:

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

Há uma propriedade msbuild que publica honras para o nome do ambiente -

$ (EnvironmentName)

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

Agora, quando esta propriedade é definida, tudo o que fazemos é criar appsettings.$(EnvironmentName).json e adicionar as informações da string de conexão a esse arquivo (se solicitado).

A partir de agora, quando esta propriedade é definida durante a publicação, também podemos atualizar o web.config publicado para ter a seguinte entrada também:

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

Isso funcionaria para a maioria dos cenários mencionados aqui?

Para os cenários fora da configuração de environmentVariable, veremos a viabilidade de portar as transformações web.config ( Xdt ) para projetos principais.

Eu descobri uma solução que parece cobrir os cenários de que preciso - gostaria de postá-la aqui, caso seja útil para mais alguém.

No meu caso, tenho meu ambiente de desenvolvimento localmente e os ambientes de teste e produção em um servidor remoto (mesmo servidor). Consegui extrair o url do aplicativo de IApplicationBuilder e usá-lo em uma instrução switch para definir o EnvironmentName .

Parece muito menos "alternativo" do que algumas das outras soluções oferecidas, mas certamente se resume à preferência.

Em Startup.cs :

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

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

O método acima é uma extensão que criei com base na coleção de propriedades de IApplicationBuilder . O método de extensão (e a classe) são assim:

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 isso possa ser útil para as pessoas (nos casos em que uma transformação web.config não é desejável).

Felicidades!

Estou marcando esse problema como uma discussão porque nenhum recurso / correção relacionado a isso está planejado no momento. Se as pessoas ainda tiverem solicitações de recursos específicos, registre os problemas para eles e priorizaremos.

Não fiquei muito satisfeito com as soluções alternativas que vi neste tópico, então optei por uma abordagem diferente. Tropecei neste tópico Stack Overflow: https://stackoverflow.com/questions/31049152/publish-to-iis-setting-environment-variable/36836533#36836533. Ele fala sobre como modificar ApplicationHost.config no servidor como um local para armazenar a variável ASPNETCORE_ENVIRONMENT.

Nossos servidores IIS internos são gerenciados por nossa equipe de operações, portanto, os desenvolvedores de nossa organização não criam esses sites. A equipe de operações usa um script PowerShell para criar esses sites. Eu apenas pedi que eles modificassem esse script para que ele também fizesse as alterações relevantes em ApplicationHost.config no momento em que o site fosse provisionado. Agora posso simplesmente implantar lá e não me preocupar em gerenciar o ambiente .NET Core. Funcionou bem para nossa situação.

Eu acho que em um verdadeiro ambiente DevOps, você provavelmente usaria o Azure de qualquer maneira, o que torna muito fácil definir a variável de ambiente.

Com o Sdk mais recente, você pode simplesmente passar a propriedade msbuild $(EnvironmentName) & o conjunto de ferramentas se encarregará de definir ASPNETCORE_ENVIRONMENT para este valor.

por exemplo: Se EnvironmentName estiver definido como staging, web.config terá a seguinte entrada:

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

PR com a correção:
https://github.com/aspnet/websdk/pull/377

@vijayrkn Parece um começo promissor. Isso eventualmente terá suporte integrado aos perfis de publicação / publicação do VS WebDeploy, etc?

No momento, não temos uma IU no VS para fazer essa seleção de nome de ambiente, mas se isso for adicionado ao arquivo de projeto ou ao pubxml, tanto a publicação do VS quanto a linha de comando irão honrá-la.

Estaremos analisando a adição de suporte à interface do usuário para isso também.

@vijayrkn Esta é apenas uma solução para aqueles que publicam com um arquivo web.config - correto?

@vijayrkn Sim, obter suporte no formato pubxml seria o momento em que isso se tornaria útil para o nosso caso de uso. Nesse ponto, poderíamos descartar todo o material de transformação XML e apenas especificar as strings de ambiente apropriadas em cada pubxml . O suporte à interface do usuário pode vir em uma data posterior, mas isso seria apenas a cereja do bolo.

@challamzinniagroup - Não, você não precisa de um web.config para esta funcionalidade.
Tudo o que você precisa fazer é adicionar o seguinte ao arquivo pubxml e as ferramentas de publicação cuidarão do resto.

<EnvironmentName>YourCustomEnvironment</EnvironmentName>

@challamzinniagroup , @vijayrkn

A menos que você tenha alguma configuração que só pode ser feita em web.config e deve ser transformada entre o ambiente, caso contrário, deixe o web.config sozinho. Com 2 linhas de código, você pode ler variáveis ​​de ambiente de qualquer lugar. E você não precisa de nenhum ajuste no perfil de publicação ou código publicado, apenas uma lista de appsetting.XYZ.json correspondentes

@ThisNoName

Você quer dizer strings de conexão de banco de dados, terminais de serviço, credenciais ou qualquer outra coisa que mudaria de dev-> staging-> production.

Se você estiver executando várias instâncias no mesmo ambiente ( muito comum fora da nuvem), você absolutamente precisa da flexibilidade das transformações web.config. É muito ridículo que a Microsoft não tenha atendido a esse requisito fora da caixa com o núcleo dotnet, eles apenas presumiram que todos estavam hospedando no Azure e tinham um relacionamento 1-1 entre a instância e o ambiente.

As variáveis ​​de ambiente são realmente ruins fora da nuvem, já que você acaba com a configuração separada do seu aplicativo, tornando mais difícil gerenciar as implantações em ponto final.

A principal mudança aqui é que esses segredos nunca devem ser armazenados no controle de origem e, em vez disso, devem ser configurados no próprio ambiente. As transformações vão contra as boas práticas porque pressupõem que você entenda o destino da implantação no momento da publicação, o que nem sempre é o caso (especialmente quando você tem vários ambientes). Você realmente precisa reimplementar ao alterar uma definição de configuração para uma dessas N implantações?

Agora, a parte infeliz é que, com o IIS, as variáveis ​​de ambiente precisam ser definidas no arquivo de configuração para que o pool de aplicativos possa vê-las. Acho que nunca pretendemos que as pessoas definam a configuração de toda a máquina em máquinas alvo (embora eu já tenha visto pessoas fazerem isso).

@willapp Por que você não usa appsettings.json ?

@willapp

M $ tem a solução perfeita, mas a maioria das pessoas manteve o conceito de transformação web.config.

Esta é uma maneira de ter vários sites lado a lado. Você só precisa lançar o valor do ambiente em qualquer lugar fora do diretório binário do IIS e ler / configurá-lo em program.cs

• IISRoot
  
  
  
  • MySiteDEV
  
  
  • bin
    
    
    
    
    
    • appsettings.json
    
    
    
    • appsettings.DEV.json
    
    
    
    • appsettings.PROD.json
    
    
    
    • web.config
    
    
    
  
  
  • Histórico
  
  
  • env.DEV
  
  
  • MySitePROD
  
  
  • bin
    
    
    
    
    
    • appsettings.json
    
    
    
    • appsettings.DEV.json
    
    
    
    • appsettings.PROD.json
    
    
    
    • web.config
    
    
    
  
  
  • Histórico
  
  
  • env.PROD
  
  

@davidfowl

Você está dizendo às pessoas que é uma pena que o ASP.NET core não funcione bem com o IIS? Como arquiteto do Microsoft .NET Core?

A mudança de paradigma aqui com qualquer coisa que o Core seja multiplataforma. O IIS é claramente um utilitário do Windows - portanto, alguns problemas de crescimento devem ser esperados. Soluções alternativas, em um caso como este, devem ser esperadas e aceitas à medida que as coisas avançam. Ter feito escolhas intencionais de design no Core para oferecer suporte a um recurso do Windows teria sido contra-intuitivo.

Edite para adicionar:
Esta é uma questão de saber se o Core deve ter um suporte melhor e pronto para o IIS. A discussão sobre o uso de variáveis ​​de ambiente sendo uma boa alternativa, não obstante ...

@davidfowl

E esta é exatamente a diferença entre arquitetura corporativa e SME. Eu trabalho para um FTSE100 e sim, separar a implantação do código faz sentido, mas também executo vários sites de forma independente e é apenas mais fácil e mais econômico ter um único servidor onde hospedo todos os meus sites. Usar o Web Deploy + Transforms é um mecanismo testado e comprovado para alterações de código de entrega, ele simplesmente funciona. Não estou dizendo que não haja alternativas melhores em alguns casos, mas a Microsoft deveria ter continuado o suporte para transformações sabendo que a maioria dos usuários deseja familiaridade ao migrar da estrutura .net para o núcleo.

Eu tenho minha solução agora do início deste tópico, então estou feliz o suficiente. Eu só acho que eles deixaram a bola cair um pouco, não incluindo isso como padrão.

@willapp

Acho que transformar é baseado na ideia de compilar a partir da fonte e publicar separadamente para cada ambiente. Estou feliz que M $ desistiu porque a alternativa é muito mais elegante.

Com a nova configuração, você publica seu código apenas uma vez usando a configuração de versão. Todas as instâncias em execução são cópias binárias idênticas do original. A implantação deve ser apenas uma sincronização de arquivo simples para o próximo ambiente DEV => TEST => Staging => PROD.

Você está dizendo às pessoas que é uma pena que o ASP.NET core não funcione bem com o IIS? Como arquiteto do Microsoft .NET Core?

Estou dizendo que as pessoas não pensam imediatamente no fato de que as variáveis ​​de ambiente usadas dessa forma devem ser por processo em vez de por máquina. Historicamente, no Windows, as pessoas identificam as variáveis ​​de ambiente em toda a máquina, em vez de por processo, o que causa confusão. O IIS 10 adicionou suporte para adicionar variáveis ​​de ambiente por pool de aplicativos. O módulo ASP.NET Core também oferece suporte para definir variáveis ​​de ambiente por processo.

Ainda assim, essa capacidade está lá. Eu acho que houve principalmente uma mudança filosófica no pensamento aqui. Não queremos fazer nada que torne mais fácil especificar segredos no momento do desenvolvimento.

@challamzinniagroup bom resumo

Esta é uma questão de saber se o Core deve ter um suporte melhor e pronto para o IIS. A discussão sobre o uso de variáveis ​​de ambiente sendo uma boa alternativa, não obstante ...

Direito. O fluxo de trabalho para configurar informações específicas do ambiente ainda deve estar no ambiente específico. A questão é como você faz isso chegar lá. Isso faz parte da implantação?

Dito isso, acredito que estamos adicionando suporte para isso nas ferramentas do 2.2.

cc: @vijayrkn

@davidfowl

Quando você diz "Historicamente no Windows, as pessoas identificam as variáveis ​​de ambiente como em toda a máquina em vez de por processo", você se refere às variáveis ​​de ambiente do Windows, como na linha de comando SET?

Porque meu entendimento de "ambiente" dentro do contexto do .NET core é apenas uma variável. Por padrão, ele lê ASPNETCORE_ENVIRONMENT do sistema ou web.config. Mas você pode sobrescrever e obtê-lo de qualquer fonte por qualquer convenção.

Existe algo inerentemente errado com essa abordagem? Porque se a posição oficial da equipe do Microsoft .NET é não fazer isso, teríamos que reconsiderar seriamente. Mas você acabaria dizendo às pessoas para executar o .NET core no IIS, mas, infelizmente, não há uma maneira fácil de configurar esses aplicativos. Espero que não seja o caso.

Obrigado.

@ThisNoName

Quando você diz "Historicamente no Windows, as pessoas identificam as variáveis ​​de ambiente como em toda a máquina em vez de por processo", você se refere às variáveis ​​de ambiente do Windows, como na linha de comando SET?

Sim, é exatamente disso que trata este tópico. (Veja aqui ). Como David diz, eles podem ser por processo, mas na minha experiência a maioria da documentação no núcleo dotnet assume que você os define no nível da máquina, portanto, temos esse problema em que não é possível implantar facilmente várias instâncias de aplicativos no mesmo servidor, como eles obterão os mesmos valores de ambiente, então você não poderá distinguir entre dev / staging / prod.

O fato de que o IIS10 suporta configurá-los por pool de aplicativos é ótimo ... se você tiver o Server 2016 disponível. Estou executando 2012, então esta não é uma opção. Novamente, meu problema não é que a Microsoft esteja tentando mover as coisas em uma direção melhor, mas abandonar o suporte 'legado' para algo que muitas pessoas consideravam certo ao implantar aplicativos ASP.NET parece um erro para mim. Sem dúvida, introduza novos padrões e incentive as pessoas a adotá-los, mas não remova o comportamento legado até ter certeza de que poucas pessoas precisam dele. Caso contrário, tudo o que você está fazendo é colocar barreiras para os clientes que desejam o núcleo dotnet, mas consideram o caminho de migração muito difícil.

@willapp

Essa é apenas a configuração padrão pronta para uso. Você pode ler e definir o ambiente da maneira que quiser. Pelo menos esse é o meu entendimento, a menos que alguém aponte alguma falha séria nessa abordagem?

   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

A falha séria é: como você faz o método "ReadEnvFromWherever" retornar um valor diferente ao implantar usando a publicação na Web do VSTS, com base na configuração da sua solução? Suponho que você possa usar diretivas de pré-processador (#if RELEASE ...), mas isso parece muito sujo.

No "velho mundo" (estrutura completa do ASP.NET), você cria um perfil de publicação e parte disso é selecionar uma configuração de solução para construir. Com base nessa configuração, ele aplicou uma transformação de configuração que permitiu especificar configurações diferentes com base em se você estava publicando em dev / staging / prod.

Aceito que este fluxo de trabalho não se encaixa em um pipeline de CI moderno, onde você pega um único pacote de compilação e o envia por meio de cada ambiente - neste caso, você quer algo como o pipeline de lançamento do VSTS para injetar configurações no momento da implantação, ou você prepara sua instância de servidor com as variáveis ​​de ambiente corretas, caso em que você apenas solta o pacote na caixa e ele funcionará como um passe de mágica. Mais uma vez, porém, acho que muitos PMEs e bandas de um homem só não estão neste lugar e desejam um processo de implantação a partir do Visual Studio que produza o resultado que desejam.

Apenas para acrescentar que isso também é importante para a implantação de pequenos projetos em plataformas de hospedagem compartilhada que são executadas no IIS e que oferecem hospedagem ASP.NET tradicionalmente. Eles não têm nenhuma facilidade para definir variáveis ​​de ambiente por site por meio de seus painéis de controle de hospedagem e, portanto, a única abordagem realista é usar transformações e web.config .

Parece que tudo isso terá uma solução decente no próximo lançamento, porém, e com suporte a VS embutido seguindo um pouco mais adiante. Esperançosamente, isso oferecerá suporte às pessoas com fluxos de trabalho existentes que dependem dessa funcionalidade até que os provedores de hospedagem e sistemas legados possam ser atualizados ou melhorados.

@willapp

Por convenção. Se você seguir o exemplo que postei anteriormente, poderá ler env.DEV da pasta pai e usar a extensão de arquivo como sua variável de ambiente. Mas você pode seguir qualquer convenção, como nomear a raiz do aplicativo como MySiteDEV, MySitePROD, etc. e analisar o nome da pasta para obter o nome do ambiente.

Se o seu código variar de acordo com o ambiente, você pode ler o valor do ambiente em IHostingEnvironment .EnvironmentName

Isso não é diferença do .NET core lendo ASPNETCORE_ENVIRONMENT da variável do sistema ou web.config.

@ThisNoName

Mas como você obtém _env.DEV_ na pasta pai, a não ser copiá-lo manualmente? Vejo o que você está tentando dizer, mas acho que está perdendo o ponto aqui: costumava haver uma solução pronta para o uso que simplesmente funcionava. Agora não há porque o suporte de ferramentas para ele não foi considerado como parte do processo de implantação central do dotnet.

Eu entendo _porque_ ele foi removido (porque existem alternativas melhores se você tiver um processo de CI decente), mas acho que foi muito míope quando muitos usuários em migração ainda o desejariam.

@willapp

Você o copia uma vez durante a configuração inicial e todas as implantações futuras vão para a pasta bin. Sem recompilação, sem publicação, sem transformação. É assim que deve ser, leva 3 linhas extras de código, e daí? É M $. Até 3 meses atrás, você não conseguia nem chamar o Active Directory no .NET Core.

@ThisNoName Você espera ser levado a sério com essas coisas de M $. Você sabe que é 2018, certo?

Sua sugestão não faz sentido no contexto de uma implantação da web em uma plataforma de hospedagem compartilhada. Eu nem tenho certeza do que você está argumentando a favor ou contra, a funcionalidade está sendo adicionada na próxima versão do ASP.NET Core para que uma variável de ambiente possa ser especificada no perfil de publicação, sem necessidade de quaisquer transformações ou qualquer coisa. Também não há necessidade de abordagens não padronizadas com nomes de pastas, que podem ou não estar sob seu controle.

@willapp , @svallis
A solução que postei um pouco mais adiante funciona em alguns casos. Você pode obter o Url e definir o ambiente com base nele. Em qualquer ambiente de hospedagem, você tem controle total de seus Urls. Sei que isso ainda é "hackeado" e uma solução alternativa - mas geralmente deve funcionar na maioria das vezes. No caso da minha empresa de hospedagem, o Url que eu estava recebendo era um localhost: port base ("127.0.0.1:7777") - então acabou não sendo o ideal para mim. Mas também tenho a capacidade de definir caminhos de pasta raiz em meus vários ambientes, já que os configuro como subdomínios - e extrair o caminho do aplicativo raiz também é muito simples:

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

A escolha de se o ambiente deve ou não ser determinado dentro do código, no momento da implantação ou pré-determinado diretamente no ambiente com antecedência não é a discussão que estou tentando abordar - estou simplesmente oferecendo uma correção razoável para aqueles SME / indivíduos que têm controle de hospedagem limitado e precisam de uma correção. No meu caso, este é um código-uma-vez-e-esqueça - exatamente o que eu preciso.

Posteriormente, posso extrair facilmente os valores de configuração de um arquivo appsettings.json sem qualquer necessidade de transformações simples, incluindo:

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

no arquivo de configurações e tendo 3 entradas por configuração - uma para cada ambiente. Só tenho um número muito pequeno de configurações neste arquivo e, portanto, a duplicação não é um grande problema.

Espero que isto ajude!

@challamzinniagroup É mais fácil usar o caminho relativo da pasta e o nome por convenção.

@svallis Todo o conceito é publicar uma vez e implantar no nível binário. Portanto, mesmo que você possa definir a variável por perfil de publicação, esse não é o caminho a percorrer.

@ThisNoName Para você, talvez seja mais fácil - mas não presuma essas coisas para os outros. No meu caso, tenho configurações para limpar os diretórios de destino antes de publicar / copiar - e, portanto, para sua solução, eu teria que recarregar cada arquivo de ambiente manualmente, todas as vezes. Isso definitivamente _não_ é mais fácil.

@challamzinniagroup Agree. Cada situação é diferente. O ponto principal é que o ambiente é apenas uma variável, você pode controlá-lo da maneira que achar melhor, em vez de esperar que a Microsoft forneça a próxima melhor opção. E o que quer que apareça, é apenas outra solução baseada em convenção de qualquer maneira - lendo algum valor do sistema ou do web.config e do ambiente definido.

BTW, você ainda pode usar a convenção. Não há como dizer que appsettings precisam usar uma única palavra do meio e Staging / Production não tem significados especiais. Você pode facilmente fazer algo assim e passar o nome da pasta para corresponder.

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

Com a solução baseada em convenção, você pode ativar novas instâncias sem ter que recompilar e / ou republicar.

@vijayrkn, você poderia elaborar mais sobre o uso do pubxml?
Eu atualizei meu SDK para 2.1.302 (x64), alterei meu pubxml, mas não consigo ver nenhuma diferença no web.config publicado.

@wggley - A correção não está disponível no 2.1.302. Ele deve estar disponível no próximo lançamento.

Você pode tentar a versão de visualização do cli que contém a correção aqui - https://dotnetcli.blob.core.windows.net/dotnet/Sdk/release/2.1.4xx/dotnet-sdk-latest-win-x64.exe

Avise-me se tiver problemas com a versão de visualização acima.

Obrigado @vijayrkn . Vou esperar pelo próximo lançamento e tentar usar em uma nova publicação.
Eu gostaria de apontar que a solução @frankhoffy funcionou para mim como um encanto:
https://stackoverflow.com/questions/31049152/publish-to-iis-setting-environment-variable/36836533#36836533
Procure a primeira resposta (resposta mais votada).

O suporte para transformação de configuração da Web durante a publicação agora está disponível em 2.2 preview1 https://www.microsoft.com/net/download/dotnet-core/2.2

@vijayrkn existe uma amostra básica em algum lugar? Seria ótimo apontar as pessoas para o equivalente hello world usando uma transformação básica que define ASPNETCORE_ENVIRONMENT.

Para definir ASPNETCORE_ENVIRONMENT, os usuários podem definir a propriedade msbuild '$ (EnvironmentName)'. Vou adicionar um exemplo que mostra como definir outras variáveis ​​env usando transformações web.config.

Aqui está um repositório de amostra - https://github.com/vijayrkn/webconfigtransform

Leiame tem detalhes sobre como isso funciona:
https://github.com/vijayrkn/webconfigtransform/blob/master/README.md

Espero que isto ajude!

@Eilon - Podemos encerrar esse problema. Isso foi corrigido e está disponível na última visualização.

@vijayrkn Não está claro como definir as configurações de Publicação para definir o ambiente na caixa de diálogo Configurações de Publicação? O que realmente pode ser alterado nesta caixa de diálogo para distinguir um site de teste de um site de produção, se ambos os sites estiverem sendo implantados no mesmo servidor?

Esse aspecto do .NET core parece muito confuso. Deve ser muito mais fácil especificar o ambiente por pasta. Uma variável de ambiente de servidor completo não pode funcionar em nossa situação. Nem todos podem executar seus sites de teste em servidores diferentes para seus sites de produção.

A configuração é por aplicativo.

Desculpe, mas isso realmente não responde à minha pergunta. Talvez eu esteja entendendo mal alguma coisa.

Há alguma pseudo documentação aqui https://github.com/vijayrkn/webconfigtransform/blob/master/README.md ( @vijayrkn , precisamos colocá-la nos documentos reais).

@vijayrkn Quanto suporte existe para isso na caixa de diálogo de publicação?

Atualmente, a caixa de diálogo de publicação não tem nenhum suporte para definir os ambientes de publicação, mas os ambientes podem ser definidos manualmente no perfil de publicação ou transformações específicas podem ser aplicadas.

@ nmg196 - Se você deseja apenas definir o 'ASPNETCORE_ENVIRONMENT' no web.config, tudo o que você precisa fazer é adicionar o nome do ambiente ao publishprofile.

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

Para cenários avançados (além da configuração da variável de ambiente ASPNETCORE_ENVIRONMENT), as transformações web.config podem ser aplicadas conforme mencionado na documentação acima.

@davidfowl - Angelos tem um item para documentar o suporte à transformação web.config.

@vijayrkn Como usar em CI / CD do TFS? Não consegui usar o dotnet publish com p: CustomTransformFileName no TFS

Você pode passar esta propriedade msbuild para publicar dotnet.

Você pode consultar este exemplo aqui - https://github.com/vijayrkn/webconfigtransform/blob/master/publish.cmd

Isso passa a propriedade CustomTransformFileName para dotnet publish

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

@vijayrkn
Eu li sua documentação e não consigo transformar o web.config. Tentei basicamente todos os comandos que você tem no readme.md e nenhum deles resultou na execução da transformação.

No entanto, consegui escrever um script do PowerShell que usa Microsoft.Web.XmlTransform.dll para realizar a transformação separada da operação de publicação.

Minha pergunta é qual versão do msbuild e dotnet você está usando?
Estou usando:
dotnet - versão 2.1.104
dotnet msbuild-versão 15.6.84.34536

Obrigado

@ stephenarsenault1
Você precisa instalar qualquer uma das compilações a partir daqui para o recurso acender - https://www.microsoft.com/net/download/dotnet-core/2.2

Mais recente - https://www.microsoft.com/net/download/thank-you/dotnet-sdk-2.2.100-preview3-windows-x64-installer

@davidfowl escreveu:

Há alguma pseudo documentação aqui https://github.com/vijayrkn/webconfigtransform/blob/master/README.md ( @vijayrkn , precisamos colocá-la nos documentos reais).

@vijayrkn Quanto suporte existe para isso na caixa de diálogo de publicação?

Você sabe se isso alguma vez foi adicionado aos documentos reais? Em caso afirmativo, você tem o link?

Passamos a usar <EnvironmentName> em nossos perfis de publicação agora. Seria bom ter alguma interface do usuário em cima disso para que seja mais visível, no entanto. Presumo que isso virá em uma data posterior.

Acho que é uma alteração significativa habilitar por padrão as transformações do web.config na publicação do dotnet. Depois de instalar o .NET Core SDK 2.2.101, ele quebrou nosso cenário de CI / CD. Nosso pipeline foi configurado para criar artefato publicado usando dotnet publish apenas uma vez para qualquer versão ( regra de construção única ), transformação aplicada automaticamente na implantação real (realizada pelo Octopus). Não encontrei nenhuma menção na documentação sobre essa mudança. Gastei um pouco de tempo tentando descobrir qual o motivo dos blocos de configuração duplicados no web.config após a implantação. Aparentemente, a transformação foi aplicada duas vezes: por dotnet publish e pela ferramenta de gerenciamento de versão.

Depois de desabilitar as transformações web.config com a configuração <IsTransformWebConfigDisabled>true</IsTransformWebConfigDisabled> , TransformWebConfig também pulou (junto com TransformXml), o que resulta em %LAUNCHER_PATH% e %LAUNCHER_ARGS% variáveis ​​não sendo substituídas durante o processo de publicação. Existe uma configuração para controlar essas etapas de forma independente?

Isso funciona em um aplicativo de console com o arquivo App.Config?

Podemos ver um exemplo?

@dmitryshunkov você pode definir $ (RunXdt) como false para apenas pular a execução da transformação Xml personalizada.

@auserx - se for um projeto no estilo sdk, então deve funcionar.