Sdk: dotnet run needs a way to pass through arguments starting with - or -- to the executable

[pranavkm]

I have an executable that supports a --foo argument. However, running dotnet run --foo does not work since the run command attempts to parse it (invalid option --foo). We need a way to pass through any arguments that aren't consumed by the run command to the executable being launched. This might also apply to the dotnet test command.

[blackdwarf]

@anurse is this in your backyard, so to speak? :) I think this is a reasonable ask, given the fact that dotnet run is also used for quick testing of console apps.

[davidfowl]

This is a System.CommandLine issue I believe.

/cc @livarcocc @piotrpMSFT

[livarcocc]

Yes. Today, we does not have a "remaing args" option to pass along. We are looking into it.

[dougbu]

This seems like an important ask for many reasons. For example,

• dotnet test --help displays no information about the many options the underlying xUnit (in my case) test runner supports.
• dotnet run --help displays no information about the many options ASP.NET Core's hosting supports for a web site.

@blackdwarf with the shared runtime changes, "quick testing" no longer begins to cover all of the dotnet run use cases.

@livarcocc "remaining arguments" won't cut it as shown in the above examples. Of course --help is just one possible argument that both dotnet.exe and applications may support.

/cc @davidfowl

[dougbu]

Hmm, maybe this issue is [now] specific to dotnet test? Looks as if dotnet run -- --configuration does approximately the Right Thing^:tm:.

[jskeet]

I arrived at this issue due to looking for something like the -- separator within dotnet test. I'm lucky I _did_ get here though, given that the title of the issue is specifically about dotnet run.

Could I suggest that either the issue title is changed, or a new issue is raised specifically about dotnet test? Basically, I'd be entirely in favour of supporting -- as a separator between arguments to dotnet test and arguments which are intended to be passed on to the test runner.

[plioi]

+1

"dotnet test" without passing through arguments cripples those of us wishing to port test frameworks to .NET Core.

[blackdwarf]

I believe that for dotnet run this has been fixed. The command now accepts -- as a delimiter after which you can specify arguments to your code. https://docs.microsoft.com/en-us/dotnet/articles/core/tools/dotnet-run documents it. Will close this as "fixed".

[dotnetshadow]

I'm not sure if the issue truly fixed.

If I have a CommandLineApplication and I type:
donet run --help it assumes that help is for the dotnet run command, not the your application
dotnet run -? this actually displays the help for your application
dotnet \bin\Debug\netcoreapp1.0\foo.dll --help runs the help option for your application

It seems we would need a way for dotnet run to know that there is a help command specific for the app, but then how would we ever get to the help command for dotnet run?

Also a sidenote the default shows
Usage: dotnet run [options] [command]

But I think commands come before options?

[blackdwarf]

@dotnetshadow you need to use the -- switch to delimit that any subsuquent switches belong to the application. In your example, to get to the application's help you would type the following command dotnet run -- --help.

[dotnetshadow]

@blackdwarf ahhh thank you that's the thing I missed

[PRIMETSS]

Thnaks, but is this meant to work when launching from VS2017 using IISExpress
Have below in launchSettings.json, from below UI in VS

"profiles": { "IIS Express": { "commandName": "IISExpress", "commandLineArgs": "-- -c \"D:/DATA/My Projects/2018/LIS/Config.xml\"", "launchBrowser": true, "environmentVariables": { "ASPNETCORE_ENVIRONMENT": "Development" } },

But public static void Main(string[] args) is always empty

However does work from command line with

dotnet run -- -c "D:/DATA/My Projects/2018/LIS/Config.xml"

[mwpowellhtx]

@davidfowl I'm not sure I'm having a similar issue. If I should open a new issue, I'll do that, let me know. I have a custom CLI tool that I want to relay command line arguments to. Literally, something like this dotnet mytool --response "MyCommandLineTool.rsp". My CLI tool is a netcoreapp Console Application and knows how to process a response command line argument, among several others.

I have serious doubts about this over something like this, dotnet mytool --version, my CLI tool knows how to process the version command line argument, and should respond along the lines of Tooling version is 1.0.0.4505 (Error Level: 0)., rather, is responding along these lines, Running MyTool v0.6.1+2b937a442a .... I have no idea where 0.6.1 is coming from. None whatsoever. Not my CLI tool, I can promise you that.

At its core, I think possibly I need to see better documentation how to pass command line arguments to my CLI tool.

[mwpowellhtx]

@davidfowl I think I've run into what I think is most likely a naming conflict with an already existing nuget dotnet-mytool package. Not literally, but in pattern. It does already exist, I know that for a fact. What is a mystery to me is why dotnet, nuget, msbuild, not necessarily in that order, or one of its surrogate(s), did not fall back on the project artifacts which were there and available as a natural part of the build pipeline. In other words, why it would want to default to nuget package source(s)?

[plioi]

@mwpowellhtx Since this is a 3 year old, closed, unrelated issue, you'll probably get more eyes and feedback by opening a new issue.

[mwpowellhtx]

@plioi I did actually, thanks...