Remote Debugging with Docker? #220

tonysneed · 2016-04-19T08:40:30Z

Node.js 4.x supports remote debugging, and VS Code is able to place nicely with it. I'm wondering if anyone know if .NET Core supports remote debugging? I seem to recall a part of @shanselman's Build demo where he used the VS Tools for Docker to remote debug into a Docker container. But I can't remember if the container was running .NET Core. I'd be grateful for any information on this.

tonysneed · 2016-04-19T08:45:02Z

Thinking this question probably is more relevant to the .NET Core repo, so I posted it over there as well.

gregg-miskelly · 2016-04-19T15:29:15Z

Yes, in in the build demo the container was running .NET Core.

Are you asking about VS Code or VS?
For VS - yes, debugging support hasn't been released yet, but we expect to release it soon.
For VS Code - we don't have support for this yes.

tonysneed · 2016-04-19T22:10:56Z

@greg-miskelly Thanks for answering my question. Technically what is it that VS Code needs to support remote debugging for .NET Core?

gregg-miskelly · 2016-04-19T23:09:29Z

'Remote Debugging' is kind of a big area as there are lots of different scenarios that might be interesting -- ex: remote to Docker containers, remote to a stand along Linux server over SSH, remote to a Windows PC, remote to Azure, etc.

Lets talk about Docker as that is probably the easiest one to accomplish. For that we need:

Support for building and deploying Docker images that we can leverage. This is the majority of the work.
Some minor changes to consume the functionality we are already using in Visual Studio so that we can run the backend of the .NET Debugger (clrdbg) inside the container of the target app using 'docker exec' instead of on the IDE computer.
Tweaks to the launch.json format to indicate that Docker should be used.

My guess is that this isn't going too far away. But right now the VS Docker Tools folks are concentraiting on getting the VS end-to-end ready to be shipped.

tonysneed · 2016-04-20T06:12:13Z

@gregg-miskelly, Thanks for the clear explanation - helps to understand what has to be done. Glad you addressed the Docker scenario, which is what I'm most interested in.

Support for building and deploying Docker images that we can leverage. This is the majority of the work.

I've seen some traction on creating updated Docker images. See this issue on the dotnet/cli repo. And it "feels" like RC2 may be getting close. 😄

Some minor changes to consume the functionality we are already using in Visual Studio so that we can run the backend of the .NET Debugger (clrdbg) inside the container of the target app using 'docker exec' instead of on the IDE computer. Tweaks to the launch.json format to indicate that Docker should be used.

Maybe these are low hanging fruit? 😉

gregg-miskelly · 2016-04-20T15:57:54Z

In terms of the debugger work - yes, I think this work should be pretty easy.
In terms of the image build work - it may be, but I don't know enough how the VS Docker Tools works to say.

janaka · 2016-06-27T02:31:47Z

@gregg-miskelly @rajkumar42

I was wondering what the latest was with this? Is all the functionality available in theory for me to try hook it up?

I've seen commit https://github.com/OmniSharp/omnisharp-vscode/pull/415/files referencing Docker related changes.

I've tried stumbling around using ^^ and https://github.com/Microsoft/MIEngine/wiki/Offroad-Debugging-of-.NET-Core-on-Linux---OSX-from-Visual-Studio as ref but not go it working yet.

I'm trying to get VS Code to attach to the clrdbg in docker without installing Dotnet core clr locally on OSX.

When I try and launch the debugger I get the Run 'Debug: Download .NET Core Debugger' in the Command Palette or open a .NET project directory to download the .NET Core Debugger error.

My launch config:

 {
           "name": ".NET Core Launch (Docker)",
            "type": "coreclr",
                        "request": "launch",
            "program": "${workspaceRoot}/src/dotnetstarter/bin/Debug/netcoreapp1.0/dotnetstarter.dll",
            "args": [],
            "cwd": "${workspaceRoot}",
                        "pipeTransport": {
                "pipeCwd": "${workspaceRoot}",
                "pipeProgram": "enter the fully qualified path for the pipe program name, for example 'c:\\tools\\plink.exe'",
                "pipeArgs": [],
                "osx": {
                    "pipeCwd": "${workspaceRoot}",
                    "pipeProgram": "/usr/local/bin/docker",
                    "pipeArgs": ["run", "-it -p 5000:5000 -v /Users/janaka.abeywardhana/code-projects/aspnet-core-helloworld:/myapp microsoft/dotnet-preview:latest /bin/sh", "-c 'curl -sSL https://raw.githubusercontent.com/Microsoft/MIEngine/getclrdbg-release/scripts/GetClrDbg.sh | bash /dev/stdin latest ~/clrdbg; ~/clrdbg/clrdbg --interpreter=mi; cd myapp/src/dotnetstarter; dotnet restore; dotnet run --server.urls=http://0.0.0.0:5000;"]
                }
            }

        }

gregg-miskelly · 2016-06-27T06:08:08Z

@janaka The Visual Studio Docker Tools team is working on scaffolding to use the pipeTransport to enable debugging from VS code. I am not sure if it has been released yet though @SteveLasker?

You will however still need to install the .NET CLI locally - we still depend on it for running the local parts of the debugger, doing builds, etc.

SteveLasker · 2016-06-27T14:57:34Z

Thanks. @gregg-miskelly
@janaka last week, we released http://aka.ms/yodocker for debugging .net core apps with vs code in a Linux container. Yo docker also supports Nod.js.
You may also want http://aka.ms/DockerToolsForVSCode to get docker language services.
I am curious what type of apps your looking to debug. Web, APIs, console , ???
Thanks,
Steve

SteveLasker · 2016-06-27T14:57:59Z

Well release .NET Core RTM versions today

janaka · 2016-06-27T16:52:09Z

@SteveLasker @gregg-miskelly Thanks.

Sounds like the Yo generator will answer more of my questions I'll dig in later.

As we (Hudl.com) adopt .Net Core it could be any of those. I've been using a Web app and an API to experiment with things .Net Core and Docker related.

A lot of our devs are on Mac. Today they have to develop in Parallel, the developer experience sucks. With debugging in Docker I'm thinking about the developer experience and how that can connect to deploying to test and prod environments, the development workflow.

akku27 · 2016-08-23T15:32:33Z

Pls let me know if I can remote debug a container on Ubuntu machine from my windows machine using visual studio 2015 update 3

gregg-miskelly · 2016-08-23T16:08:46Z

@akku27 check out https://visualstudiogallery.msdn.microsoft.com/0f5b2caa-ea00-41c8-b8a2-058c7da0b3e4

schusovskoy · 2016-10-20T08:07:23Z

Hi, all
I have an issue with debugging app in Docker container. I've reviewed the code generated by yoman 'aspnet' and 'docker' generators, and did exactly the same. Debugging works fine for the situation, when docker is installed locally. But if I do it with docker located on remote server It falls. The steps I do:

Build container, and put app and clrdbg in it.
Set container entrypoint to 'sleep infinity'.
Change launch configuration to connect to server via ssh and then docker exec -i containerid /clrdbg/clrdbg --interpreter=mi
So debugger successfully connects to remote docker container executes web app and immediately stops.

gregg-miskelly · 2016-10-20T17:02:25Z

@schusovskoy that output looks like it is the target process which is immediately exiting.

Do you see a module load for your dll?
What are you setting as the startup program in launch.json?

schusovskoy · 2016-10-21T09:00:39Z

@gregg-miskelly thank you for reply. I think I've found the problem. I tried to run and debug bin/debug/netcoreapp1.0/test.dll and not the published version in bin/debug/netcoreapp1.0/publish/test.dll.
So I did it all from scratch and saw that debugging works fine.

(https://github.com/schusovskoy/apsnet_remote_debug) If someone will face the same problem, hear is the link to the working demo.
Note: Don't forget to add your ssh key in container.

joshgav · 2017-03-14T15:19:14Z

@schusovskoy thanks for the link and those scripts!

@gregg-miskelly I was hoping to do this in a simpler way. My launch.json invokes a script which when run directly from a terminal drops me into a shell in the target container 🎉. But when I invoke the debugger through VS Code I get the following message (line wraps added to protect the innocent). Feels like I'm close, any suggestions? Thanks!

Executing: "/Users/joshgav/node/demos/multi-container/scripts/csharp-debug.sh" \
"bash -c 'uname && if [ "$\(uname\)" == "Linux" ] ; then
  ps -axww -o pid=,comm=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa,args= ;
elif [ "$\(uname\)" == "Darwin" ] ; then
  ps -axww -o pid=,comm=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa,args= -c;
fi'"

gregg-miskelly · 2017-03-14T16:04:56Z

@schusovskoy you need to update your csharp-debug.sh script to expect that it will be passed an argument containing the quoted command to be run.

gregg-miskelly · 2017-03-14T16:05:55Z

Sorry, that should have been @joshgav.

styfle · 2017-03-23T20:25:43Z

With node.js, I can expose port 5858 and then VS Code can attach to that port.
What is the port for a .net core app and is there any documentation on remote debugging a docker container?

gregg-miskelly · 2017-03-23T21:52:00Z

@styfle .NET Core debugging doesn't work like that - what you want to do is:

Get vsdbg into your container by downloading it either as part of image building, or inside the container. See https://github.com/OmniSharp/omnisharp-vscode/wiki/Attaching-to-remote-processes
Setup a pipeTransport element in your launch.json which will do a docker exec of vsdbg.

There used to be a yo docker extension to make this nice and easy, but unfortunately that is now defunct. I am hoping someone fixes this up again soon. BTW: There is some useful info in #1318 that you may want to read. Note that the fix we made to make things easier hasn't been released yet.

saeedmsdi · 2017-04-14T21:31:00Z

@gregg-miskelly can you explain more about that 2 steps ?
Should I use this part of code on my docker file?
curl -sSL https://aka.ms/getvsdbgsh | bash /dev/stdin -v latest -l ~/vsdbg

Please tell how should be the pipeTransport, this is the yo docker defaults :

"pipeTransport": { "pipeProgram": "/bin/bash", "pipeCwd": "${workspaceRoot}", "pipeArgs": ["-c", "./dockerTask.sh startDebugging"] "windows": { "pipeProgram": "${env.windir}\\System32\\WindowsPowerShell\\v1.0\\powershell.exe", "pipeCwd": "${workspaceRoot}", "pipeArgs": [".\\dockerTask.ps1", "-StartDebugging"] } }

OS Version : macOS Sierra

gregg-miskelly · 2017-04-14T21:49:15Z

CC @glennc @Andrew-MSFT

I think I would probably recommend pulling vsdbg as some sort of occasional step instead of doing it every time you build your container. Ex: Maybe only do it if vsdbg isn't pulled down locally already, or, if you want to get fancy, only do it once a day or something like that.

The command you want to pull vsdbg is similar, but you need to also include -r debian.8-x64 [replace 'debian.8-x64' with whatever runtime id you are using for your container].

The dockerTask.sh that yo docker generates is broken in that it just assumed what command it should run, and that command is wrong. You could certainly try fixing that script if you want. The debugger will pass the debugger command to it as the last argument to the script.

Alternatively, another user reported success with:

pipeProgram = "bash",
pipeArgs = [ "-c", "docker exec -i remotedebug-1-mispn ${debuggerCommand}" ],

For the soon-to-be-released 1.9 version of the extension we added a new quoteArgs option under pipeTransport that can eliminate the need to use bash (or otherwise somehow un-quoting the debugger command).

greatkeke · 2017-05-17T10:49:26Z

I develop in mac os, but I had to debug via vs in Vmware because no way to debug in docker for mac. It's terrible for me to use .net core, finally I searched this issue.

I hope the easier way to resolve this issue.

Best wish:)

greatkeke · 2017-05-18T11:51:10Z

I found a solution. https://github.com/OmniSharp/omnisharp-vscode/wiki/Attaching-to-remote-processes

jchannon · 2017-06-01T08:51:28Z

I'm on OSX using VSCode and have followed the above link and installed vsdbg.

Below is my launch json. I get a remote process to attach to but then nothing. Breakpoints are greyed out and I see in the debug console every 2 secs or so Exception thrown: 'System.Net.Internals.SocketExceptionFactory.ExtendedSocketException' in System.Net.Sockets.dll

Can anyone suggest what I might be doing wrong? I feel I'm close to getting it to work

{
            "name": ".NET Core Remote Attach",
            "type": "coreclr",
            "request": "attach",
            "processId": "${command:pickRemoteProcess}",
            "pipeTransport": {
                "pipeProgram": "bash",
                "pipeArgs": [ "-c", "docker exec -i am2 ${debuggerCommand}" ],
                "debuggerPath": "/root/vsdbg/vsdbg",
                "pipeCwd": "${workspaceRoot}",
                "quoteArgs": true
            },
            "sourceFileMap": {
                "/Users/jonathan/Projects/vq/src/VQPortal.Hosting.Self": "${workspaceRoot}/src/VQPortal.Hosting.Self"
            },
            "justMyCode": false
        }

greatkeke · 2017-06-01T08:55:21Z

@jchannon Did your machine be authorized by the server?

jchannon · 2017-06-01T08:58:50Z

I'm not sure what that means 😄

greatkeke · 2017-06-01T09:01:49Z

You should publish your rsa_pub to the remote machine first. Otherwise, the remote machine will refuse to accept your request.

jchannon · 2017-06-01T09:02:04Z

I'm not on SSH, I'm on Docker

jchannon · 2017-06-01T09:13:08Z

The output I get suggests its kind of working in that it can see my app's PDBs but then seems to throw the socket exception for some reason and the breakpoints in vscode arent working:

Starting: "bash" -c "docker exec -i am2 /root/vsdbg/vsdbg --interpreter=vscode"
-------------------------------------------------------------------
You may only use the Microsoft .NET Core Debugger (vsdbg) with
Visual Studio Code, Visual Studio or Visual Studio for Mac software
to help you develop and test your applications.
-------------------------------------------------------------------
Loaded '/vq/portal/System.Private.CoreLib.ni.dll'. Cannot find or open the PDB file.
Loaded '/vq/portal/VQPortal.Hosting.Self.dll'. Symbols loaded.
Loaded '/vq/portal/System.Runtime.dll'. Cannot find or open the PDB file.
Loaded '/vq/portal/mscorlib.dll'. Module was built without symbols.
Loaded '/vq/portal/System.Threading.Tasks.dll'. Cannot find or open the PDB file.
Loaded '/vq/portal/Microsoft.Extensions.Configuration.dll'. Cannot find or open the PDB file.
Loaded '/vq/portal/Microsoft.Extensions.Configuration.Abstractions.dll'. Cannot find or open the PDB file.
Loaded '/vq/portal/System.Collections.dll'. Cannot find or open the PDB file.
Loaded '/vq/portal/Microsoft.Extensions.Configuration.Json.dll'. Cannot find or open the PDB file.
Loaded '/vq/portal/VQPortal.dll'. Symbols loaded.
Breakpoint error: The breakpoint failed to bind. - /Users/jonathan/Projects/vq/src/VQPortal/VQBootstrapper.cs:952
Loaded '/vq/portal/System.Reflection.dll'. Cannot find or open the PDB file.
Loaded '/vq/portal/System.ComponentModel.Primitives.dll'. Cannot find or open the PDB file.
Loaded '/vq/portal/System.Xml.XDocument.dll'. Cannot find or open the PDB file.
Loaded '/vq/portal/System.Xml.ReaderWriter.dll'. Cannot find or open the PDB file.
Loaded '/vq/portal/System.Text.RegularExpressions.dll'. Cannot find or open the PDB file.
Loaded '/vq/portal/System.Reflection.TypeExtensions.dll'. Cannot find or open the PDB file.
Loaded '/vq/portal/System.Reflection.Emit.ILGeneration.dll'. Cannot find or open the PDB file.
Loaded '/vq/portal/System.Reflection.Emit.Lightweight.dll'. Cannot find or open the PDB file.
Loaded 'Anonymously Hosted DynamicMethods Assembly'. 
Loaded '/vq/portal/System.Security.Cryptography.X509Certificates.dll'. Cannot find or open the PDB file.
Loaded '/vq/portal/System.Text.Encoding.dll'. Cannot find or open the PDB file.
Loaded '/vq/portal/System.Text.Encoding.Extensions.dll'. Cannot find or open the PDB file.
Loaded '/vq/portal/NLog.dll'. Cannot find or open the PDB file.
Loaded '/vq/portal/Polly.dll'. Cannot find or open the PDB file.
Loaded '/vq/portal/System.Data.Common.dll'. Cannot find or open the PDB file.
Loaded '/vq/portal/Dapper.dll'. Cannot find or open the PDB file.
Loaded '/vq/portal/Microsoft.CSharp.dll'. Cannot find or open the PDB file.
Loaded '/vq/portal/Microsoft.AspNetCore.Authentication.Cookies.dll'. Cannot find or open the PDB file.
Loaded '/vq/portal/PingMiddleware.dll'. Symbols loaded.
Loaded '/vq/portal/System.Diagnostics.TraceSource.dll'. Cannot find or open the PDB file.
Loaded '/vq/portal/WindowsAuthenticationMiddleware.dll'. Symbols loaded.
Loaded '/vq/portal/OwinUserMiddleware.dll'. Symbols loaded.
Loaded '/vq/portal/Microsoft.AspNetCore.Owin.dll'. Cannot find or open the PDB file.
Loaded '/vq/portal/System.Security.Claims.dll'. Cannot find or open the PDB file.
Loaded '/vq/portal/System.Security.Principal.dll'. Cannot find or open the PDB file.
Loaded '/vq/portal/Microsoft.AspNetCore.StaticFiles.dll'. Cannot find or open the PDB file.
Loaded '/vq/portal/Microsoft.Extensions.DependencyModel.dll'. Cannot find or open the PDB file.
Loaded '/vq/portal/Nancy.Validation.FluentValidation.dll'. Cannot find or open the PDB file.
Loaded '/vq/portal/FluentValidation.dll'. Cannot find or open the PDB file.
Loaded '/vq/portal/MediatR.dll'. Cannot find or open the PDB file.
Loaded '/vq/portal/System.ValueTuple.dll'. Cannot find or open the PDB file.
Loaded '/vq/portal/AutoMapper.dll'. Cannot find or open the PDB file.
Loaded '/vq/portal/System.Resources.ResourceManager.dll'. Cannot find or open the PDB file.
Loaded '/vq/portal/RawRabbit.vNext.dll'. Cannot find or open the PDB file.
Loaded '/vq/portal/System.Diagnostics.StackTrace.dll'. Cannot find or open the PDB file.
Loaded '/vq/portal/Microsoft.Win32.Registry.dll'. Cannot find or open the PDB file.
Loaded '/vq/portal/System.Numerics.Vectors.dll'. Cannot find or open the PDB file.
Loaded '/vq/portal/System.Threading.Tasks.Extensions.dll'. Cannot find or open the PDB file.
Loaded '/vq/portal/System.Buffers.dll'. Cannot find or open the PDB file.
Loaded '/vq/portal/Microsoft.Net.Http.Headers.dll'. Cannot find or open the PDB file.
Loaded '/vq/portal/System.Security.Principal.Windows.dll'. Cannot find or open the PDB file.
Loaded '/vq/portal/System.Net.WebSockets.dll'. Cannot find or open the PDB file.
Loaded '/vq/portal/System.Globalization.Extensions.dll'. Cannot find or open the PDB file.
Loaded '/vq/portal/ServiceStack.Text.dll'. Cannot find or open the PDB file.
Loaded '/vq/portal/System.Xml.XPath.dll'. Cannot find or open the PDB file.
Loaded '/vq/portal/System.Xml.XPath.XmlDocument.dll'. Cannot find or open the PDB file.
Loaded '/vq/portal/Microsoft.AspNetCore.WebUtilities.dll'. Cannot find or open the PDB file.
Loaded '/vq/portal/System.Runtime.CompilerServices.Unsafe.dll'. Module was built without symbols.
Loaded '/vq/portal/System.Xml.XmlSerializer.dll'. Cannot find or open the PDB file.
Loaded 'Microsoft.GeneratedCode'. 
Loaded '/vq/portal/System.IO.Compression.dll'. Cannot find or open the PDB file.
Loaded '/vq/portal/FubarCoder.RestSharp.Portable.Core.dll'. Cannot find or open the PDB file.
Loaded 'Microsoft.GeneratedCode'. 
Loaded '/vq/portal/System.Net.Http.dll'. Cannot find or open the PDB file.
Loaded 'Microsoft.GeneratedCode'. 
Loaded 'Microsoft.GeneratedCode'. 
Loaded 'Microsoft.GeneratedCode'. 
Loaded 'Microsoft.GeneratedCode'. 
Loaded 'Microsoft.GeneratedCode'. 
Loaded 'Microsoft.GeneratedCode'. 
Loaded 'Microsoft.GeneratedCode'. 
Loaded 'Microsoft.GeneratedCode'. 
Loaded '/vq/portal/Handlebars.dll'. Cannot find or open the PDB file.
Loaded '/vq/portal/Microsoft.AspNetCore.Http.Extensions.dll'. Cannot find or open the PDB file.
Loaded '/vq/portal/System.Reflection.Metadata.dll'. Cannot find or open the PDB file.
Loaded '/vq/portal/System.Collections.Immutable.dll'. Cannot find or open the PDB file.
Loaded '/vq/portal/System.IO.MemoryMappedFiles.dll'. Cannot find or open the PDB file.
Loaded '/vq/portal/System.IO.UnmanagedMemoryStream.dll'. Cannot find or open the PDB file.
Exception thrown: 'System.Net.Internals.SocketExceptionFactory.ExtendedSocketException' in System.Net.Sockets.dll
The thread 7069 has exited with code 0 (0x0).
Exception thrown: 'System.Net.Internals.SocketExceptionFactory.ExtendedSocketException' in System.Net.Sockets.dll
Exception thrown: 'System.Net.Internals.SocketExceptionFactory.ExtendedSocketException' in System.Net.Sockets.dll
Exception thrown: 'System.Net.Internals.SocketExceptionFactory.ExtendedSocketException' in System.Net.Sockets.dll
Exception thrown: 'System.Net.Internals.SocketExceptionFactory.ExtendedSocketException' in System.Net.Sockets.dll
Exception thrown: 'System.Net.Internals.SocketExceptionFactory.ExtendedSocketException' in System.Net.Sockets.dll

jchannon · 2017-06-01T09:20:44Z

One thing to consider is my app in the container is a self contained app

jchannon · 2017-06-01T17:38:22Z

One for @gregg-miskelly or @SteveLasker maybe?

SteveLasker · 2017-06-01T18:18:30Z

First, I apologize for the rapid changes that have been happening here. Docker scenarios are rapidly changing and we're working to stay ahead of the curve, which means we must change and prioritize.
While we started with yo docker and VS Code, we prioritized Visual Studio 2017 and have shipped what I'd hope would be considered a great container debugging experience.
We then shipped a preview of VS for Mac container debugging. This slipped in as a priority between VS for Windows and VS Code.
We are discussing when we can re-prioritize VS Code Container debugging to deliver the robust experiences we know developers want.
My suggestion would be to give the VS for Mac, Alpha Channel: https://developer.xamarin.com/recipes/cross-platform/ide/change_updates_channel/
Steve

jchannon · 2017-06-01T18:20:54Z

Will check it out but I feel it's really close. The dlls seemed loaded by vsdbg etc it's just VSCode that can't attach breakpoints and the socket exception or is that a massively naive thing to say? :)

…

On Thu, 1 Jun 2017 at 19:18, Steve Lasker ***@***.***> wrote: First, I apologize for the rapid changes that have been happening here. Docker scenarios are rapidly changing and we're working to stay ahead of the curve, which means we must change and prioritize. While we started with yo docker and VS Code, we prioritized Visual Studio 2017 and have shipped what I'd hope would be considered a great container debugging experience. We then shipped a preview of VS for Mac <https://www.visualstudio.com/vs/visual-studio-mac/> container debugging. This slipped in as a priority between VS for Windows and VS Code. We are discussing when we can re-prioritize VS Code Container debugging to deliver the robust experiences we know developers want. My suggestion would be to give the VS for Mac, Alpha Channel: https://developer.xamarin.com/recipes/cross-platform/ide/change_updates_channel/ Steve — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#220 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAGapmx2ZvKus5f6ELp0KL3RfZlXZKk3ks5r_wCAgaJpZM4IKeoA> .

gregg-miskelly · 2017-06-01T22:06:00Z

@jchannon I am assuming you are publishing a release (optimized) version of your app? Does the breakpoint hit if you publish debug instead? Release debugging is hard :)

The socket exception doesn't sound like a tooling issue.

jchannon · 2017-06-06T10:18:04Z

All works fine if in debug mode! 😄

greatkeke · 2017-06-06T10:19:45Z

@jchannon What did you do? Debug in docker container?

jchannon · 2017-06-07T16:01:05Z

http://blog.jonathanchannon.com/2017/06/07/debugging-netcore-docker/

tonysneed mentioned this issue Apr 19, 2016

Remote Debugging with Docker? dotnet/core#68

Closed

gregg-miskelly added Debugger Question labels Apr 19, 2016

gregg-miskelly closed this as completed Apr 19, 2016

snyk-bot mentioned this issue Jun 25, 2021

[Snyk] Upgrade semver from 5.6.0 to 5.7.1 madidiot2021/omnisharp-vscode#3

Open

Remote Debugging with Docker? #220

Remote Debugging with Docker? #220

Comments

tonysneed commented Apr 19, 2016

tonysneed commented Apr 19, 2016

gregg-miskelly commented Apr 19, 2016 • edited

tonysneed commented Apr 19, 2016

gregg-miskelly commented Apr 19, 2016

tonysneed commented Apr 20, 2016

gregg-miskelly commented Apr 20, 2016

janaka commented Jun 27, 2016 • edited

gregg-miskelly commented Jun 27, 2016

SteveLasker commented Jun 27, 2016 • edited by gregg-miskelly

SteveLasker commented Jun 27, 2016

janaka commented Jun 27, 2016

akku27 commented Aug 23, 2016

gregg-miskelly commented Aug 23, 2016

schusovskoy commented Oct 20, 2016

gregg-miskelly commented Oct 20, 2016

schusovskoy commented Oct 21, 2016

joshgav commented Mar 14, 2017

gregg-miskelly commented Mar 14, 2017

gregg-miskelly commented Mar 14, 2017

styfle commented Mar 23, 2017 • edited

gregg-miskelly commented Mar 23, 2017

saeedmsdi commented Apr 14, 2017

gregg-miskelly commented Apr 14, 2017

greatkeke commented May 17, 2017 • edited

greatkeke commented May 18, 2017

jchannon commented Jun 1, 2017

greatkeke commented Jun 1, 2017

jchannon commented Jun 1, 2017

greatkeke commented Jun 1, 2017

jchannon commented Jun 1, 2017

jchannon commented Jun 1, 2017

jchannon commented Jun 1, 2017

jchannon commented Jun 1, 2017

SteveLasker commented Jun 1, 2017

jchannon commented Jun 1, 2017 via email

gregg-miskelly commented Jun 1, 2017

jchannon commented Jun 6, 2017

greatkeke commented Jun 6, 2017

jchannon commented Jun 7, 2017

gregg-miskelly commented Apr 19, 2016 •

edited

janaka commented Jun 27, 2016 •

edited

SteveLasker commented Jun 27, 2016 •

edited by gregg-miskelly

styfle commented Mar 23, 2017 •

edited

greatkeke commented May 17, 2017 •

edited