Option to run the .NET Core debugger under Rosetta 2 when using the Apple Silicon version of VSCode

[sschultze]

Issue Description

Steps to Reproduce

Use the current Apple Silicon (ARM) version of the Visual Studio Code Exploration build. Open a .NET 5 project and try to run the debugger.

Expected Behavior

The .NET Core debugger should run under Rosetta 2, just like it happens automatically when you run the "official" x64 version of Visual Studio Code under Rosetta 2.

Actual Behavior

A warning is displayed: "[WARNING]: Processor architecture 'arm64' is not currently supported by the .NET Core debugger. Debugging will not be available."

Logs

OmniSharp log

Post the output from Output-->OmniSharp log here

C# log

Post the output from Output-->C# here

Environment information

VSCode version: 1.53.0-exploration
C# Extension: 1.23.7

Mono Information

OmniSharp using built-in mono

Dotnet Information

.NET SDK (reflecting any global.json): Version: 5.0.100 Commit: 5044b93829

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

Host (useful for support):
Version: 5.0.0
Commit: cf258a14b7

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

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

To install additional .NET runtimes or SDKs:
https://aka.ms/dotnet-download

Visual Studio Code Extensions

Extension	Author	Version
csharp	ms-dotnettools	1.23.7
debugger-for-chrome	msjsdiag	4.12.11
EditorConfig	EditorConfig	0.16.4
hexeditor	ms-vscode	1.3.0
ilspy-vscode	icsharpcode	0.9.0
markdown-toc	AlanWalk	1.5.6
prettier-vscode	esbenp	5.8.0
remote-containers	ms-vscode-remote	0.154.0
remote-ssh	ms-vscode-remote	0.58.0
remote-ssh-edit	ms-vscode-remote	0.58.0
remote-wsl	ms-vscode-remote	0.52.0
rest-client	humao	0.24.4
snapshot-tools	asvetliakov	0.4.0
toggle	rebornix	0.0.1
vscode-docker	ms-azuretools	1.8.1
vscode-eslint	dbaeumer	2.1.13
vscode-remote-extensionpack	ms-vscode-remote	0.20.0
vscode-typescript-tslint-plugin	ms-vscode	1.2.3

[gregg-miskelly]

I am assuming a workaround here is to use the x64 version of VS Code?

[sschultze]

@gregg-miskelly Yes, the x64 version of VS Code runs fine under Rosetta 2.

But this workaround / VS Code x64 feels really slow on my MacBook Air M1.

In contrast, the VS Code Exploration Build (native ARM) is incredibly fast. It's a pleasure to work with, I was really surprised.

I assume that the .NET Core debugger runs in an external process anyway and does some inter-process communication with OmniSharp. Don't know where the warning is coming from, but I suspect that just letting the debugger run under Rosetta 2 (which happens automatically) would probably just work.

[gregg-miskelly]

@sschultze Thanks. Did you try debugging? My team doesn't have any M1 hardware yet to try. So it would be nice to confirm if it works.

Yes, I don't think it would be too hard to support this scenario until we have a native version of the .NET SDK and a native version of the debugger. I am not sure if we would continue the support after that. My team will probably not try to fix this until we have hardware, but if you are interested in doing the probably small amount of work, I can try to dig up what you would need to change.

[sschultze]

Thank you for your offer to help.

I was quite sure that I ran the debugger in VS Code x64 last midnight, but it seems that I had just launched the .NET process, without the debugger. When I tried to run the debugger in VS Code x64 now, I'm getting an exception (which seems to be well-known after some googling) - Stack overflow at HashHelpers.GetPrime(Int32).

So, for the moment, a fix in OmniSharp wouldn't help unfortunately.

But you probably like it to hear that C# code completion, navigation etc. works really fine from the ARM build of VS Code.

[gregg-miskelly]

Thanks! Looks like dotnet/runtime#44958 tracks the crash you ran into.

[arthurlockman]

I've been developing .NET 5 apps for the past 2 days using an M1 MacBook with native VSCode. The OmniSharp extension works perfectly well in the new M1 build of VSCode, actually!

I'm happy to help test once the debugger itself is fixed.

[sschultze]

The Stack overflow at HashHelpers.GetPrime(Int32) problem is also mentioned by @khalidabuhakmeh here:

dotnet/runtime#44897

Interestingly, Cameron Swarich @zwarich, the main developer of Rosetta 2 at Apple, is also commenting on this issue.

I am also happy to help once the debugger is fixed.

[arthurlockman]

I just put up a PR that I think will get this working once macOS 11.1 is released. Supposedly .NET 5 debugging works with the rosetta fixes in that release. I'm not brave enough to run the macOS beta to find out, but 11.1 is supposed to be released shortly.

[arthurlockman]

Wanted to leave an update here - on the latest beta of macOS Big Sur (11.2 beta 2) .NET 5 debugging works perfectly with VSCode and the omni sharp extension installed! I think this issue can be closed once 11.2 is released to the public.

[LukeStephen]

great to hear!!!

[MathiasSvDK]

Can't wait for this to be fixed so we can have Native VsCode for Blazor.

[gregg-miskelly]

@imflitch I believe this issue should actually be resolved already. You do need macOS 11.2.