New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Projects
None yet
4 participants
@NinoFloris

NinoFloris commented Aug 15, 2017

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

This comment has been minimized.

Member

halter73 commented Aug 16, 2017

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

This comment has been minimized.

Member

halter73 commented Aug 16, 2017

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

This comment has been minimized.

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

This comment has been minimized.

Member

Tratcher commented Oct 13, 2017

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

@MBODM

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

Member

Tratcher commented Oct 13, 2017

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

@MBODM

This comment has been minimized.

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 join this conversation on GitHub. Already have an account? Sign in to comment