Aspnetcore: Support port command line argument

[muratg]

_From @evil-shrike on October 13, 2017 20:59_

CreateDefaultBuilder(args).UseConfiguration(configuration) works fine and allows to supply an url via cli: dotnet run --urls http://localhost:5000.
But it'd nice to support --port argument as well:
dotnet run --port 5000
Usually we don't need specify IP but only port.
It was suggested by many people in https://github.com/aspnet/KestrelHttpServer/issues/639. I saw this suggestion many times in many issues but all of them are closed and it's still not supported.

_Copied from original issue: aspnet/KestrelHttpServer#2115_

[muratg]

_From @Tratcher on October 13, 2017 21:49_

This has come up a few times but nobody ever agrees what the default host/IP should be for that port. E.g. is it the same as http://localhost:5000 or http://*:5000?

[muratg]

_From @evil-shrike on October 13, 2017 22:3_

Well, my feeling is it should be "localhost " (meaning that "allow only local connections). "Secure by default".
If someone wants to allow remote connections to his/her server he'll specify IP/* in urls. But usually we'll have a reserve proxy which accesses Kestel locally so port will enough.

[muratg]

_From @Tratcher on October 13, 2017 22:4_

The other trouble is that localhost doesn't work well in docker.

[muratg]

_From @evil-shrike on October 14, 2017 0:3_

I'm not an expert here but how will it work in docker with defaults? I mean without --urls or explicit Listen option?

[muratg]

_From @Tratcher on October 14, 2017 0:9_

I meant that in docker you need http://*:5000

[muratg]

Yeah if we change this, we'll need to keep docker running without changing the templates.

cc @shirhatti for his thoughts.

[muratg]

Tentatively putting this in 2.2.

[muratg]

_From @davidfowl on February 2, 2018 4:15_

This should be moved to Hosting

[shirhatti]

I personally am just not of fan of only specifying just the port. What's the implied hostname and scheme? I'm hard-pressed to see what value it adds, besides being a little more terse than being forced to specify the scheme and hostname as well.

[ghost]

See: https://github.com/aspnet/KestrelHttpServer/issues/639#issuecomment-237721352
Based on the community liking of that set of options. That way of overriding of port and host from command line in ootb template will bring about sheer positivity to the ASP.NET Core product, please consider it. People coming from different technology stacks are very accustomed to overriding the basic options from command line without changing some JSON or having to recompile code.. It may require few sprints to make it happen, but IMO it is worth the effort.

Thanks!

[davidfowl]

It has nothing to do with a json file vs the command line. We support both. The specific isssue we always stumble over is “do we bind to localhost or all addressed by default if you only specify a port number”. Everything we have today defaults to localhost but doing that here limits the usefulness.

Can you point me to another stack that reads the port from the command line out of the box? I’m not sure which ones do that. AFAIK you have to write code to read the appropriate settings from env or the command line and explicitly pass it to the server binding API.

I’d love to get more information here before we decide anything.

[evil-shrike]

@davidfowl
under node:

const connect = require('connect');
const http = require('http');
const https = require('https');

let  app = connect();
http.createServer(app).listen(80);
https.createServer(options, app).listen(443);

[ghost]

Please see the comment https://github.com/aspnet/KestrelHttpServer/issues/639#issuecomment-237721352 for ROR example and documentation.

[artiomchi]

Not a big fan of specifying only the port either. I'd rather the option be descriptive - so it would be obvious what the behaviour is.

For example setting the port to 5000 doesn't really explain whether it's the same as localhost:5000 or *:5000 or 10.0.0.5:5000 for example. Ambiguity in this case would just confuse people.

Also, and more importantly, the ports parameter doesn't explain whether the port should be listening to a secure connection or plaintext one.
I'll say it again - if you specify the port parameter - there's no way to specify whether this is a http or https port.

And do we really need two parameters? (--port and --securePort) 😄

I think the ability to set URLs is more than enough, since it allows you to configure anything you need: the protocol, host/ip/ips, port, and allows you to set multiple listening endpoints in one command.

[davidfowl]

@evil-shrike I'm not sure what that was supposed to show. You're explicitly passing the port.

@kasper3 ROR is the only one I've seen so far, is there any other?

@artiomchi yes, most of our team falls in this camp. We already have --server.urls where you can specify the scheme, port and host in a single parameter.

[evil-shrike]

@evil-shrike I'm not sure what that was supposed to show. You're explicitly passing the port.

it's supposed to show that specifying port is enough to start web server.

var argv = require('minimist')(process.argv.slice(2));
var port = argv.p || parseInt(process.env.PORT, 10);
http.createServer(app).listen(port);

and call it from cli: node index.js -p 80

[Tratcher]

But you had to write code to do that. You can already do that with ASP.NET Core. This issue is about built in command line support.

[ghost]

@evil-shrike this is about command line invocation, without changing the code.

@davidfowl, there is a pattern how some platforms handle the options. That pattern is being adopted in various utilities like linters, compilers and transpilers. I am not sure how common Microsoft products follow that pattern. It goes like this:

• Command line option has highest precedence and overrides everything
• Settings file in current directory, second highest
• Settings file in a directory above, third
• ...
• Settings file at the root of drive/device
• Settings file in user home directory
• Environment variables
• Default values

In case of ASP.NET Core, launchSettings in Properties directory carrying the environment variable, which cannot be overridden from outside if available in the launchSettings, command line options requiring a separate registration in the user code etc. is a quite different approach to solve this problem.

Now it's probably too late to reason about it, least we can expect is a default app template with ability to override url and port from command line, regardless of launchSettings having those values.. without changing the user code

[artiomchi]

@kasper3 Actually, ASP.NET Core does the same thing. You can quite easily and heavily customise how and where you're reading the options from when you build your IWebHost in Program.cs. Also in your own project - you can always change/remove the launchSettings.json file - it'd be your project after all.

With the default configuration (when you're using WebHost.CreateDefaultBuilder()) the settings are loaded from the following (the first entries having the top priority):

• Command line arguments
• Environment variables
• User secrets (if present, and when running in Development mode)
• Json files, by default appsettings.json and appsettings.{Environment}.json

If you're using the Options extension to bind settings to typed classes, if no value is found, the default value in your class will be used.

So you have a great variety of ways to configure your app.

The launchSettings.json file defines the launch settings and environment of your app (when running in development). When building your app, you will customise and configure it, including setting the desired ports it will run under, either by specifying it in code, or environment vars or the launchSettings.json file.

In a real project, you'll never just create an empty mvc template, not configure it at all and deploy that as your app :)

P.S. As far as I understand, your main complaint is the presence of ASPNETCORE_URLS in launchsettings.json, which will be deprecated anyway in 2.1-preview2 as far as I understood. So that's not a problem anyway