Kestrelhttpserver: Any new steps to take before dotnet run --urls "http://localhost:5001" would work?

[NinoFloris]

So docs and a lot of places reference this dotnet run --urls "http://localhost:5001" as the way to be able to change the listening address via command line. However it does not seem to work at all.

We're using WebHost.CreateDefaultBuilder(args) so we do include the commandline configuration provider. It should just work then right?

[halter73]

Thanks for the report. To use the --urls command line args, you can change the BuildWebHost method from the new 2.0 templates to look like the following:

```C#
public static IWebHost BuildWebHost(string[] args)
{
var configuration = new ConfigurationBuilder().AddCommandLine(args).Build();

return WebHost.CreateDefaultBuilder(args)
    .UseConfiguration(configuration)
    .UseStartup<Startup>()
    .Build();

}

The args passed to `WebHost.CreateDefaultBuilder(args)` are used to populate the `IConfiguration` object you can dependency inject into your application classes such as `Startup`. E.g:

```C#
public Startup(IConfiguration configuration)
{
    Console.WriteLine(@"Configuration[""urls""] = ""{0}""", configuration["urls"]);
}

The above would print Configuration["urls"] = "http://localhost:8080/" to the console if started with dotnet run --urls http://localhost:8080/ even without changing the BuildWebHost method defined in the 2.0.0 templates.

We're looking into having WebHost.CreateDefaultBuilder(args) automatically populate the WebHost configuration from command line args in addiction to the app configuration it currently populates in 2.1.0.

[halter73]

I'm closing this since I created aspnet/MetaPackages#221 to track progress on making this work out of the box in future versions.

[MBODM]

Is the IConfiguration service already available in Program.cs after the „.CreateDefaultBuilder(args)“ line, so we can directly do a „.UseUrls(configuration[„urls“])“ in Program.cs ?

[Tratcher]

No, you'd have to create your own configuration instance to do that. However, it's circular as UseUrls just writes to config.

[MBODM]

i think

public static IWebHost BuildWebHost(string[] args)
{
WebHost.CreateDefaultBuilder(args)
.UseUrls(new ConfigurationBuilder().AddCommandLine(args).Build()[„urls“])
.UseStartup()
.Build();
}

would also do the trick. i think it doesnt matter if you use the above mentioned variant (by adding .UseConfiguration()) or this one. in the end its all the same.

hopefully the development process of .net core stays fast, and next step is fixing all that tiny things like this one, and all the many other small edges and flaws, to raise overall quality of .net core, BEFORE they move on to next big changes and adding new stuff.

[MBODM]

side question: is there a simple layer in .net core, a developer can use here, to get the —urls param value out of args[] without handling the whole thing by yourself, string splitting etc ?

to just do a

.UseUrls(MagicLayer(args, „urls“))

without writing MagicLayer completely by hand (even when it isnt that much) ?

[Tratcher]

AddCommandLine is the only provided API for processing args[].

[MBODM]

Ah, ok. Thx a lot. Wasnt sure about that. Every day i still face some methods or classes i never realized they exist in .NET Core or EF Core.