Omnisharp-vscode: Support Windows ARM64

[richlander]

Environment data

Windows ARM64
Install Windows ARM64 .NET Core SDK (NOT x86)

Steps to reproduce

• Create console app
• Insert a ReadLine in it, to hault execution so we can wait on the debugger being attached
• Build console app at CLI
• Launch app, and make sure it is waiting at the ReadLine
• Attach to the right PID

Expected behavior

• Debugger shows threads and any other appropriate data
• breaks at breakpoint after the ReadLine once I hit enter

Actual behavior

• Debugger doesn't appear to do anything

Tried same steps launching the app with both .NET Core 3.0 x86 runtime and .NET Core 3.0 ARM64 runtime. Same experience.

My App

    class Program
    {
        static void Main(string[] args)
        {
            var pid = System.Diagnostics.Process.GetCurrentProcess().Id;
            Console.WriteLine("Hello World!");
            Console.WriteLine($"Process: {pid}");
            Console.WriteLine("Press enter to exit.");
            Console.ReadLine();
            Console.WriteLine(System.Runtime.InteropServices.RuntimeInformation.FrameworkDescription);
        }
    }

[gregg-miskelly]

It is probably a VS Code bug that it doesn't show you an error - the C# extension only ships the x64 version of the debugger, which will not run on a Windows ARM64 machine.

As we discussed a while back - we aren't planning to support x86 in the VS Code debugger. I can leave this active if you want to eventually support ARM64 target processes.

[richlander]

Thanks for the info. Yes, my goal is ARM64 not x86. I tried both to see if there was any difference.

Can we make this issue the request for an ARM64 debugger, and not by design as a result?

[richlander]

One small nit ... The ARM64 SDK isn't currently yet available, just the Runtime. So everything is correct above, but to go through the flow today, you need the x86 SDK to build the product. In future, we'll have an ARM64 SDK.

[MikeyMCZ]

Hello. It seems that we might get build of Visual Studio Code for Windows ARM in "near future" - Iteration Plan for April 2020 and we are getting Windows ARM64 builds of .NET 5.0 SDK - Nightly SDK builds.
Any plans to support .NET debugging on Windows ARM devices?

[gregg-miskelly]

Supporting .NET debugging on Windows ARM64 is definitely something on our radar. But we haven't yet decided for sure what form that will take or when it will be released.

[turowicz]

I need it so bad. Any rough estimates or alternatives?

[gregg-miskelly]

@turowicz can you talk more about what your scenario is? Examples: You are developing an arm64-only app, you are developing on a ARM device, etc.

[turowicz]

I am porting my dotnet core 3.1 AI system (surveily.com) to run on Nvidia Jetson. There are many problems with libraries that I use (nuget and cpp) that need debugging so I must resort to Console.Writeline right now... Also cannot debug failing unit tests.

[gregg-miskelly]

@turowicz to make sure I understand - you are running Windows on this Nvidia Jetson board?

[turowicz]

@gregg-miskelly Jetson only supports Jetpack OS, which is a Ubuntu image made by Nvidia.

[gregg-miskelly]

@turowicz Than this issue has nothing to do with your scenario. ARM64 remote Linux debugging has been supported for quite some time. See the Wiki for instructions.

[turowicz]

Is it possible to remote debug a docker container? I don't see that kind of hybrid in the documentation.

[turowicz]

ie. a docker container running on the remote ARM machine

[gregg-miskelly]

Yes. There is a docker example here. Since your container is remote, yours is a bit different from the example. But you could -

1. Use local the docker executable to run commands on a remote host
   -or-
2. SSH into the target host and run docker commands there.
   -or-
3. Run an SSH server inside your container

For attach, full Visual Studio (NOT Code) has support for attach in all these cases through the Attach To Process dialog, though no support for launch. Visual Studio Code can stitch anything together that you have the patience to do, but you will need to manually configure everything....

[turowicz]

This is what I meant, there isn't an "official" way to do it in Code (ssh through to docker).

[gregg-miskelly]

I wouldn't really say that - the nice thing about remote debugging in VS Code is that everything is supported, and you can make everything work. The downside of remote debugging in VS Code is that nothing is trivial. SSH + Docker is a bit tricker maybe since we don't have an example, but I am happy to add an example if you have a launch.json block to share.

[turowicz]

I wouldn't really say that

If you can point me to a documentation explaining how it's done then I will definitely agree with you.

[gregg-miskelly]

@turowicz the documentation for pipeTransport is here and in the IntelliSense provided in VS Code (which you can read here if you prefer). If you have any questions, or find any bugs feel free to open a new issue.

[BigBandit]

Hello, just wanted to bump this, was wondering if this would be coming anytime in the near future. I use a Surface Pro X for developing.

[Alovchin91]

Hi @gregg-miskelly, what's the status of this? Now that stable Visual Studio Code is officially supported on Windows on Arm and .NET 5 supports Arm64 and is approaching the release, it would be nice to get some kind of a timeline for C# extension's Windows on Arm support. Thanks!

[gregg-miskelly]

It is something fairly high on our priority list, but we don't have a committed release yet.

[b2af]

I am extremely interested in debugger support for Windows 10 ARM 64.

I am looking forward to the release of this feature in the C# extension!

[visschersm]

I currently use the dotnet CLI on my surface pro x to develop some net5.
Though I'm very much looking forward to full support for the arm64 processors.

[jamesthurley]

Another vote for the scenario of doing .NET Core development using a Surface Pro X with VSCode.

[tbonham]

Another vote for this. I'm waiting to get a surface pro x for this to work.

[Alovchin91]

@gregg-miskelly Hi, do you have any updates on this? Maybe there is something we could help with?

[turowicz]

.NET 5.0 runs pretty smooth on ARM64

[gregg-miskelly]

@gregg-miskelly Hi, do you have any updates on this? Maybe there is something we could help with?

The debugger part of the extension is what I work on. Most of the debugger is closed source, so this needs to be done by my team.

The rest of the extension (C# language service and Razor language service) is open source, so there may be opportunities for community help.

For the C# language service -- that currently runs on Desktop CLR, so in theory it _should_ work on Windows ARM64, but it would be x86 emulated, I am not sure if the language team has a good read on how well that works (example: how does it work with a native SDK). The language service team might appreciate feedback. @cartermp might be able to better comment. In the long term there is a desire to run on .NET Core, but I don't know if that needs to happen for this work item to really be done.

[Alovchin91]

Hi, any updates on this? .NET 5.0 RC 2 landed today, with an official SDK installer for Windows on Arm64 and a go-live license. Meaning only this issue prevents from developing on Surface Pro X 😉

[aidapsibr]

Now that mono is under the NET5 umbrella, how much work is left here?

[tbonham]

Hello,

Is there any update on this? With dotnet 5 having the official installer this plugin is the only thing keeping me from getting a surface x pro.

[LinuxDoku]

FYI, since omnisharp 1.37.1 they publish native windows arm64 assemblies (https://github.com/OmniSharp/omnisharp-roslyn/releases).

You can download them and point the omnisharp path in your visual studio code settings to the OmniSharp executable.

"omnisharp.path": "C:\\Temp\\omnisharp-win-arm64\\OmniSharp.exe",

With this you get intellisense, file error checking, etc. Only the debugger is still incompatible. To debug your code, you have to open the x86 emulated visual studio 2019.

[kotha16]

When is the official support for Windows 10 ARM64 coming.....Why is this taking so long......Not having an ARM64 is really sad especially people buying surface pro x.....Am not sure why msft is not looking into this

[ap3rus]

As a (kind of) workaround, arm64 build of windbg from Windows SDK supports .NET5's sos.dll, makes it a viable (although a bit complicated) option for debugging.