Running "dotnet -v diag run" shows diagnostics but fails to run
See original GitHub issueSteps to reproduce
C:\Users\scott\Desktop\newdotnet\src\project1> dotnet -v diag run
Telemetry is: Enabled
projetfactory: MSBUILD_EXE_PATH = C:\Program Files\dotnet\sdk\1.0.0-preview4-004233\MSBuild.dll
projetfactory: MSBuild project path = C:\Users\scott\Desktop\newdotnet\src\project1\project1.csproj
projecttoolscommandresolver: resolving commandspec from 0 Tool Libraries.
projecttoolscommandresolver: failed to resolve commandspec from library.
Microsoft.DotNet.Cli.Utils.CommandUnknownException: No executable found matching command "dotnet-diag"
at Microsoft.DotNet.Cli.Utils.Command.Create(ICommandResolverPolicy commandResolverPolicy, String commandName, IEnumerable`1 args, NuGetFramework framework, String configuration, String outputPath, String applicationName)
at Microsoft.DotNet.Cli.Utils.Command.Create(String commandName, IEnumerable`1 args, NuGetFramework framework, String configuration, String outputPath, String applicationName)
at Microsoft.DotNet.Cli.Program.ProcessArgs(String[] args, ITelemetry telemetryClient)
at Microsoft.DotNet.Cli.Program.Main(String[] args)
Expected behavior
Note that the diagnostics shows indicating that -v got the “diag” switch but then it tries to run dotnet-diag.
Environment data
dotnet --info
output:
.NET Command Line Tools (1.0.0-preview4-004233)
Product Information:
Version: 1.0.0-preview4-004233
Commit SHA-1 hash: 8cec61c6f7
Runtime Environment:
OS Name: Windows
OS Version: 10.0.14986
OS Platform: Windows
RID: win10-x64
Base Path: C:\Program Files\dotnet\sdk\1.0.0-preview4-004233
Issue Analytics
- State:
- Created 7 years ago
- Comments:10 (4 by maintainers)
Top Results From Across the Web
Visual Studio unable to run .NET Core tests
NET Core 2.1, so to run the tests it needed to look in the x64 folder path. How installations look from Add or...
Read more >VS 2017 Diagnostic Tools Failed Unexpectedly
After debugging my dotnet core app the diagnostic tools window show an error and says it failed unexpectedly. It says the output window...
Read more >Diagnostic Tools and Performance Profiler are Unstable ...
Start the debugger with Diagnostic Tools CPU profiling turned off (this is important, as if it starts on then the data processing with...
Read more >Fix .NET Framework 'This application could not be started'
When you attempt to run a .NET Framework application, you may receive the "This application could not be started" error message.
Read more >dotnet test command - .NET CLI
The dotnet test command builds the solution and runs a test host application for each test project in the solution. The test host...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
OK, I think we should use this issue to rename the
-v | --verbosity
to-d | --diagnostics
to allow differentiation. As chatted offline @livarcocc I’m assigning this to you.@schellap thanks for the info. slightly_smiling_face: This changes my suggestion above insofar as the potential change is not in the muxer (and the fact that not all options preceeding the verb are muxer options) but in
dotnet.dll
. I still think thatdotnet -v run -v diag
is not super clear.For
dotnet run
, we already have a convention that--
is used to disambiguate between verb’s and app’s arguments. But yeah, your other point is good, there needs to be crisp documentation on this as part of https://docs.microsoft.com/en-us/dotnet/articles/core/tools/index. Can you file an issue for this on dotnet/docs and /cc me?