When trying to debug a MVC Web project in VS 2017 Mac I get the error message: Unable to attach to CoreCLR.

dotnet

Microsoft .NET Core Shared Framework Host
Version : 1.1.0

dotnet --info

.NET Command Line Tools (1.0.1)

Product Information:
Version: 1.0.1
Commit SHA-1 hash: 005db40cd1

Runtime Environment:
OS Name: Mac OS X
OS Version: 10.12
OS Platform: Darwin
RID: osx.10.12-x64
Base Path: /opt/dotnet/sdk/1.0.1

Got the same issue (also on Sierrs 10.12.4 beta)

This will be fixed in the next 1.0 and 1.1 service releases and has been fixed in the master branch.

When will it be available ? Thanks

Sierra 10.12.4 is now being pushed as an update by Apple. I installed the update this morning and now I can no longer debug in VS Code ('Unable to attach to CoreCLR.'). I believe this is the same issue reported above. I installed the latest .NET Core SDK (dotnet --version now says 1.0.1). Is the fix available elsewhere, or any advice please?

Here is a work around that worked for Gregg Miskelly:

1. Download https://dotnet.myget.org/F/dotnet-core/api/v2/package/runtime.osx.10.10-x64.Microsoft.NETCore.Runtime.CoreCLR/1.1.2-servicing-25123-01
2. Open the resulting file as a zip, and copy out runtimes/osx.10.10-x64/native/libdbgshim.dylib
3. Open a terminal
4. cd ~/.vscode/extensions/ms-vscode.csharp-1.8.0/.debugger
5. cp .
   As I said above, but just to repeat here, I expect to have a real fix out soon. But hopefully this will unblock folks in the mean time.

Confirmed workaround works. Thanks for the info. When the real fix is released, will I need to 'reverse' the workaround, or will installing the new software get me back to consistency?

Is there a workaround for Visual Studio Mac ?

@gregg-miskelly Is there a workaround for VS for Mac?

I don't have precise steps, but you can work around this by downloading https://vsdebugger.azureedge.net/coreclr-debug-1-9-0/coreclr-debug-osx.10.11-x64.zip, and replacing the version of vsdbg that VS for Mac is using with that version.

@DavidKarlas do you have better instructions?

This fixed it for me, in Visual Studio for Mac:

1. Download https://dotnet.myget.org/F/dotnet-core/api/v2/package/runtime.osx.10.10-x64.Microsoft.NETCore.Runtime.CoreCLR/1.1.2-servicing-25123-01
2. Open the resulting file as a zip, and copy out runtimes/osx.10.10-x64/native/libdbgshim.dylib
3. Navigate to /Applications/Visual Studio.app/Contents/Resources/lib/monodevelop/AddIns/DotNetCore.Debugger/Adapter/ in Finder or Terminal
4. Rename libdbgshim.dylib to libdbgshim.dylib.old
5. Paste in the new libdbgshim.dylib

@suqram You just saved my day and night! Thx.

@suqram it worked well!

Thanks

fix it for me!

@suqram Excellent!
Work for me!
Thanks

Excellent, copying the libdbgshim file as instructed by @suqram did the trick.

@suqram Excellent!
Work for me!
Thanks

Works for me too!

thanks!

Open the resulting file as a zip, and copy out runtimes/osx.10.10-x64/native/libdbgshim.dylib

@mikem8361 what does this mean?

A nuget file is a zip file. Rename to .zip and run unzip on it.

@suqram Work for me as well - thank you.

@suqram Thanks so much! It works!

Is this issue fixed in production now, or is it still in workaround? I noticed a new C# Extension and installed it yesterday. Does that contain the fix?

@robbpriestley Sure seems like it. This is in the changelog for the extension in vs code:
What's New in 1.8.1
Fixes debugging on macOS Sierra 10.12.4.

(and it's working)
Brilliant!

I did precisely what @suqram suggested, but now I get a popup when I try to run my application:

Debugger operation failed
Unknown Error: 0x92330062

I don't get the 'Unable to attach to CoreCLR' message in my Application Output window anymore, so that's fixed. (and to clarify: when I run 'dotnet' or 'dotnet --info' , my results are identical to those from @AAimson)

@joristt if you have the 1.8.1 extension installed and you are still running into an issue, your issue isn't related to this issue. Please open a new issue, this issue is long enough :).

I was working on aspnet core when this issue started, and with VS preview it used to start a new Browser with a new debug session. Am i looking for the wrong setting now?

@gregg-miskelly Yeah you're right, sorry :). You said

replace the version of vsdbg that VS for Mac is using

and I interpreted that as: replace only the vsdbg Unix executable. Tried copying everything from that zip to the VS Adapter directory 1 minute after commenting here and that fixed the problem.

@robvdveer by 'VS Preview' you mean 'VS For Mac Preview' correct? If so - VS For Mac hasn't shipped an update vsdbg package containing the fix yet (at least to my knowledge), so you are very likely at the right place. There are two work arounds posted above, but I will give you the latest version of it --

• Download https://vsdebugger.azureedge.net/coreclr-debug-1-9-1/coreclr-debug-osx.10.11-x64.zip
• Navigate to /Applications/Visual Studio.app/Contents/Resources/lib/monodevelop/AddIns/DotNetCore.Debugger/Adapter/ in Finder or Terminal
• Extract the zip to this folder

Thanks @gregg-miskelly for such a quick response!

@gregg-miskelly well played. Thanks

@gregg-miskelly saved the day!!!!

@gregg-miskelly this will work on the visual studio preview the debug gives an execution error

visual studio code using golang debugger does not match the gopath path code ?

I construct up golang environment using visual studio code IDE MAC OS, then install the necessary tools:

I ever set my go path /Users/friends/gopath , before long I changed my gopath /Users/friends/Document/share/gopath. I changed the gopath ~/.bash_profile ,visual studio code setting about

go.gopath': '/Users/friends/Documents/VirtualMachine/share/gopath

when I debug my code, it tips that can't find the file in/Users/friends/gopath/src/...../apiSGetChainsIds.go , actually the file exist in /Users/friends/Documents/VirtualMachine/share/gopath/src/..../apiSGetChainsIds.go .It is obvious that the debugger find the previous gopath ,is it the golang tools bug? or something I wrong?

my usersetting is

• In the VS Code terminal, run echo $GOPATH. Is the output the same as your expected GOPATH?
• The debugger cannot read VS Code settings. So you need to set the right GOPATH as an environment variable outside VS Code or you can pass the same in the debug configuration in the launch.json file
• If you are using the latest version of the Go extension (0.6.65), then you don't have to pass the GOPATH via the launch.json either.

See Debugging-Go-code-using-VS-Code as well

This is happening to me as well -- I'm using Linux, so the bug has affected both MAC OS and Linux.

• I'm using the latest version of the Go extension (0.6.66), and my VS Code is downloaded and installed just today.
• My go version is go1.9.1 linux/amd64, and
• My OS is

• In the VS Code terminal, run echo $GOPATH, the output is the same as my expected GOPATH.

Only after adding the GOPATH as an env var in the env property in the launch.json file solved the problem.

@suntong The debugger should have figured out the right GOPATH based on the package being debugged. Can you try the below?

• Does the value in the program property in the launch.json file fall under your expected GOPATH?
• Remove the GOPATH from the env property in the debug config in the launch.json file
• Add 'trace': 'verbose' to your debug config in the launch.json file
• Start debugging
• You will see verbose logging in the debug console. You should see a line 'Using GOPATH:' Does this GOPATH match what you expect?

Thanks for the reply, @ramya-rao-a,

The value in the program property in my launch.json file is:

I don't know how to check it, but all my own code are not under GOPATH, as I want to distinct my own code from those I get from go get.

Maybe that's the reason vscode-go is confused?

Hmmm..., actually, I thought about that, and has tried to move my code under GOPATH, but that won't work either. Maybe I only did a symlink, and that won't work.

Will try the trace: verbose next and post back...

UPDATE,

After I added trace: verbose, and restarted debugging, I saw logging in the debug console

Which is where my own code actually is, not where I started VS Code (i.e., under GOPATH via symlink). And that is different than the GOPATH I set in the environment -- /path/to/repo/go-arch

I think vscode-go should honor the GOPATH set in the environment, instead of figuring it out on its own and overwrite the environment setting.

To summarize:

• The debugger is using the GOPATH /path/to/repo/gitwork which is where your code really is
• But you have opened VS Code for a folder under /path/to/repo/go-arch which you have sym linked to /path/to/repo/gitwork
• If you set GOPATH in the env in launch.json to /path/to/repo/go-arch, then everything is fine
• You have set GOPATH as a env variable (outside of VS Code) to /path/to/repo/go-arch

Is that right?

Yep, precisely!

Few more things...

• What do you see when you run the command Go: Current Gopath?
• Have you by any chance modified the settings go.gopath or go.inferGopath ?

'What do you see when you run the command Go: Current Gopath?'

Not sure I understand what you mean.

But I didn't touch go.gopath or go.inferGopath, just accepting what was pre-filled launch.json setting for me.

Press Ctrl+Shift+P, the command pallet will open. If on Mac then use Cmd+Shift+P
Type Go: Current Gopath, select it from the options

That output is correct,

Current GOPATH: /path/to/repo/go-arch

@suntong
ok, https://github.com/Microsoft/vscode-go/blob/0.6.66/src/debugAdapter/goDebug.ts#L235 is the reason for the debugger trying to infer the GOPATH.

I'll look at the history and try to recall why I do that even when GOPATH is set in the env.

@friends110110 Can you tell us if you use symlinks as well?

Just to make it clear that it fails regardless of the symlinks. I.e., whether I started VS Code from under
/path/to/repo/gitwork or /path/to/repo/go-arch, both cases failed.

When you start VS Code from under /path/to/repo/gitwork what does the Using GOPATH log show?

Same,

Current GOPATH: /path/to/repo/go-arch

Or, sorry, Using GOPATH log showed the same as before as well.

Using GOPATH: /path/to/repo/gitwork

No I meant the logs from the verbose logging when debugging

@suntong I have pushed in a fix which should help your case, can you give it a try?

You will have to

• Download https://github.com/Microsoft/vscode-go/blob/master/Go-latest.vsix
• Run code --install-extension Go-latest.vsix
• Reload VS Code

OK, I'll try it out this weekend.

Sorry to response late, but my debugging is not working any more. I'll open another issue instead.

But adding 'trace': 'verbose' to my debug config in the launch.json file, and judging the output of Using GOPATH, it is using the correct path now. However the same fix has caused my debugging not working any more...

What's up about this? The tools are installed in /home/myself/go but I set my GOPATH to /home/myself/.go:

In vsc terminal:

But with the command:

This is a bug, because the documentation says:

Out of the box, the extension uses the value of the environment variable GOPATH.

I am running Debian testing.

@Boiethios give this a try,
#1307 (comment)
at least it solves the GOPATH problem.

And Ramya is waiting for more testers too. She's been very helpful. Let us know your outcome. please post to #1307 (comment) if you try.

Thx

@ramya-rao-a I agree that this issue should not be considered as 'closed'.

@Boiethios Can you share your settings? Have you set any of go.gopath, go.inferGopath, go.toolsGopath ? Please check both your user and workspace settings