vscode-csharp icon indicating copy to clipboard operation
vscode-csharp copied to clipboard

Feature request: support Linux ARM / ARM64

Open m-brooks opened this issue 6 years ago • 77 comments

Environment data

dotnet --info output: .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.

m-brooks avatar Jan 01 '19 08:01 m-brooks

@m-brooks my understanding is that VS Code doesn't have an official version for Linux ARM. Is that correct?

gregg-miskelly avatar Jan 01 '19 23:01 gregg-miskelly

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

m-brooks avatar Jan 02 '19 10:01 m-brooks

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 https://github.com/Microsoft/vscode/issues/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 --

  • The 'entry point' is a bit of JavaScript that interacts with the VS Code UI and glues everything together. VS Code itself provides the version of node that this runs on, so as long as VS Code works, this will work.
  • The language service is implemented in C# and runs on mono. It doesn't fully support ARM in the sense that it doesn't ship with an ARM version of mono. But from your description, it sounds like everything is fine as long as your box has a new enough ARM mono version installed.
  • The debugger is implemented in a mixture of C# and C++. Most of this is available for Linux ARM because we support Linux ARM as a remote debugging target. But currently we don't package it together for VS Code since there isn't an ARM version of VS Code to support.
  • The Razor language service is implemented in C#. There would need to be additional packaging work to support Linux ARM, but otherwise I believe things should just work.

gregg-miskelly avatar Jan 02 '19 17:01 gregg-miskelly

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

m-brooks avatar Jan 02 '19 18:01 m-brooks

@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 avatar Jun 11 '19 19:06 joaomoreno

@joaomoreno very cool! But to be clear, I am not sure this changes things too much --

  • If you want this because you just want to debug on a Raspberry Pi, but you will run VS Code on an x64 PC - that was actually something that the C# extension has supported for a long time via remote debugging. Some folks might find VS Code remote an interesting option as an alternative, but there are some downsides of that way too since you are running Omnisharp, which is pretty demanding, on ARM.
  • If you want this because you have a very inexpensive ARM-based computer that you would like to use as your PC, then you probably need full VS Code support (and probably a .NET SDK)

gregg-miskelly avatar Jun 11 '19 21:06 gregg-miskelly

@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 avatar Jun 16 '19 21:06 thesamesam

@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 avatar Jun 17 '19 14:06 gregg-miskelly

@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?

thesamesam avatar Jun 17 '19 22:06 thesamesam

If we fixed this issue, the remote scenario would also be addressed, so no need to open a separate issue.

gregg-miskelly avatar Jun 17 '19 22:06 gregg-miskelly

Big bummer this isn't working inside Raspbian. Cross-platform is still far from being real in 2019.

SuperJMN avatar Jun 23 '19 22:06 SuperJMN

By following Remote Development using SSH https://code.visualstudio.com/docs/remote/ssh

Python could be run and debugged without problem, However, run a c# project it displays

[ERROR] Error: spawn /home/pi/.vscode-server-insiders/extensions/ms-vscode.csharp-1.21.0/.omnisharp/1.34.0/run ENOENT

[Window Title] Visual Studio Code - Insiders

[Content] The C# extension is still downloading packages. Please see progress in the output window below.

[Open launch.json] [Cancel]

NetGH avatar Jul 29 '19 06:07 NetGH

@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 avatar Jul 29 '19 17:07 gregg-miskelly

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

bpranger avatar Aug 16 '19 14:08 bpranger

@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 avatar Jan 29 '20 20:01 nathansoz

@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 avatar Jan 29 '20 20:01 gregg-miskelly

@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:

image

nathansoz avatar Jan 29 '20 20:01 nathansoz

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: spawn /home//.vscode-oss/extensions/ms-vscode.csharp-1.21.11/.omnisharp/1.34.11/run ENOENT

tomflorin avatar Feb 07 '20 22:02 tomflorin

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.

kangaroo avatar Feb 24 '20 02:02 kangaroo

MacOS Arm64 should increase the priority of this.

sdmaclea avatar Jul 10 '20 18:07 sdmaclea

so, basically we'd need to strip all the legacy cruft from Omnisharp in order to get it to run on dotnet core (again?!) and then this should work?

Spongman avatar Aug 25 '20 07:08 Spongman

@kangaroo can you make a pull request?

lostmsu avatar Sep 04 '20 01:09 lostmsu

You can now run a free (until the end of 2020) ARM64 instance on AWS: https://aws.amazon.com/blogs/aws/new-t4g-instances-burstable-performance-powered-by-aws-graviton2/

lostmsu avatar Sep 14 '20 22:09 lostmsu

Pinebook Pro user here.

I understand the Omnisharp extension can only run on an official VS Code build.

Things are moving because very recently Microsoft announced the official Windows ARM version of VS Code.

The only thing I wish is that when an official Linux ARM version will be out, I'll be able to debug my favorite language on my arm64 laptop.

Thanks to all the team for your work.

jmevel avatar Sep 21 '20 09:09 jmevel

VS Code for arm is now released, currentky installed on my arm chromebook

Version: 1.50.0
Commit: 93c2f0fbf16c5a4b10e4d5f89737d9c2c25488a3
Date: 2020-10-07T06:01:12.076Z
Electron: 9.2.1
Chrome: 83.0.4103.122
Node.js: 12.14.1
V8: 8.3.110.13-electron.0
OS: Linux arm64 5.4.48-06434-gd868196d13af

baralong avatar Oct 10 '20 06:10 baralong

It's now close to 2 years since I posted the OP on this thread and we've seen great strides. Microsoft are now shipping builds of VSCode for Linux ARM and I have just successfully installed the 32 bit version on my Raspberry Pi (the Pi itself uses a 64 bit CPU but the Raspian OS is still 32 bit). I have also installed both .Net Core 3.1 and the dotnet-script REPL.

Unfortunately in one other respect things seem to have gone backwards. When I started this thread I had installed Jay Rodgers's headmelted ARM port of VSCode and was successfully using the Microsoft C# extension on it (other than debugging of course - that was the whole point of the post), or at least I thought I was (read on, because the details are a little more complex than I would have realised back then). However, I have installed that extension on my Microsoft-built installation of VSCode only to find that it reports "The C# extension for Visual Studio Code (powered by OmniSharp) is incompatible on linux armv7l".

That said, when I create a CSX or C# file and start editing, all looks good (nice syntax highlighting) and formats nicely (I do also have the C# FixFormat 0.0.85 extension installed, so possibly that has something to do with it). I seem to have a halfway house when it comes to Intellisense - if I type "for" then Intellisense suggests for, foreach, forr and I can make a selection and get a nice snippet, but if I type "Console." then Intellisense does not kick in to show me the methods and properties of the Console static class as it would on a Windows PC. So I seem to have C# intellisense but not .Net intellisense, which if anything is back to front from what I'd expect given the notification mentioned above.

When I hit F5 to debug I get the message "Couldn't find a debug adapter descriptor for debug type 'coreclr' (extension might have failed to activate)", which maybe supports the notification that was claiming that the C# extension isn't working?

Anyone (especially @gregg-miskelly ) any insight into what needs to be done next in order to get C# or CSX debugging working and Intellisense working properly?

m-brooks avatar Oct 10 '20 18:10 m-brooks

if I type "for" then Intellisense suggests for, foreach, forr and I can make a selection and get a nice snippet, but if I type "Console." then Intellisense does not kick in to show me the methods and properties of the Console static class as it would on a Windows PC.

That's not Intellisense, that's the default autocomplete. It behaves like a simple text editor, it also suggests previously used words. I could live without a debugger, but without Intellisense what's the point of installing vscode

SLS8 avatar Oct 12 '20 12:10 SLS8

Really hoping this gets some focus - I use VS Code and C# everywhere, but was sadly disappointed when I couldn't install on my highly portable Lenovo Chromebook Duet

scottyearsley avatar Oct 18 '20 20:10 scottyearsley

Really hoping this gets some focus - I use VS Code and C# everywhere, but was sadly disappointed when I couldn't install on my highly portable Lenovo Chromebook Duet

I have the exact same machine. Hoping it comes soon. Does omnisharp itself build on arm?

baralong avatar Oct 19 '20 01:10 baralong

Raspbian user here wishing to have this feature.


From: Doug Paice [email protected] Sent: Monday, October 19, 2020 3:58:46 AM To: OmniSharp/omnisharp-vscode [email protected] Cc: José Manuel Nieto [email protected]; Comment [email protected] Subject: Re: [OmniSharp/omnisharp-vscode] Feature request: support Linux ARM (#2771)

Really hoping this gets some focus - I use VS Code and C# everywhere, but was sadly disappointed when I couldn't install on my highly portable Lenovo Chromebook Duet

I have the exact same machine. Hoping it comes soon.

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://eur06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FOmniSharp%2Fomnisharp-vscode%2Fissues%2F2771%23issuecomment-711467612&data=04%7C01%7C%7C3514927e6dcd4df7e10b08d873d28479%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637386695277777814%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=dIKzQOImHMj1w4wEcPrRQI3HvBz%2B%2BCH6o9KxFa%2BE%2Bmc%3D&reserved=0, or unsubscribehttps://eur06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAAXXHW5Q7PXJSKOIBNXNPATSLOMNNANCNFSM4GMXIU7Q&data=04%7C01%7C%7C3514927e6dcd4df7e10b08d873d28479%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637386695277787808%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=MzBhFt%2FkzInlnd1BJlUsAI3lAkurWWoX9QUIDmjno2w%3D&reserved=0.

SuperJMN avatar Oct 19 '20 07:10 SuperJMN