"dotnet exec --help" should print help #3089
Description
@jcouv commented on Thu Nov 02 2017
>dotnet --help says to Run 'dotnet COMMAND --help' for more information on a command. amongst other things.
Yet >dotnet exec --help only prints an error message: dotnet exec needs a managed .dll or .exe extension. The application specified was '--help'.
I expect this should print usage information.
I'm using 2.1.1-preview-007094 (dotnet --version)
@livarcocc commented on Thu Nov 02 2017
This is by design.
exec is not really a CLI verb, but rather a parameter to the host. It is an advanced command that you should not need to use it.
To run your application, you just need to run dotnet <path_to_your_dll>.
Also, this is a host (dotnet.exe) parameter. If you feel strongly about changing this, please open an issue at core-setup.
@jcouv commented on Fri Nov 03 2017
@livarcocc Here's the scenario that motivated this issue:
I was trying to run some Roslyn tests on Core runtime on Window. We already have a build output, so I figured I should be able to do something equivalent to the desktop world: xunit.console.exe <path_to_my_dll>.
There is such an equivalent: dotnet exec --depsfile ... --runtimeconfig ... <path_to_netcoreapp2.0_xunit_console_dll> <path_to_my_dll> and our build output already has all the right files.
But I had tried this without --depsfile or --runtimeconfig, and would not have been able to discover those options because dotnet exec --help doesn't document them.
Luckily, some Roslyn automation already uses those options and I discovered them that way.
Other things I tried:
dotnet test <path_to_test_csproj>(error: cannot findcsc.dll)dotnet xunit <path_to_test_dll>(I don't remember the problem there)
@livarcocc commented on Fri Nov 03 2017
Why dod you need to use exec? Why not just dotnet <path_to_your_dll>?
Also, like I said, maybe move this issue to core-setup.
@wweeder commented on Thu Mar 22 2018
I feel the pain of the OP. MS products are extremely klugey and opaque. This is why many development professionals don't even take any MS products seriously, period.
I wish MS engineers would not ask 'why would I want to know', or say things like 'It is an advanced command that you should not need to use it'. This shows an extremely counter productive culture for MS. Just expose everything your software does -everything.
MS is no longer cranking out products for clueless users. MS is trying to join the modern world with offerings that are compatible with modern delivery processes. There is no room for obfuscation anymore. None whatsoever.
Visual studio uses dotnet. I am building dotnet applications using the dotnet CLI. I have massive difficulties trying to reproduce visual studio builds, because VS behaves differently than the dotnet CLI makes clear, using undocumented tools and flags exactly like the OP describes. VS simply doesn't expose it's operations (to me, the owner and operator of the software).
No, having visual studio installed everywhere is not an option, you shouldn't even ask. MS should purge every employee who believes there is value in hiding, omitting, or failing to expose any of it's products details to the users. We're not talking about children and the elderly trying to run microsoft office, we are talking about IT professionals who actually read technical documentation.
@jcouv commented on Thu Mar 22 2018
@livarcocc I'm not sure what you mean by dotnet <path_to_my_dll>. Did you mean dotnet <path_to_netcoreapp2.0_xunit_console_dll> <path_to_my_dll>?
I'm was trying to test some assemblies with xunit, and struggled to find the --depsfile and --runtimeconfig options. Is there any dotnet command which provides documentation for those two options?