"dotnet exec" needs to be listed in -h

[ljw1004]

Steps to reproduce

(1) do dotnet -h (2) do dotnet exec -h

Expected behavior

(1) should list exec amongst the possible command (2) should provide help about dotnet exec

Actual behavior

(1) it doesn't (2) it doesn't

Environment data

dotnet --info output:

.NET Command Line Tools (1.0.0-beta-002133)

Product Information:
 Version:     1.0.0-beta-002133
 Commit Sha:  a21e0ea6b4

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.10240
 OS Platform: Windows
 RID:         win10-x64

[davidfowl]

What is dotnet exec?

[ljw1004]

@davidfowl exactly :)

[TheRealPiotrP]

/cc @blackdwarf @schellap @gkhanna79

dotnet-exec should be an implementation detail of other commands like dotnet run. I don't see a need to advertise it directly nor to drive folks towards its usage. Why do you feel that the value of this command to an end-user is worth the concept count?

[gkhanna79]

I concur with @piotrpmsft. Exec is an internal implementation detail and not a formal command.

There should not be a need to doc it.

[blackdwarf]

Agreed with @gkhanna79 and @piotrpMSFT. dotnet run is something that should be used.

[ljw1004]

@piotrpMSFT I don't think the value is worth the concept count. I have a different take. It gives me the willies that the tools I depend upon have secret undocumented switches and functionality. I've never seen this in any other tool I use and don't know why dotnet deserves to be the first.

[gkhanna79]

@ljw1004 This is no different from universal host depending upon the layout of deps.json, as an example, which is an internal implementation detail.

[ljw1004]

@gkhanna79 you're making this sound worse not better :)

[blackdwarf]

All tools have implementation details. dotnet exec is not something that the user is supposed to call directly. The behavior of --help is by design, so closing this issue.

[vincentwoo]

I would lobby for this to be reopened. The dotnet run CLI is very slow, especially on Linux, and doing a manual build + exec tends to be faster. Unfortunately, exec seems undocumented.

[sartan]

I'd like to share another use case for dotnet exec over dotnet run.

In my integration test, I need to run the application dll and kill it after the test completes. My initial implementation used dotnet run, however dotnet run apparently spawns another process with dotnet exec. This presents a challenge when I want to "clean up" and kill the spawned process. I can capture the dotnet run process and kill it, but the dotnet exec remains orphaned. So I reimplemented the test to use dotnet exec directly.

All of this to say that dotnet exec has value for me as a developer, but it not documented.

[livarcocc]

Why do you need explicitly dotnet exec? Why not just run dotnet <path_to_your_dll>? Also, dotnet run should not be used to run applications in a production capacity. Think of dotnet run as the equivalent of F5 in VS. If you are executing a published application, you should use dotnet <path_to_your_dll> if the app is a Framework Dependent App or app.exe if it is a self-contained app.

[ViktorHofer]

How would I use runtime-options together with dotnet or dotnet run? dotnet exec seems to be the only verb that accept those. In example from corefx:

"C:\git\corefx4\artifacts\bin\testhost\netcoreapp-Windows_NT-Debug-x64\dotnet.exe" exec --runtimeconfig System.Text.RegularExpressions.Tests.runtimeconfig.json xunit.console.dll System.Text.RegularExpressions.Tests.dll -xml testResults.xml -nologo -notrait category=nonnetcoreapptests -notrait category=nonwindowstests -notrait category=OuterLoop -notrait category=failing

[n8kennedy]

If the command isn't supposed to be used, then at the very least it shouldn't be referenced in documentation. It's also confusing if you check the web.config for a .NET Core web application and see "exec" in the arguments passed to the dotnet command - which is how I came to find it. If users aren't supposed to use the command directly, then say so in the documentation. But don't cause confusion by using referencing the command in multiple places, but NOT documenting it.

[RikkiGibson]

I recently found docs which specifically recommend usage of dotnet exec. https://docs.microsoft.com/en-us/dotnet/core/diagnostics/dotnet-trace#dotnet-trace-collect

Using this option monitors the first .NET 5.0 process that communicates back to the tool, which means if your command launches multiple .NET applications, it will only collect the first app. Therefore, it is recommended you use this option on self-contained applications, or using the dotnet exec <app.dll> option.

[mwasplund]

I also found it confusing when looking through the logs of a build and see it is running code using an undocumented 'exec' command instead of the normal 'run'.

[kyle-dgcapital]

I have found dotnet exec in multiple places in the wild, such as AWS EB procfiles and Dockerfiles. Not being able to look up documentation from a single source of truth is frustrating - people are using this switch, whether by MS design or not. Either kill it or document it, and I very much doubt you can kill it at this stage.