dnx requiring "run" can be improved a bit

[lodejard]

dnx path-to-project.json run is a bit redundant - if you name the project file or folder, and there are no arguments, it can be implied.

On the other hand, if dnx run can use the current directory as the project then that does make sense, and looks cleaner than dnx . run or dnx project.json run

[davidfowl]

And if there's a folder called run. We can just ignore it? What about the other commands?

[Mpdreamz]

I would love if we could change it to dnx run [folder | file] with it defaulting to pwd. Feels more posixy this way.

If you have a folder named run it'll be dnx run run :)

[shanselman]

Ya, this all started with the whole "dnx ." thing and I came here to open another bug but found this.

When I went "dnx web" I get a lousy error "Please specify the command to run" and I just stared.

I agree with @Mpdreamz we should do "dnx command [directory]" so the default is .

@glennc @danroth27 @DamianEdwards

(or at the absolute minimum, change the error to tell folks about the . )

[lodejard]

Yeah, was talking with @anurse about this the other day too. Specifying the project dir would probably move to a switch, because things coming after the "command" should be treated as string[] args. And the main use-case would still be to default to the current working directory, so you'd almost never be exposed to the project dir switch.

[analogrelay]

My thought was that dnx.exe would have the following syntax:

dnx <Host Options> [Command] <App Args...>

Possible "Host Options" include:

• --debug - Wait for a debugger to attach
• --lib <path> - Add a search path for assemblies
• --appbase|-p <path> - Change the base path for the application (defaults to .)

The first argument that doesn't start with - indicates the immediate end to Host Options. Everything from the first non-- argument on is passed along to AppHost.

When DNX starts up, it uses the --appbase value (which defaults to .) as the base path and boots AppHost in that directory, the rest of the arguments go to that. So if you are in a project.json directory, you can just dnx run and everything is ☀️ ✨ 😄.

There is a small exception, which is that if [Command] resolves to a real physical file on disk (a DLL or EXE, for example), that file is treated as a complete application. This lets you do dnx MyApp.exe (similar to mono MyApp.exe).

If you want to run commands from another project, you just do dnx -p path/to/project run. It's a few extra characters than it is today (-p) but since that's the secondary case, I think that's OK.

[davidfowl]

It's worth noting that changing this might break visual studio /cc @sayedihashimi @PradeepKadubandi @BillHiebert

[DamianEdwards]

I really like the look of @anurse's proposed changes.

[lodejard]

+1 and agreed such a change would need to be coordinated pretty carefully

[shanselman]

I like this also. The 90% case has to be as easy as possible. "mono foo,"
"java foo, "dnx foo"

On Wed, May 20, 2015 at 1:08 PM, Louis DeJardin notifications@github.com
wrote:

+1 and agreed such a change would need to be coordinated pretty carefully

—
Reply to this email directly or view it on GitHub
#1403 (comment).

Scott Hanselman
Donate to fight diabetes: http://hnsl.mn/fightdiabetes

[muratg]

We'll go with @anurse's suggestion. We need to ensure tooling doesn't break.

Also let's keep dnx . run behavior so that we don't break people who are super used to this. We'll remove this later.

[BillHiebert]

Tooling will need to be updated to handle the changes. We should be able to do it in a compatible way that continues to support the old syntax for older versions of DNX.

[davidfowl]

@BillHiebert I dont think it will affect tooling. Can you tell us how you're launching things today? I believe you're passing in the full path including the --appbase flag which should continue to work.