aspnetcore: DOTNET_URLS ignored by Kestrel on macOS / .NET Core 3.1 + .NET 5 Preview 8

I don’t know if this is related but launchSettings.json appear to be ignored on MacOS if using Host.CreateDefaultBuilder. This code will start localhost:5000, ignoring the launchSettings.json

        private static IHostBuilder CreateHostBuilder(string[] args)
        {
            return Host.CreateDefaultBuilder(args)
                .ConfigureServices((hostContext, services) =>
                {
                    //Disable default startup messages so we don't mess up console based structured logging
                    services.Configure<ConsoleLifetimeOptions>(opt => opt.SuppressStatusMessages = false);
                })
                .ConfigureWebHostDefaults(c => { c.UseStartup<Startup>(); })
                .ConfigureLogging(c => { c.SetMinimumLevel(LogLevel.Trace); })
                .UseNLog();
        }

whereas this “legacy code” will correctly pick up launchSettings.json

        private static IWebHostBuilder CreateHostBuilder(string[] args)
        {
            return WebHost
                .CreateDefaultBuilder(args)
                .UseStartup<Startup>()
                .ConfigureLogging(c =>
                {
                    c.SetMinimumLevel(LogLevel.Trace);
                })
                .UseNLog();
        }

Running in Rider but no other changes between the two debug runs except to swap these methods.

.NET Core 3.1.3

+1 for addressing this. When running .NET core in a Docker container, ENV variable for URLs are completely ignored and the default http://localhost:5000 is always used. Seemingly the only way to change this behavior is by setting Kestrel:Endpoints:Http:Url value in appsettings.json.

If you don’t need all the extra features configuring endpoints directly in Kestrel gives you (like specifying TLS certs or HTTP protocol versions), you can set the key Urls (or URLS or urls because it’s case insensitive) to http://*:8080. This should work with all versions of ASP.NET Core using either ConfigureWebHostDefaults (The generic host) or WebApplicationBuilder (new in .NET 6).

Urls can be defined via the command line (--urls "http://*:8080"), non-prefixed environment variables (Just URLS. DOTNET_URLS or ASPNETCORE_URLS get overridden by URLS) which includes any defined in launchsettings.json or in appsettings.json or any other configuration source. If Urls is defined in more than one place, it is taken from the highest priority configuration source which is the last one added to the IConfigurationBuilder. By default, the command line has the highest priority closely followed by non-prefixed environment variables (from launchsettings.json or otherwise) and then appsettings.json.

The recently updated doc https://docs.microsoft.com/en-us/aspnet/core/fundamentals/configuration/?view=aspnetcore-6.0#default-application-configuration-sources goes into a lot more detail about all of this. As noted in those docs:

URLS is one of the many common host settings that is not a bootstrap setting. Like every other host setting not in the previous list, URLS is read later from application config. Host config is a fallback for application config, so host config can be used to set URLS, but it will be overridden by any configuration source in application config like appsettings.json.

In an earlier triage we suggested the following:

Triage: We can look at adding info logs stating “<value> from <location> was overridden by <value> from <location>” or something similar.

Unfortunately, this is not possible because we cannot determine if config was overridden using IConfiguration. I’m going to move this out of the backlog to discuss in triage again, but now that the documentation is updated, I think we should close this issue. While the current behavior is unfortunately quite complicated, any simplification would be a pretty major breaking change.

Can confirm that only (i’m setting this via kubernetes) @kmjungersen approach worked with my case, ie. I set the key: Kestrel__Endpoints__Http__Url to http://*:8080 (what I need for my kubernetes service). Thanks.

Also experienced this issue, running in the context of a Docker container.

Triage: We can look at adding info logs stating "<value> from <location> was overridden by <value> from <location>" or something similar.

I’m removing the labels because I want to discuss this next triage. This experience does seem pretty surprising and hard-to-diagnose, and I want to make sure there isn’t something more we can do to improve this before marking it at resolved.