Closed inech closed 1 year ago
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.
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);
}
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.
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_
. TheDOTNET_
prefix is used by .NET for host and app configuration, but not for user configuration.
Looks like this behavior is documented here: https://docs.microsoft.com/en-us/aspnet/core/fundamentals/host/generic-host?view=aspnetcore-6.0#default-builder-settings
Admittedly, it could be a bit more clear about the fact that config loaded later in the order overrides earlier config.
We should add a clear explanation in our docs of how the config is loaded from various places, in what order, and which things override others.
Thanks for contacting us.
We're moving this issue to the .NET 7 Planning
milestone for future evaluation / consideration. Because it's not immediately obvious that this is a bug in our framework, we would like to keep this around to collect more feedback, which can later help us determine the impact of it. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.
I think one option here is to give ASPNET_
environment variables the lowest precedence by default. So instead of adding GenericWebHostBuilder
's chained config source at the end of the IConfigurationBuilder.Sources
, we could add it to the beginning.
This would be a breaking change that would likely need to be announced as this would cause DOTNET_
environment variables to
override ASPNETCORE_
environment variables instead of the opposite which happens today, but hopefully there aren't many people relying on that. I'm considering a similar change to WebApplicationBuilder
in 7.0 when it's replatted on HostApplicationBuilder
or whatever we end up calling it. https://github.com/dotnet/runtime/issues/61634.
This should now be addressed in 7 since we did what @halter73 mentioned above.
Reopening to consider changing the GenericWebHostBuilder
to match WebApplicationBuilder
's new behavior of loading ASPNET_
-prefixed environment variables with the lowest precedence. We've already made this breaking change to WebApplicationBuilder
. See https://github.com/aspnet/Announcements/issues/498
I moved this to preview 1 since it's a relatively small change that we should introduce early since it's breaking.
Triage: this seems low priority and the current behavior is now documented better. Closing this issue.
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:
ASPNETCORE_urls
vs--urls
- command-line argument wins 📗DOTNET_ENVIRONMENT
vs--Environment
- command-line argument wins 📗ASPNETCORE_ENVIRONMENT
vs--Environment
- environment variable wins 📙To Reproduce
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 .
Further technical details