New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

dotnet.exe host should have a --debug switch #198

Open
eerhardt opened this Issue Jun 30, 2016 · 26 comments

Comments

Projects
None yet
@eerhardt
Copy link
Member

eerhardt commented Jun 30, 2016

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

This comment has been minimized.

Copy link
Member

gkhanna79 commented Jun 30, 2016

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

@eerhardt

This comment has been minimized.

Copy link
Member

eerhardt commented Jun 30, 2016

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

This comment has been minimized.

Copy link
Contributor

blackdwarf commented Jun 30, 2016

@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

This comment has been minimized.

Copy link
Member

eerhardt commented Jun 30, 2016

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

This comment has been minimized.

Copy link
Member

eerhardt commented Jun 30, 2016

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

This comment has been minimized.

Copy link
Contributor

blackdwarf commented Jun 30, 2016

@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

This comment has been minimized.

Copy link

schellap commented Jun 30, 2016

@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

This comment has been minimized.

Copy link
Member

eerhardt commented Jun 30, 2016

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

This comment has been minimized.

Copy link

rainersigwald commented Jun 30, 2016

@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

This comment has been minimized.

Copy link

schellap commented Jun 30, 2016

@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

This comment has been minimized.

Copy link
Member

gkhanna79 commented Jul 5, 2016

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

This comment has been minimized.

Copy link

rainersigwald commented Jul 5, 2016

@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.

@gkhanna79 gkhanna79 added this to the 1.1.0 milestone Jul 12, 2016

@gkhanna79 gkhanna79 modified the milestones: 1.2.0, 1.1.0 Sep 19, 2016

@ramarag ramarag assigned ramarag and unassigned schellap Nov 1, 2016

@danmosemsft

This comment has been minimized.

Copy link
Member

danmosemsft commented Apr 28, 2017

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

@gkhanna79

This comment has been minimized.

Copy link
Member

gkhanna79 commented Apr 28, 2017

Yeah, this nice to have and can move out.

@gkhanna79 gkhanna79 modified the milestones: 2.1.0, 2.0.0 Apr 28, 2017

@gkhanna79 gkhanna79 assigned steveharter and unassigned ramarag Jun 8, 2017

@jamesqo

This comment has been minimized.

Copy link

jamesqo commented Jun 10, 2017

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

@steveharter steveharter removed their assignment Jan 10, 2018

@gingters

This comment has been minimized.

Copy link

gingters commented Feb 22, 2018

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

This comment has been minimized.

Copy link
Member

steveharter commented Feb 22, 2018

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

@steveharter steveharter modified the milestones: 2.1.0, Future Feb 22, 2018

@steveharter

This comment has been minimized.

Copy link
Member

steveharter commented Jun 5, 2018

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)

@steveharter steveharter modified the milestones: Future, 3.0 Jun 5, 2018

@eerhardt

This comment has been minimized.

Copy link
Member

eerhardt commented Jun 30, 2018

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

This comment has been minimized.

Copy link

gholt-aws commented Oct 3, 2018

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

@jeffschwMSFT

This comment has been minimized.

Copy link
Member

jeffschwMSFT commented Oct 3, 2018

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

@tommcdon

This comment has been minimized.

Copy link
Member

tommcdon commented Oct 3, 2018

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

@mikem8361

This comment has been minimized.

Copy link
Member

mikem8361 commented Oct 3, 2018

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

This comment has been minimized.

Copy link

abatishchev commented Oct 3, 2018

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

This comment has been minimized.

Copy link
Member

mikem8361 commented Oct 3, 2018

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

This comment has been minimized.

Copy link

abatishchev commented Oct 3, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment