dotnet.exe host should have a --debug switch

[eerhardt]

Steps to reproduce

It is too hard to debug applications when they aren't launched from VS. Today, you need to add some "Console.ReadLine()" calls in order to have the process wait for you to attach to the process.

Expected behavior

There should be an easy way to say "launch this .net core app and attach a debugger" or "wait for a debugger to be attached".

Actual behavior

This isn't possible today.

Notes

I think even if we enabled something simple in the host like:

if --debug is passed before the assembly to run, print out a message like: "DEBUG MODE: attach a debugger to process <process id> and then hit ENTER to continue". That waits for the ENTER, and then your entry method is invoked.

/cc @schellap @gkhanna79 @piotrpMSFT @blackdwarf @brthor @ericstj @weshaggard

[gkhanna79]

@eerhardt Are you not able to use VS debugger do the same by pointing it to a command line?

[eerhardt]

Are you not able to use VS debugger do the same by pointing it to a command line?

That approach is less than ideal because:

1. I need to create a dummy project so I can tell VS to "point to a command line"
2. I need to ensure I created a .NET Core dummy project.
   • If I use a Windows Desktop C# console app I get an error:

---------------------------
Microsoft Visual Studio
---------------------------
A fatal error has occurred and debugging needs to be terminated. For more details, please see the Microsoft Help and Support web site. HRESULT=0x8000ffff. ErrorCode=0x0.
---------------------------
OK   
---------------------------

1. Maybe I don't have VS, and I only have WinDBG, or some other debugger. When I move my app into "production" or off of my dev box, I don't want to install full VS just to debug the app.
2. Maybe my intent isn't to do traditional VS debugging, but instead I want to get the process ID and do some other monitoring while the app runs.

[blackdwarf]

@eerhardt so, in summary, the proposal is to, at least, have an easy way for people to get a PID of the host running?

[eerhardt]

BTW - without this 'feature', folks have been inventing it themselves by using DebugHelper.HandleDebugSwitch and copying that file around.

See https://github.com/search?p=3&q=org%3Adotnet+DebugHelper&type=Code for all the places it is used in our 'dotnet' repos today.

[eerhardt]

so, in summary, the proposal is to, at least, have an easy way for people to get a PID of the host running?

AND pause the app until I say "GO"

[blackdwarf]

@eerhardt got it. The pause part is actually the more useful one, as getting the PID can be done in different ways. I have to say, this could be useful actually, from a user's POV.

[schellap]

@eerhardt trying to understand this ask... how did desktop framework work without this feature?

AFAIK, no program suspends on its own for a potential debugger attach, so why should a managed program host do this?

[eerhardt]

no program suspends on its own for a potential debugger attach

See my link above. That shows at least 3 programs that we wrote in the CLI and in core-setup.

Also, CoreRun.exe does this today:

C:\cli>\core-setup\pkg\Tools\CoreRun.exe /d
Runs executables on CoreCLR

USAGE: coreRun [/d] [/v] Managed.exe

  where Managed.exe is a managed executable built for CoreCLR
        /v causes verbose output to be written to the console
        /d causes coreRun to wait for a debugger to attach before
         launching Managed.exe

  CoreCLR is searched for in %core_root%, then in the directory
  that coreRun.exe is in, then finally in %windir%\system32\.

I won't go searching for all the programs in the world that do this, but suffice it to say, this seems valuable to a lot of people if we have that DebugHelper class, and CoreRun.exe implemented it. And the only reason I knew about CoreRun.exe is because @rainersigwald pointed it out to me, because he uses it. So we have users outside of the .NET team who use this switch in CoreRun.

how did desktop framework work without this feature

desktop framework was very "VS centric". .NET Core runs on platforms VS isn't capable of running on.

[rainersigwald]

@schellap The problem is that it's easy to vsjitdebugger.exe MyProgram.exe or windbg.exe MyProgram.exe or set ImageFileExecutionOptions to break into the start of a desktop executable. Those are much less desirable here because I don't want to step into the CLR host--I want to step into my program.

Also, every program I maintain has a clause like this:

if (Environment.GetEnvironmentVariable("{something}DEBUGONSTART") == 1)
{
    Debugger.Launch();
}

Sure would be nice if it were built in.

[schellap]

@rainersigwald and @eerhardt, thanks. We can bake this in with some switch that doesn't conflict with dotnet.dll.

@eerhardt, sorry... I wanted to call out that most programs native or managed (incl. Desktop apps) don't have this support, for these handful of programs you quoted. They are being debugged fine... did not ask to list what programs do this today.

[gkhanna79]

I guess I still have more questions to understand this better. If the goal is to attach the debugger before any managed application is launched, then doing "windbg dotnet <app.dll>" is equivalent to what you are requesting for.

@rainersigwald Can you please explain your workflow while using the switch? Is it the case that you do not own the process that launches the application?

[rainersigwald]

@gkhanna79 I use this all the time to debug unit tests with xunit: corerun /d xunit.console.netcore.exe ....

I like being able to use VS to debug using the session I'm using to develop, with persistent breakpoints and mental state built up over multiple runs of the program under test. But when the entry-point application is a netcore app that's not my code, it's really inconvenient to set VS up to launch it.

Maybe there's a better way, but the only way I know is to create a new bogus xproj and configure it to launch the application. My mental cost/benefit calculation always makes it seem like it's cheaper to launch with the debug flag and manually attach from my VS.

Just prefixing the command line with vsjitdebugger.exe almost works, but it launches in native-debugging mode and doesn't hit managed breakpoints.

If there's an actually-easy way to get a running instance of VS to attach to a short-lived program via command line, I'd be happy. This seems like a way to get that.

[danmoseley]

@gkhanna79 this sounds like a feature, and we're past feature complete..

[gkhanna79]

Yeah, this nice to have and can move out.

[jamesqo]

I would also like to have this option for so I can debug during dotnet test.

[gingters]

If you think about implementing that, please make sure that the implementation does not print to console.

If you write a .net core console application that is used to stream out some data into stdout and you want to pipe that to another console application, any extra console output will mess that up.

[steveharter]

Moving this out again; feature complete is next week and this won't make it

[steveharter]

Moving to 3.0

cc @jeffschwMSFT

Summary:

1. Corerun already does this coreclr's corerun /d switch
2. Add the PID to the message to make attaching easier
3. To prevent interferrence of the running application, do not display a message to stdout\stderr by default, or display by default but provide a way to turn that off. Consider using the existing COREHOST_TRACE and -v options (need to discuss)

[eerhardt]

See https://twitter.com/migueldeicaza/status/1013061980284997632?s=21 for others talking about this same thing. It would be great if this was just built in to the platform. (Note the link to the tweet about forgetting to remove Thread.Sleep(30s) from the code, causing slow startup)

[gholt-aws]

I'd love to see this make it into 3.0.
If this is accurate (dotnet/vscode-csharp#1059), getting this feature would be very helpful.

[jeffschwMSFT]

I would like to get @tommcdon perspective on this feature ask.

[tommcdon]

Adding @noahfalk and @mikem8361. The "wait for attach" approach sounds interesting and is potentially useful, esp for remote VS debug scenarios.

[mikem8361]

We need to be clear about what the flag is waiting for: a native debugger attach (which is what corerun's /d is waiting for) or a managed debugger attach (like from VS or VSCode). These are very different features.

[abatishchev]

Maybe --vsdebug then? To be clear in the intend. However since this is .NET I would assume VS debugger by default. That's what 99.98% of customer would need, imo.

[mikem8361]

I don't think we can assume what debugger is going to used. It depends on the dev. Some devs want to debug the runtime itself or debug natively using VS, windbg, cdb on Windows or lldb on Linux/MacOS. Others may want to debug the just the managed code using VS/VSCode on Windows or VSCode on Linux/MacOS.

Either we purpose two flags like "--native-debug" and "--managed-debug" or be very clear about which scenario we are talking about here.

[abatishchev]

Maybe then --debug <name> with the support of few to begin with and with a way to extend the list in the future?

[adaviding]

I want to help convince people that this is an important feature by looking at an example from the Java ecosystem. This may also inform the design that you eventually choose.

Ever since Java 1.3 (or maybe 1.5), when you launch a java program, you can pass args like the following to java.exe:

-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=1234

The JRE then acts like a remote debugging host over port 1234. I understand that dotnet has vsdbg which doesn't use ports, but we can ignore that difference for now. Take a look at the suspend= part of the string.

• suspend=y would imply that program execution is suspended until a debugger is attached
• suspend=n would imply that the program runs normally, and only halts if a debugger asks it to (once attached).

I think --suspend would be good nomenclature for you guys to use in this case.

dotnet run --suspend ...

[adaviding]

I would also like to suggest that being able to specify a unique port at startup eliminates the need to know the PID of the process that you are trying to debug. I get that you have committed to using vsdbg instead of ports, but maybe there is a way to pass some unique integer (e.g. 1234) when the program is started up ...

dotnet run --debug 1234 --suspend ...

... such that you can now ask vsdbg to connect to the process where 1234 was uniquely specified, so you don't need to know the PID anymore.

[danmoseley]

@shirhatti

[loligans]

This functionality would be tremendously helpful when debugging startup issues in a remote container.

[abatishchev]

@jeffschwMSFT any chance this can be addressed since June 2016? That would be really helpful, a lot. My example: when a Service Fabric services which is just a dotnet.exe run command (aka a guest executable) fails on startup by whatever nonobvious reason)without any traces lefts other than non-zero error code - it's painful, frustrating, and hard to debug.

[KathleenDollard]

Question: Now that we have self-contained and runtime-dependent executables, is this feature needed only when doing dotnet run and dotnet <assemblyFileName>?

The approaches suggested here only work in that scenario because any variation of --debug may already be a switch.

System.CommandLine solved this by providing an alternate syntax for switches going to the startup model [debug] but unless the community strongly coalesced around an alternate syntax, I don't see a good answer for the executable scenarios.

[fredrikhr]

Well if the dotnet.exe used the System.CommandLine for parsing its args, then that would be great too (you'd get [debug] for free)

[dave-yotta]

Yes please, It's a pain to debug tests/apps in (e.g. local) kube clusters (and this should be the de-facto standard imo), and VS is so so slow to release support in tools for these environments. And half of my team don't use VS anyway, and some others aren't even on windows. Anything to make this easier and remove random stuff from our code/tooling.

Moved rant to end: And then it's some convoluted stuff e.g. that docker stuff that's supported in the csproj with some rapid build stuff, or connect to azure kube cluster but don't actually run your app in it - most of us have a local kube cluster or some other cloud service...just such a pain, I have just a container for you to connect to and run a proc my dude, I've mounted my host/source fs, when I press F5 or run test...why so complex?

I swear I'm going to write a extension for vs that supports remote/container test run and debug at some point, it's like, an excel macro of a few clicks at best. I'm sure the laggy test explorer is easily replaced too, for those who have ever virtualized a listview 🤦

[wasabii]

Something nobody here has thought of: this would be nice to exist on compiled platform dependent executables as well. And that means if you use command line arguments, you'd be getting in the way of their processing.

An environmental variable might be better.

[dave-yotta]

Don't think it would get in the way: dotnet run --debug MyApp.dll <arguments here>?