ASPNETCORE_Environment overrides cmd parameter

[inech]

Describe the bug

We've noticed a very strange behavior of hosting environment setting. When using ASPNETCORE_Environment="fromEnv" environment variable and --Environment=fromCmd command-line argument then for some reason the environment variable wins.

This is very inconsistent given that:

1. ASPNETCORE_urls vs --urls - command-line argument wins 📗
2. DOTNET_ENVIRONMENT vs --Environment - command-line argument wins 📗
3. ASPNETCORE_ENVIRONMENT vs --Environment - environment variable wins 📙

To Reproduce

1. (This one works well) When I don't set any environment variables, the command-line argument is applied:

dotnet .\WebApplication_TestEnvironment.dll --Environment=fromCmd
Current environment: fromCmd

2. (This one works well too) When I set DOTNET_ENVIRONMENT environment variable, the command-line argument wins:

$ENV:DOTNET_ENVIRONMENT="fromDotnetEnv"
dotnet .\WebApplication_TestEnvironment.dll --Environment=fromCmd
Current environment: fromCmd

3. (This one doesn't work) When I set ASPNETCORE_ENVIRONMENT environment variable, then hosting environment is defined by the environment variable and not by cmd:

$ENV:ASPNETCORE_ENVIRONMENT="fromAspEnv"
dotnet .\WebApplication_TestEnvironment.dll --Environment=fromCmd
Current environment: fromAspEnv

I am able to reproduce it on a newly created ASP.NET Core 3.1 API project. The only small change I did is writing the current environment to the Console .

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

        public static IHostBuilder CreateHostBuilder(string[] args) =>
            Host.CreateDefaultBuilder(args)
                .ConfigureWebHostDefaults(webBuilder =>
                {
                    webBuilder.UseStartup<Startup>();
                });
    }

   ....................................................................

    public class Startup
    {
        public Startup(IConfiguration configuration)
        {
            Configuration = configuration;
        }

        public IConfiguration Configuration { get; }

        // This method gets called by the runtime. Use this method to add services to the container.
        public void ConfigureServices(IServiceCollection services)
        {
            services.AddControllers();
        }

        // This method gets called by the runtime. Use this method to configure the HTTP request pipeline.
        public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
        {
            Console.WriteLine($"Current environment: {env.EnvironmentName}");

            if (env.IsDevelopment())
            {
                app.UseDeveloperExceptionPage();
            }

            app.UseRouting();

            app.UseAuthorization();

            app.UseEndpoints(endpoints =>
            {
                endpoints.MapControllers();
            });
        }
    }

Further technical details

dotnet --info
.NET Core SDK (reflecting any global.json):
 Version:   3.1.100
 Commit:    cd82f021f4

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.18362
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\3.1.100\

Host (useful for support):
  Version: 3.1.0
  Commit:  65f04fb6db

.NET Core SDKs installed:
  1.1.9 [C:\Program Files\dotnet\sdk]
  2.1.201 [C:\Program Files\dotnet\sdk]
  2.1.508 [C:\Program Files\dotnet\sdk]
  2.1.509 [C:\Program Files\dotnet\sdk]
  2.1.701 [C:\Program Files\dotnet\sdk]
  2.1.801 [C:\Program Files\dotnet\sdk]
  2.2.109 [C:\Program Files\dotnet\sdk]
  2.2.401 [C:\Program Files\dotnet\sdk]
  3.1.100 [C:\Program Files\dotnet\sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.1.12 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.1.13 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.1.14 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.2.6 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.2.7 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.12 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.1.13 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.1.14 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.2.6 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.2.7 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.1.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 1.0.11 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 1.1.8 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.0.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.12 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.13 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.14 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.2.6 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.2.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.1.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 3.1.0 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

[DanieleVidoVigilate]

I noticed a similar behavior with the ASPNETCORE_URLS variable: the value of the "Urls" section of the appsettings.json file always overrides the value of the environment variable.

I stumbled across this problem working on a asp.net 3.1 core application with docker support enabled, where the environment variable was defined in the docker-compose.override.yml file.
Anyway, the same happens in a simple asp.net core 3.1 application, with the environment variable defined in the debug properties of the VS project. In both cases the host was built with the default builder.

Please note that the precedence works exactly as expected with the other variables: environment always wins on the appsettings.json file.

[KoshelevS]

Any news on this?

I've created the following extension method as a workaround, but it has not been battle-tested yet

        public static IWebHostBuilder FixEnvironmentParam(this IWebHostBuilder webBuilder, string[] args)
        {
            var configBuilder = new ConfigurationBuilder();
            configBuilder.AddCommandLine(args);
            var config = configBuilder.Build();

            var env = config[HostDefaults.EnvironmentKey];
            if (string.IsNullOrWhiteSpace(env))
            {
                return webBuilder;
            }

            return webBuilder.ConfigureAppConfiguration((host, _) => host.HostingEnvironment.EnvironmentName = env)
                             .UseEnvironment(env);
        }

[wtgodbe]

We will take a look at this in the new year once folks are back from vacation

Thanks for contacting us.
We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. We will evaluate the request when we are planning the work for the next milestone. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[mguinness]

In the documentation under Environment variable configuration provider there is the following sentence which probably explains the behavior reported by the OP.

The default configuration loads environment variables and command-line arguments prefixed with DOTNET_. The DOTNET_ prefix is used by .NET for host and app configuration, but not for user configuration.