Diagnostics: dotnet "tool" Support process name as an argument

[davidfowl]

Now that we have exe's it would be great if we could support passing a process name instead of a pid (I hacked this into my current branch for testing). It would make inner loop scenarios more friendly as it doesn't require changing the command line every time.

dotnet monitor -n WebApplication269 Microsoft.AspNetCore.Test System.Runtime

PS: I also made my logic work without being an exact match so you could potentially do something like:

dotnet monitor -n WebApp Microsoft.AspNetCore.Test System.Runtime

If there was a single process running with that name (one running an event pipe endpoint) then it would use that pid.

cc @shirhatti

[shirhatti]

I've been resorting to this in the meanwhile 😄

dotnet counters monitor -p `pgrep MyApp`

[davidfowl]

This should be the case for all dotnet tools:

> dotnet trace ps
10004 BackEnd    C:\dev\git\aspnetcore-app-workshop\src\BackEnd\bin\Debug\netcoreapp3.0\BackEnd.exe                                                                
38348 dotnet     C:\Program Files\dotnet\dotnet.exe                                                                                                                 
9324 iisexpress C:\Program Files\IIS Express\iisexpress.exe                                                                                                  
> dotnet trace collect -p 10004 --providers Microsoft-Extensions-Logging:C:4

Ideally I could do:

> dotnet trace collect -p BackEnd --providers Microsoft-Extensions-Logging:C:Informational

[davidfowl]

What makes this nice is that we already start from a filtered set of processes since we're only looking at event pipe based processes. The other nice thing is that we have executable names in 3.0 which makes conflicting less of a problem (everything isn't called dotnet anymore).

[samsp-msft]

If we did this, it would be great if the listener was then not bound to a process lifetime. If you could start the listener with a process name, and it would sit there doing nothing until a process with that name starts, then logs, and could continue after the process has ended. That way monitoring tools could be more resilient to process restarts, and also be able to capture startup scenarios.

[tommcdon]

If we did this, it would be great if the listener was then not bound to a process lifetime. If you could start the listener with a process name, and it would sit there doing nothing until a process with that name starts, then logs, and could continue after the process has ended. That way monitoring tools could be more resilient to process restarts, and also be able to capture startup scenarios.

Startup tracing is tracked on #619

[sywhang]

Closed with #1161