Skip to content
This repository has been archived by the owner on Dec 18, 2018. It is now read-only.

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

Closed
NinoFloris opened this issue Aug 15, 2017 · 8 comments

Comments

@NinoFloris
Copy link

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
Copy link
Member

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:

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:

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
Copy link
Member

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
Copy link

mbodm commented Oct 13, 2017

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
Copy link
Member

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

@mbodm
Copy link

mbodm commented Oct 13, 2017

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
Copy link

mbodm commented Oct 13, 2017

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
Copy link
Member

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

@mbodm
Copy link

mbodm commented Oct 13, 2017

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants