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, 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.

[laultman]

We need this too, using Windows Surface Pro X as a dev tool for our HoloLens2 development. Unity is no fun either. Getting all the stuff to work feels like 1984.

[Alovchin91]

Hi, can somebody please provide us with an update on this issue? Thanks!

[ap3rus]

It looks like macOS is getting prioritized over Windows #4390, is it that hard to implement this on Windows or it's just a question of market share and priorities?

[Alovchin91]

Do we have any chance to see some roadmap? At least a very, very high level one?

[Alovchin91]

Would ARM64EC make it simpler? @gregg-miskelly Could you please provide any bit of info on this?

[gregg-miskelly]

The debugger side of this work is currently in progress.

ARM64EC isn't an option for the debugger, it also wouldn't make it simpler.

[Alovchin91]

@gregg-miskelly Thanks a lot for the update! 😊

Would it be possible to have IntelliSense support in the meantime? Just like what C++ Extension did:
https://devblogs.microsoft.com/cppblog/visual-studio-code-c-extension-arm-and-arm64-support/

[Alovchin91]

@gregg-miskelly @JoeRobich Hi, I've noticed that OmniSharp is being built for Windows arm64 since v1.37.1: https://github.com/OmniSharp/omnisharp-roslyn/releases/tag/v1.37.11

I also see that the extension is not being blocked from installing on Windows arm64: https://github.com/OmniSharp/omnisharp-vscode/blob/69711c277fe3b79a6b73bf8420390238f0eff4dd/src/main.ts#L217

Unfortunately, it doesn't seem to install the OmniSharp package on Windows arm64 as I'm seeing a "File not found" error:

Starting OmniSharp server at 04/07/2021, 09:42:43
    Target: c:\Projects\dotnet_app

OmniSharp server started.
    Path: c:\Users\alovchin\.vscode\extensions\ms-dotnettools.csharp-1.23.12\.omnisharp\1.37.10\OmniSharp.exe
    PID: 4088

The system cannot find the path specified.

Would it be possible to enable OmniSharp download for Windows arm64, please? 🙂

[Alovchin91]

Hi @gregg-miskelly It turns out vsdbg.exe now supports Windows arm64! 🥳

microsoft/vscode-cpptools#6392 (comment)

microsoft/vscode-cpptools#7798

Is this something that unblocks C# Extension for arm64? 😊

[gregg-miskelly]

@Alovchin91 Yes, as I said, we are actively working on this. I would expect a PR to enable this sometime fairly soon.

[Alovchin91]

Thanks a lot for the update, that's fantastic news! 😊 Do you have a roadmap in which version you expect it to be available (like in the linked C++ extension issue)? 🙂

[gregg-miskelly]

The language service team has been trying to address a blocking bug for the 1.23.13 for a little while now, so I am not sure. Depending on how fast that issue is resolved, and if we find issues when inserting the new debugger it will either be in 1.23.13 or the release after that (1.23.14 I assume?).

[Alovchin91]

Wow, that's super great to hear! 🚀 Thanks again for the update!

[gboder]

👍🏻👍🏻👍🏻 So great ! I’m looking forward for this update.

[Alovchin91]

So great to see this merged! 🎉

@gregg-miskelly There seems to be a small typo in package.json, could you please have a look? #4675

[BigBandit]

To those that have a SPX specifically, Microsoft has released an x64 emulator that bypasses all of this: https://blogs.windows.com/windows-insider/2020/12/10/introducing-x64-emulation-in-preview-for-windows-10-on-arm-pcs-to-the-windows-insider-program/

…

On Wed, Jul 21, 2021, 4:15 AM Alexander Ovchinnikov < ***@***.***> wrote: So great to see this merged! 🎉 @gregg-miskelly <https://github.com/gregg-miskelly> There seems to be a small typo in package.json, could you please have a look? #4675 <#4675> — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#3006 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AO5OALTY5LT3AJEJSLU2O2LTYZ6ZZANCNFSM4HGXSRDQ> .

[gregg-miskelly]

To be clear: x64 emulation is only useful for this feature if you want to install x64 versions of BOTH the .NET Core SDK and VS Code. I would NOT recommend this approach unless you for some reason need to run in an x64 process.

Instead, if you want this feature now you should install arm64 versions of the .NET Core SDK (See installer link here), VS Code, and install the C# extension 1.23.14 beta release (instructions). If you are reading this after 1.23.14 has been released to the marketplace you can ignore the last part.