Feature request: support Linux ARM / ARM64 #2771
Comments
|
@m-brooks my understanding is that VS Code doesn't have an official version for Linux ARM. Is that correct? |
|
Hi Gregg. I believe so, although it also appears that Microsoft have provided an ARM flavour of the C# extension for VS Code, because I installed the MS C# extension and it's working. This does therefore leave some question over their intended direction, which I suppose is the hidden question inferred by my issue above. Having gone through all the hoops that I needed to in order to get VS Code running on a Raspberry Pi I was genuinely surprised when I hit F5 and got the above message. It would be so cool if someone in Microsoft were to port the debugger to ARM as that would complete the jigsaw and we would have the ideal low cost teaching platform. Without a working debugger it's fairly useless - a case of so near but yet so far. Regards, |
|
Short answer: This isn't something we can currently help with. The debugger is only licensed to run in official version of VS Code. So even if you had a version for ARM, it still wouldn't run because the license checks would fail. So microsoft/vscode#6442 needs to be addressed before this can be implemented. I will leave this open in case the VS Code team decides to more officially support Linux ARM. More details in case you are curious: The C# extension has 4 parts to it --
|
|
Gregg, many thanks for the response and the details re the extension. In case it's of interest, rather than installing Mono I installed the official Microsoft ARM build of .Net Core 2.2 (my understanding is that this is a completely separate code stream from Mono, but I realise I could have picked this up wrongly). My VS Code is Jay Rodgers's build (headmelted.com). Fingers crossed that the VS Code team have both the desire and bandwidth to tackle a Linux ARM version - to my mind it's just the perfect complement to the Raspberry Pi. Best regards, |
|
@gregg-miskelly Great news, the first bullet point has been addressed, since the latest Insiders already supports ARM as a remote SSH target: https://twitter.com/joaomoreno/status/1138379435839754240 Now all we need are the following 3 bullet points... 💪 |
|
@joaomoreno very cool! But to be clear, I am not sure this changes things too much --
|
|
@gregg-miskelly My use case is using a Pi as a base to connect to from other devices through the Remote feature, but even though vsdbg runs on the Pi, the extension doesn't seem to work (complains about architecture). I was able to get Omnisharp running without too much trouble. Did not try Razor as I was trying to run a console app. Given that a remote instance of Visual Studio Code would end up running the debugger, it would now be permitted under the license? |
|
@thesamesam there is no licensing reason why that scenario can't work, but I think you would be better off using remote debugging instead. Firstly, because it works today, so right now, it is the only option. But also because, at least if you have a reasonably sized project, the language service (Omnisharp) can be compute-hungry. So you probably would rather use your local processor, than run it on the comparatively under-powered CPU on the Pi. |
|
@gregg-miskelly Oh, I misunderstood then. I can see why the processor might be a problem. The main reason I'm keen on it is having the filesystem constant when I'm changing machines. At the moment, when I tried Remote (Insiders; Nightly SSH) + Pi + C# extension, I had the armv7 error for debugging and it didn't seem to download or fire up OmniSharp either (so nothing happened, bar the error). I'm not sure if I need to report this somewhere else though? |
|
If we fixed this issue, the remote scenario would also be addressed, so no need to open a separate issue. |
|
Big bummer this isn't working inside Raspbian. Cross-platform is still far from being real in 2019. |
|
By following Remote Development using SSH https://code.visualstudio.com/docs/remote/ssh Python could be run and debugged without problem, [ERROR] Error: spawn /home/pi/.vscode-server-insiders/extensions/ms-vscode.csharp-1.21.0/.omnisharp/1.34.0/run ENOENT [Window Title] [Content] [Open launch.json] [Cancel] |
|
@NetGH Correct. If you are trying to do remote ARM development, you want to use remote debugging instead. It would be better anyway... |
|
@gregg-miskelly I don't agree that "It would be better anyway". I would like to be able to build and test C# programs using System.Device.Gpio on a Raspberry Pi using VS Code and Remote-SSH. It is especially onerous when I have to first create the projects on my Windows PC (in order to get language/IntelliSense support), then, at some point, copy my project to the rpi in order to test/debug (due to the lack of actual GPIO hardware on my Windows PC). Every time I need to make substantial edits, it's back to my Windows PC in order to leverage IntelliSense, then back over to rpi to test/debug; a dreadful cycle. I am not concerned about taxing the rpi system resources a) because my performance requirements are not substantial, b) because I understand and can manage the tradeoffs, and c) because, frankly, newer rpi devices are relatively powerful. I see there is a "blocked on vs code" tag on this issue - is that still the case? I've read over this thread a few times and, from what I can see, there don't appear to be any show-stoppers; would this be difficult to enable? This seems like a slam-dunk feature request to me. |
|
@gregg-miskelly I think there might be a use case now that supports enabling this. I have a Surface Pro X and want to use x86 code as a frontend into WSL (using the WSL extension). WSL is running native ARM64 so in theory running most of my development load there should be more efficient. Are there still blockers to doing this given that omnisharp runs on mono and there exists an arm64 debugger now? I'm open to contributing here if you think this is a valid scenario. |
|
@nathansoz interesting. So you are trying this now and WSL is supported on Surface Pro X? I would agree that this sounds like an interesting scenario. Unfortunately, I don't think you will be able to currently get it to work through the remote extension support - the remote debugger (which does support Linux arm64) is slightly smaller than what we use with VS Code. You can still do this via remote debugging if you like: https://github.com/OmniSharp/omnisharp-vscode/wiki/Windows-Subsystem-for-Linux |
|
@gregg-miskelly Yeah, WSL v1 and v2 are both supported and work exactly as you would expect. Here's the output showing that it is running native ARM:
|
|
I'm using a Chromebook with crostini and on my aarch64 linux I can use the latest dotnet core that has arm64 support. Using f# and vscode is possible with the f# language server but it's sad to see that there is no good option for c#. I just need a decent intellisense and I can live without debugging, but I'm not sure what is missing and what can we do about it. i have the same error: |
|
This seems trivial to achieve: https://gist.github.com/kangaroo/883b9a6e26c1c76780fccf41f23a629e I just can't seem to figure out the canonical url, only the fallbackUrl. That said, this change lets me debug C# projects on my rpi4 with the Remote SSH target without issue. |
Any help? I tried in armv7l 32 bit |
|
I can't believe this is still not there. |
|
This is a feature I would also like to see. I was disappointed to find that omnisharp is not available on raspberry pi. Ionide adds a lot of value to VSCode for F#. |
|
Hi @Cyber1000, @baumhoto Really appreciate your efforts on this! I've followed both of your instructions to the letter on a fresh Rasbian 10 build, but when I try to debug a simple console app I have the following message: "The C# extension for Visual Studio Code (powered by Omnisharp) is incompatible on Linux aarch64 Source: C# (Extension)" Any ideas? Is there a working build of the VSIX file I could download and try please, in case something went wrong while I was packaging it up? Any help greatly appreciated! EDIT: Scratch that, VSCode had updated the extension to the live version; I had to increment the version number of this extension past the live version prior to packaging to ensure it wasn't replaced. It's working beautifully! |
|
In an VSCode event on "microsoft tv" recently they said arm64 on linux should be supported by the release of .net 6. Can anyone confirm? |
|
@Dean2678 Glad you found a solution, sorry didn't read your comment in time. @sandrokl I've only heard this https://www.infoworld.com/article/3608611/whats-new-in-microsoft-net-6.html
But there are hopefully others who know more ... For everyone who wants to test, i've updated my fork and with an github-action (which is also used here) I built a new vsix: https://github.com/Cyber1000/omnisharp-vscode/releases/tag/v1.23.17-beta1.arm64%2B001 For now I have one positive reply (from myself) and one negative (see in PR #4515), would be interested if it works (or doesn't work) for others. |
|
A prerelease build of the C# extension with experimental language server support for Linux Arm64 is available at https://github.com/OmniSharp/omnisharp-vscode/releases/tag/v1.23.18-beta1. You will need to set your "omnisharp.path" to "latest" as there is not a published release of O# for this platform. There is also no Razor language support in this build. |
|
I've been away from the thread for a while, but I certainly appreciate the effort to getting this new support into the project. I look forward to testing it in the new year when I can get back to the project that got me into this thread. |
|
What about armv7l and raspberry pi 4? Is there plan to update plugin? |
|
I struggling to figure out what raspi omnisharp works on. I have a Raspi 4 and but also and so omnisharp doesn't work. According to online sources, Raspi 4s should have ARMv8. What raspi can I use? |
|
@jtheisen I believe the default Raspian distro is a 32-bit OS. You could install a 64-bit Debian distro instead. |
|
@jtheisen, what JoeRobich said is correct, default Raspian is 32-bit OS. You can't get the image from Raspberry Pi Imager directly because it is still in beta > https://forums.raspberrypi.com/viewtopic.php?t=275370 |
|
You can get the latest 64 bit Raspbian build from here: https://downloads.raspberrypi.org/raspios_arm64/images/ |
Was hoping this woud work for my Chromebook (aarch64) Below is what I'm greeted with in the output window. Tried a number of solutions on the internet to rectify this GLIBC not found issue but no dice. I'm guessing this was made with Raspberry Pi in mind `Starting OmniSharp server at 12/14/2021, 6:20:39 PM OmniSharp server started. /home/abenson/.vscode/extensions/ms-dotnettools.csharp-1.23.18/.omnisharp/1.37.18-beta.115/bin/mono: /lib/aarch64-linux-gnu/libm.so.6: version |
Okay so to answer my own problem (and for anyone out there with a chromebook) I did some research and it appears it's because the libc/glibc version on my chromebook is below 2.29. I used Edit: It's no longer an issue for me with my Crostini Linux, Chrome OS updated and then I reinstalled Crostini and it downloaded the latest environment, I'm on 2.31 now :) |
|
It is now just over three and a half years since I posted the OP. I have finally found time to have another go at getting this all set up on a Raspberry Pi running Raspbian and I have to say I am delighted with the results. For some reason actually getting .Net 6 properly installed took some work (the install script didn't appear to succeed at setting environment variables appropriately - I had to manually update .profile to set PATH and DOTNET_ROOT), but once I nailed that I found that everything works. I have .Net 6, dotnet-script, VSCode, the C# extension, source-level debugging and Intellisense - even when using .csx scripts (which was what I was really after). |
|
Can anyone help me: I still get that warning plus 'Couldn't find a debug adapter descriptor for debug type coreclr' Here's the steps I've taken (on a raspberry pi)
I initially tried a few other things. Fresh install maybe needed? Thanks, |
|
@changetocoding Yes, you would need a 64-bit Linux distro. I believe Raspbian is 32-bit by default. |
|
@JoeRobich Thanks :) |
|
Since this issue was filed O#/C#/Dev Kit all now support linux ARM. Closing |
Environment data
dotnet --infooutput:.NET Core SDK (reflecting any global.json):
Version: 2.2.101
Commit: 236713b0b7
Runtime Environment:
OS Name: raspbian
OS Version: 9
OS Platform: Linux
RID: linux-arm
Base Path: /home/pi/dotnet/sdk/2.2.101/
Host (useful for support):
Version: 2.2.0
Commit: 1249f08fed
.NET Core SDKs installed:
2.2.101 [/home/pi/dotnet/sdk]
.NET Core runtimes installed:
Microsoft.AspNetCore.All 2.2.0 [/home/pi/dotnet/shared/Microsoft.AspNetCore.All]
Microsoft.AspNetCore.App 2.2.0 [/home/pi/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 2.2.0 [/home/pi/dotnet/shared/Microsoft.NETCore.App]
VS Code version:
Version: 1.29.0 (user setup)
Commit: f74c7914490b68b4052ff877f04b6eaf7198f261
Date: 2018-10-16T15:00:48.287Z
Electron: 2.0.11
Chrome: 61.0.3163.100
Node.js: 8.9.3
V8: 6.1.534.41
Architecture: arm
C# Extension version:
1.17.1
Steps to reproduce
Hit F5 from a C# console application.
Expected behavior
Program builds and runs, and stops at breakpoints.
Actual behavior
[WARNING]: Processor architecture 'armv7l' is not currently supported by the .NET Core debugger. Debugging will not be available.
The text was updated successfully, but these errors were encountered: