Add process launch semantics to dotnet-monitor

[samsp-msft]

Background and Motivation

While setting up dotnet-monitor is not especially hard as a sidecar, it is one more step to think about, and get right from a configuration perspective.

Proposed Feature

Simplify the launch of dotnet-monitor and the application by adding the ability for dotnet monitor to launch the process to be examined. This then means you don't need figure out the target process, as it's the one that launched it.

Usage Examples

dotnet-monitor MyApplication1.dll

Launches dotnet-monitor and starts the process for MyApplication as if dotnet MyApplication1.dll had been called

dotnet-monitor MyApplication1

Launches dotnet-monitor and MyApplication1 with dotnet-monitor monitoring whatever process chain is created from MyApplication1.

dotnet-monitor -launchSuspended MyApplication1.dll

Launches the application, but suspended until a trace action is started via the http endpoint

dotnet-monitor <-args> MyApplication1.dll <args2>

All arguments that start with a - before the first non - delimited arg can be considered as belonging to dotnet-monitor. Ones after that should belong to whatever command is executed by dotnet.

[wiktork]

Note this would only work in scenarios where the app and dotnet-monitor live in the same container. I don't think we can spawn processes across container boundaries.

[samsp-msft]

Correct - this is about creating a simpler deployment option.

[jander-msft]

dotnet-monitor MyApplication1.dll

Launches dotnet-monitor and starts the process for MyApplication as if dotnet MyApplication1.dll had been called

dotnet-monitor MyApplication1

Launches dotnet-monitor and MyApplication1 with dotnet-monitor monitoring whatever process chain is created from MyApplication1.

@samsp-msft, I'm not sure I understand the distinction between these two and I'm not sure that the difference would be apparent based on whether the entry point assembly has an extension on it or not. Would you mind further elaborating?

[samsp-msft]

It depends on whether the entrypoint is a dll or executable. The former today requires dotnet to run, and that seems to be what VS does in its docker templates. I expect that people will also do a publish to an executable, so both forms need to be supported. We can't rely on exe's having the exe suffix on linux - which is probably the main deployment target. It should be a FileInfo argument for system.commandline, and then launch with dotnet if the extension is dll

Customer research is showing that there is a total lack of knowledge about the dotnet-* diagnostics tools, and when users do try to use them, they are too complicated to setup.

This and #3008 go together in how to make dotnet-monitor easier to use on its own instead of as a component in a larger monitoring environment. It turns out that many users don't seem to have the bigger system built out, so are not using it as it really requires the rest of the environment to be useful. I think if we can make it brain-dead simple to use for the one-off case, it will become part of the standard practice, rather than unusual case.

I suspect we get most traction with logging today because we put the output directly into the user's face. Even then, most are harvesting as a text stream, rather than structured messages.

Ideally running under dotnet-monitor could become something that is included as an option in the templates as part of the docker build and as an option in launch.json so that the monitoring is shown as part of running the application. This work-item as an option means that you don't need to figure out how to run as as a side car, and then once running to query the process list and attach to be able to make progress. Adding in a web UI (#3008, #17) would enable users to see the results immediately, especially for metrics and logs - which should be in the default UI screen. It would put traces & dumps a couple of clicks away, and would ideally launch straight into VS when they are downloaded.

The nice thing is that this functionality would be complementary to what is already in dotnet-monitor - it wouldn't harm scenarios where dotnet-monitor is already being used as a sidecar.

[samsp-msft]

@davidfowl asked what would happen if the app is no longer PID=1. The answer is that you'd need to pass along the SIGTERM to the child process, and possibly redirect its console input/output.