appsettings Urls takes precedence over ASPNETCORE_URLS in 6.0.4

[Hoffs]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

Using aspnet 6.0.4 runtime, precedence of appsettings.json Urls and ASPNETCORE_URLS seems to be different compared to previous versions. Specifying ASPNETCORE_URLS environment variable does not override the url provided in appsettings.json Urls property. Before 6.0.4, ASPNETCORE_URLS would have been used over Urls in appsettings.json .

I would assume that the order that these settings are overriden in is the same as for regular settings: https://docs.microsoft.com/en-us/aspnet/core/fundamentals/configuration/?view=aspnetcore-6.0#default-configuration

Based on those, environment variables are applied after appsettings.

I am guessing this is related to dotnet/aspnetcore#39836 which meant to fix in-code overriding of any configuration value. Also, while that issue is tagged with 6.0.3, based on comment dotnet/aspnetcore#40614 (comment) it looks like it was shipped as part of 6.0.4, which is a bit confusing.

Expected Behavior

ASPNETCORE_URLS is used instead of appsettings.json Urls.

Steps To Reproduce

• Create new project dotnet new webapi
• Modify appsettings.json by adding "Urls": "http://*:5300/"
• Set env var export ASPNETCORE_URLS="http://*:5200/"
• dotnet run

info: Microsoft.Hosting.Lifetime[14]
      Now listening on: http://[::]:5300

@Rick-Anderson EDIT following lines

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 0eb4d762-3910-2c57-8741-3306c15537b6
• Version Independent ID: ba2254a0-ea8e-9b28-e94b-edd0fc58c043
• Content: Configuration in ASP.NET Core
• Content Source: aspnetcore/fundamentals/configuration/index.md
• Product: aspnet-core
• Technology: aspnetcore-fundamentals
• GitHub Login: @Rick-Anderson
• Microsoft Alias: riande

Thanks for contacting us.

We're moving this issue to the .NET 7 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. 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.

[halter73]

If you want an environment variable to override "Urls": in appsettings.json, it's still possible. You just have to use export URLS="http://*:5200/" instead of export ASPNETCORE_URLS="http://*:5200/".

dotnet/aspnetcore#39836 is a bugfix and it aligns WebApplicationBuilder behavior with Host.CreateDefaultBuilder(args).ConfigureWebHostDefaults(....

---

The order of default config in .NET 6 for all hosts after this bugfix is as follows from highest to lowest precedence:

Application config

1. Command-line arguments
2. Non-prefixed environment variables
3. user-secrets (in development environments)
4. appsettings.{Environment}.json
5. appsettings.json

Host config

1. ASPNETCORE_-prefixed environment variables
2. Command-line arguments
3. DOTNET_-prefixed environment variables

Explanation

Application config falls back to host config, so you might wonder why command line arguments gets added again at a lower precedent in host config. And the answer is that when initializing the WebApplicationBuilder and during the early stages of IHostBuilder.Build(), application config hasn't been built yet.

Since we wanted to allow command-line arguments to control things like environment name by default (and that is important for building application config because that determines which appsettings.{Environment}.json to load), the command line gets added twice as a config source.

Host variables

The following variables are all locked in early when initializing the host builders and cannot be influenced by application config:

1. Application name
2. Environment name (e.g. Development, Production)
3. Content root
4. Web root
5. Whether to scan for hosting startup assemblies and which assemblies to scan for
6. Variables read by app and library code from HostBuilderContext.Configuration in IHostBuilder.ConfigureAppConfiguration() callbacks

URLS is notably absent from this list of host variables. URLS is read later from application config where non-prefixed environment variables override appsettings.json, but ASPNETCORE_-prefixed and DOTNET_-prefixed environment variables get overridden.

@Rick-Anderson Do you think https://docs.microsoft.com/en-us/aspnet/core/fundamentals/configuration/?view=aspnetcore-6.0#default-configuration can get updated to be more like the above? I can submit a PR myself, but it might have to wait a little.

---

It is odd that ASPNETCORE_ environment variables override command line arguments for host config. That's one of the little things fixed by dotnet/aspnetcore#40459. Starting in .NET 7, WebApplicationBuilder will order host config with command-line arguments at the highest precedent and ASPNETCORE_ environment variables at the lowest.

[Rick-Anderson]

@Rick-Anderson Do you think https://docs.microsoft.com/en-us/aspnet/core/fundamentals/configuration/?view=aspnetcore-6.0#default-configuration can get updated to be more like the above? I can submit a PR myself, but it might have to wait a little.

I'll give it a shot and have you review the PR.
Do you want to transfer this issue to https://github.com/dotnet/AspNetCore.Docs/issues ?

[nobugsincode]

Hm, it's interesting. I have my app running in Docker with dotnet/aspnet as a base image which sets ASPNETCORE_URLS=http://+:80 but the app is running on port 5000 instead. I don't have any Urls set in the app config. So seems like Docker images now should use URLS instead of ASPNETCORE_URLS? I've noticed this after app update to 6.0.4. So it's no longer run on port 80 inside Docker container but on port 5000. To run app on port 80 again I need to set it explicitly using dotnet App.dll --urls=+:80 which is a bit odd. @halter73, since you've did the change for 6.0.4 - is it a desired behavior?

[nobugsincode]

Hm, it's interesting. I have my app running in Docker with dotnet/aspnet as a base image which sets ASPNETCORE_URLS=http://+:80 but the app is running on port 5000 instead. I don't have any Urls set in the app config. So seems like Docker images now should use URLS instead of ASPNETCORE_URLS? I've noticed this after app update to 6.0.4. So it's no longer run on port 80 inside Docker container but on port 5000. To run app on port 80 again I need to set it explicitly using dotnet App.dll --urls=+:80 which is a bit odd. @halter73, since you've did the change for 6.0.4 - is it a desired behavior?

Not an issue, my fault, I had some custom logic around configuration setup which cause such issue.