Running dotnet-counters in the background fixes #1098

[mikelle-rogers]

I started looking at this issue, here are my main thoughts. Does this seem to be on a right track? I assumed that part of what running in the background meant that there would not be anything printed to the Console, is this correct?

[noahfalk]

part of what running in the background meant that there would not be anything printed to the Console, is this correct?

We can make educated guesses, but the only way we'll know for certain what the original poster in #1098 had in mind will be to ask them. I see the issue is a bit over a year old so there is no telling if they will notice or still be interested, but there is little harm in asking. If I were to make an educated guess there are two things to look at:

1. When run in the background (ie dotnet-monitor collect <args> &) dotnet-monitor shouldn't crash. The poster included an Exception stacktrace that looks like it does crash currently.
2. When run in the background dotnet-monitor should either have no console output or it should just have a small amount of initial output. It may already be working this way once the crash issue is resolved.

@sywhang proposed a --background argument but I think we should also investigate if it is possible to have the app auto-detect when it is running in the background so that users don't have to remember any special arguments. The convention most Linux users would expect is that adding & at the end of the command-line is sufficient.

[josalem]

It's worth pointing out that one of your previous PRs may have partially implemented the ability to run in the background: #2466.

You fixed it so that it only calls the excepting API if input is not redirected (Noah's point 1).

I concur with Noah that there should be a little more consideration around use case. Running monitor in the background is different from running collect in the background for instance.