NRE when starting debugging with pipeTransport

[galvesribeiro]

Environment data

dotnet --info output:

.NET Core SDK (reflecting any global.json):
 Version:   2.1.302
 Commit:    9048955601

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  10.13
 OS Platform: Darwin
 RID:         osx.10.13-x64
 Base Path:   /usr/local/share/dotnet/sdk/2.1.302/

Host (useful for support):
  Version: 2.1.2
  Commit:  811c3ce6c0

.NET Core SDKs installed:
  2.1.302 [/usr/local/share/dotnet/sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.1.2 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.2 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.1.2 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]

VS Code version: 1.26.1
C# Extension version: 1.15.2

Steps to reproduce

Open directory containing a .Net Core solution, hit F5.

Expected behavior

The application to run/debugger properly as usual.

Actual behaviour

NRE

I posted the issue on VSCode repo as it looks to me a VSCode problem as it started to happening after last update of it however, MSFT folks there are saying it is caused by the C# extension as you can see here microsoft/vscode#57808 (comment)

The codebase isn't changed in months so I doubt it is a code/config problem as it was working perfectly so far until I had VSCode updated.

No errors on Electron console:

And this is what happens when I start an app:

Here is the launch.json:

{
  "version": "0.2.0",
  "configurations": [
      {
          "name": "Kube Debugger",
          "type": "coreclr",
          "request": "launch",
          "program": "/app/EventStore.Kube.dll",
          "cwd": "/app",
          "sourceFileMap": {
              "/src": "${workspaceFolder}"
          },
          "pipeTransport": {
              "debuggerPath": "/root/vsdbg/vsdbg",
              "pipeCwd": "${workspaceFolder}",
              "windows": {
                  "pipeProgram": "kubectl",
                  "pipeArgs": [
                      "exec",
                      "-i",
                      "eventstore",
                      "--namespace",
                      "giro",
                      "--"
                  ],
                  "quoteArgs": false
              }
          }
      }
  ]
}

Any clues on how to workaround it is really appreciated as I'm totally blocked now.

[gregg-miskelly]

I am not sure what the source of that error message might be. If you enable logging do you get anything in the debug console that might be helpful?

[galvesribeiro]

@gregg-miskelly this is what I get:

<- (ERROR) {"request_seq":2,"success":false,"command":"launch","message":"Start debugging failed. Object reference not set to an instance of an object.","body":{"error":{"id":1099,"format":"Start debugging failed. Object reference not set to an instance of an object."}},"seq":1,"type":"response"}

[gregg-miskelly]

@galvesribeiro Do you see an event before that which has more information about the exception?

[galvesribeiro]

Nop. That is the only thing printed. I tried to enable the full logging with "args": [ "--engineLogging" ] but it doesn't write the file on OSX home directory after I restart VSCode...

[gregg-miskelly]

I don't have a mac at home to try this out, but here is I think your problem - you setup pipe transport with a bunch of commands. But by putting them under windows you are saying they are only used when you are on a Windows computer. Except that you aren't on Windows. If you just remove the windows element to indicate they are on all platforms, I think it will work.

[galvesribeiro]

Oh! Didn't saw that... It used to work on my old SurfaceBook2, that is why it is not working...

However, now I have this log with a different message:

Starting: "kubectl" exec -i eventstore --namespace giro -- /root/vsdbg/vsdbg --interpreter=vscode
-> (C) {"command":"initialize","arguments":{"clientID":"vscode","clientName":"Visual Studio Code","adapterID":"coreclr","pathFormat":"path","linesStartAt1":true,"columnsStartAt1":true,"supportsVariableType":true,"supportsVariablePaging":true,"supportsRunInTerminalRequest":true,"locale":"en-us"},"type":"request","seq":1}
-> (C) {"command":"launch","arguments":{"name":"Kube Debugger","type":"coreclr","request":"launch","logging":{"engineLogging":false},"program":"/app/EventStore.Kube.dll","cwd":"/app","sourceFileMap":{"/src":"/Users/guto/dev/repos/OctaGame/ES"},"pipeTransport":{"debuggerPath":"/root/vsdbg/vsdbg","pipeCwd":"/Users/guto/dev/repos/OctaGame/ES","pipeProgram":"kubectl","pipeArgs":["exec","-i","eventstore","--namespace","giro","--"],"quoteArgs":false},"__sessionId":"bea615b7-279e-4e3d-a945-926a3aa43051"},"type":"request","seq":2}
<- (E) {"seq":2,"type":"event","event":"output","body":{"category":"console","output":"-------------------------------------------------------------------\nYou may only use the Microsoft .NET Core Debugger (vsdbg) with\nVisual Studio Code, Visual Studio or Visual Studio for Mac software\nto help you develop and test your applications.\n-------------------------------------------------------------------\n"}}
-------------------------------------------------------------------
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.
-------------------------------------------------------------------
<- (E) {"seq":3,"type":"event","event":"output","body":{"category":"telemetry","output":"VS/Diagnostics/Debugger/vsdbg/LaunchFailed","data":{"VS.Diagnostics.Debugger.vsdbg.AdapterId":"coreclr","VS.Diagnostics.Debugger.vsdbg.ErrorCode":1002,"VS.Diagnostics.Debugger.vsdbg.Distribution.Name":"debian","VS.Diagnostics.Debugger.vsdbg.Distribution.Version":"9","VS.Diagnostics.Debugger.vsdbg.OSFamily":"Linux","VS.Diagnostics.Debugger.vsdbg.Version":"15.7.20426.1 commit:91b285752d1135b8cdcdb3d74b44ca9faee48809"}}}
<- (R) {"seq":4,"type":"response","request_seq":2,"success":false,"command":"launch","message":"launch: program '/app/EventStore.Kube.dll' does not exist."}
-> (C) {"command":"disconnect","arguments":{"restart":false},"type":"request","seq":4}
<- (E) {"seq":5,"type":"event","event":"output","body":{"category":"telemetry","output":"VS/Diagnostics/Debugger/vsdbg/DebugCompleted","data":{"VS.Diagnostics.Debugger.vsdbg.AdapterId":"coreclr","VS.Diagnostics.Debugger.vsdbg.DebugCompleted.BreakCounter":0,"VS.Diagnostics.Debugger.vsdbg.Distribution.Name":"debian","VS.Diagnostics.Debugger.vsdbg.Distribution.Version":"9","VS.Diagnostics.Debugger.vsdbg.OSFamily":"Linux","VS.Diagnostics.Debugger.vsdbg.Version":"15.7.20426.1 commit:91b285752d1135b8cdcdb3d74b44ca9faee48809"}}}
<- (R) {"seq":6,"type":"response","request_seq":4,"success":true,"command":"disconnect"}

It wasn't able to find the application code inside the container but that was a mistake on the kube configMap that was point to the wrong build output directory.

I still think that message could be more user-friendly in case no default nor OS-specific config were found on launch.json.

For now problem solved! Thanks @gregg-miskelly! Enjoy your holiday! :)

[gregg-miskelly]

Lets leave this open to track fixing the error handling here. But glad you solved the problem.