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

Cannot set self-hosting url using command line argument and hosting.json after UseDefaultHostingConfiguration removed, #740

Closed
xatabhk opened this issue May 1, 2016 · 8 comments
Labels
Milestone

Comments

@xatabhk
Copy link

xatabhk commented May 1, 2016

After UseDefaultHostingConfiguration removed,
"dotnet run /server.urls http://xyz:5000" does not work any more. Neither does ""server.urls": "http://xyz:5000/"" in hosting.json. Only "UseUrls("http://xyz:5000")" in code works.

The following lines in Startup() seem dummy:

    .AddCommandLine(args)  
    .AddEnvironmentVariables(prefix: "ASPNETCORE_")  
    .AddJsonFile("hosting.json", optional: true)

Also 'args' is not available in Startup(), assigning it in main() to another static variable just for it is too much.

@davidfowl
Copy link
Member

If you want to support command line arguments then just it's 2 calls instead of one. The decision was made to remove the shortcut because the method name was pretty confusing and as more code moved into the application, having some of those defaults weren't important anymore.

You never have to call AddEnvironmentVariables because that's done by default now. If you want command line args then the code looks like this:

https://github.com/aspnet/cli-samples/blob/168196ec946acaea5122dfda47bed139d3158e17/HelloMvc/Program.cs

There's no longer a "default hosting configuration"

@xatabhk
Copy link
Author

xatabhk commented May 1, 2016

@davidfowl But there is a bug, the call order becomes important. Here is an example:

var builder = new ConfigurationBuilder()
                .AddCommandLine(args)
                .AddJsonFile("hosting.json", optional: true)
                .AddJsonFile("config.json");

Command line arg ‘server. urls’ will be ignored. This is not the desired behavior as command line args are expected to always override settings in configuration files.

@davidfowl
Copy link
Member

Command line arg ‘server. urls’ will be ignored. This is not the desired behavior as command line args are expected to always override settings in configuration files.

Are you saying you want the extension method back so that it can order things properly for your app?

The difference in thinking here comes from the fact that you control your hosting wire up. That code in now part of the application. hosting.json is no longer special. The only thing that matters is what supported configuration values we read by default. If you want to treat hosting.json specially, then you need to write that code. If you want to preserve the order, then again, write the code. The configuration system behaves the way it does and isn't changing so you just have to write the appropriate code.

WebHostBuilder is an API that can be used in multiple environments so there are no more assumptions about where configuration comes from, just what configuration we support.

@xatabhk
Copy link
Author

xatabhk commented May 1, 2016

I understand your explanation and don't want extension method back. But I think command line args should be used/read first. Or in the following code:
.AddCommandLine(args)
.AddJsonFile("hosting.json", optional: true)
.AddCommandLine(args) does nothing; it takes time to figure the issue out as no compiling error to tell the wrong order.

@davidfowl
Copy link
Member

davidfowl commented May 1, 2016

Sounds fine, put them last 😄 . I don;t know how you'd expect that to be a compiler error.

@xatabhk
Copy link
Author

xatabhk commented May 1, 2016

@davidfowl Yes. It will never be a compiler error. I hope command line args are re-ordered internally, so user doesn't have to remember to put AddCommandLine(args) last every time.

@davidfowl
Copy link
Member

You want the command line arguments to be reordered internally where?

@xatabhk
Copy link
Author

xatabhk commented May 1, 2016

@davidfowl You know I mean using command line settings first internally always.

@muratg muratg added this to the Discussion milestone May 2, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

3 participants