Archlinux - ms-vscode.csharp - "Error while installing .NET Core Debugger"

[weinand]

From @vindicatorr on July 13, 2016 9:17

• VSCode Version: 1.3.1
• OS Version: Archlinux 4.6.3 - KDE 5.7.1
• Mono Version: 4.3.3

Steps to Reproduce:

1. Extract VSCode

2. mkdir test; cd test; dotnet new

3. Start VSCode and Open Folder for newly created "test"

4. Enable recommended "ms-vscode.csharp" (and restart VSCode)

   Error while installing .NET Core Debugger
   

5. View Log

   ...
   Creating /home/username/.vscode/extensions/ms-vscode.csharp-1.2.2/coreclr-debug/project.json
   Telemetry is: Enabled
   
   log  : Restoring packages for /home/username/.vscode/extensions/ms-vscode.csharp-1.2.2/coreclr-debug/project.json...
   
   error: System.IO 4.1.0 provides a compile-time reference assembly for System.IO on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with arch.-x64.
   ...
   log  : Writing lock file to disk. Path: /home/username/.vscode/extensions/ms-vscode.csharp-1.2.2/coreclr-debug/project.lock.json
   
   log  : /home/username/.vscode/extensions/ms-vscode.csharp-1.2.2/coreclr-debug/project.json
   log  : Restore failed in 2012ms.
   
   Error: 
   Errors in /home/username/.vscode/extensions/ms-vscode.csharp-1.2.2/coreclr-debug/project.json
   
   Error:     System.IO 4.1.0 provides a compile-time reference assembly for System.IO on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with arch.-x64.
   ...
   System.Threading.Timer on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with arch.-x64.
   One or more packages are incompatible with .NETCoreApp,Version=v1.0 (arch.-x64).
   
   dotnet exited with error code 1
   

That is only part of the issue. The other part relates to omnisharp which I think I'll be submitting to their repository.

Copied from original issue: microsoft/vscode#9192

[gregg-miskelly]

@Vindicator as far as I know, Arch Linux isn't yet officially supported by .NET Core (ex: I don't see it listed on https://www.microsoft.com/net/core). I don't think we would support it for the debugger until it becomes officially supported.

[vindicatorr]

So be it if you want to wait for an "official okey-dokey" from the core team, but do know that dotnet does work in Arch: https://github.com/dotnet/coreclr/issues/5006#issuecomment-229472022
You'll see in later comments and other issues I've opened with core* that we just can't build it from scratch in Arch (I may give it another go since it's been awhile). Abrodersen just used the Fedora package.

I will also add that I may have been a lucky tester of abrodersen's package as I just now looked at the comments for his package on AUR that people were having issues building it. I already had all dependencies from when I attempted building from scratch in the past.

If you're looking for a guinea-pig, just come-a-knockin'.

[gregg-miskelly]

@vindicatorr in a later comment though, it sounds like Abrodersen rebuilt the native binaries on Arch. Do I have that right?

If the Fedora 23 runtime will work as-is (in other words the native binaries in the Fedora package are binary compatible with Arch), then we can probably do a quick tweak to this switch statement to add support for Arch.

If we need a new runtime - because both OmniSharp and the debugger package carry there own runtime, there isn't a simple official fix we can do. If you are interested in getting this to work on your own box - that is very doable.

[vindicatorr]

Oh right, native are built locally on Arch: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=dotnet-cli, just not mscorlib and related managed libraries.
You can see where he runs "build.sh" for both clr and fx.

For the sake of testing ONLY fedora dotnet in Arch, I overwrote abrodersen's build with the fedora tarball (including native) and as expected dotnet fails (0x80131500).
So the Fedora runtime will NOT work as-is. Native HAS to be built locally on Arch.

[gregg-miskelly]

Thanks @Vindicator. I moved this issue and #563 to the 'future' milestone for now as I don't know when there will be official packages for Arch. But we can give you instructions that you can try if you want to play around with this yourself.

/cc @DustinCampbell

[vindicatorr]

Certainly, I can give it a go in a couple days after I give clr and fx another go.

[harry-cpp]

What part of code is generating "runtimes" line in "coreclr-debug/project.json"?

EDIT: Never mind, found it, the project is much better organized than I anticipated.

[elangelo]

Is possible to receive some instructions too? I'm used to working with archlinux for quite a while and have been een C# dev for decade too. Hate to have to switch distro just to get debugging to work.

[gregg-miskelly]

@elangelo is there an arch-Linux compatible version of .NET Core available for download from Microsoft?

If one of the official builds from Microsoft works - this is pretty easy, we just need to change the platform detection code in src/platform.ts to return the runtime id of this compatible distro.

Otherwise - this might not be possible to solve. You could try downloading one of the debugger zip files and then replacing all the CoreCLR binaries in it. I would use one of the 1-6-0 zip's as those move to the 1.1 CLR (see #1000 for the PR that switched to this).

[elangelo]

I have dotnet running on my ArchLinux machine. The tarball for ubuntu 16.04 of dotnet (dotnet-dev-ubuntu.16.04-x64.1.0.0-preview2-1-003177.tar.gz) works just fine on archlinux as well.

So i downloaded the ubuntu coreclr-debug zip referred to in PR 1000, where am i supposed to put this? I think this one should actually just work on my install.

[gregg-miskelly]

@elangelo can you try downloading https://vsdebugger.azureedge.net/coreclr-debug-1-6-0/coreclr-debug-ubuntu.16.04-x64.zip and extracting it to ~/.vscode/extensions/ms-vscode.csharp-ver/.debugger (replace ver with the version you have installed, make sure it is at least 1.5). Please verify you can hit breakpoints and the locals window will populate.

If that works, cat you send me your /etc/os-release file?

[elangelo]

@gregg-miskelly this worked thnx!
what i did:

• created .debugger directory in ~/.vscode/extensions/ms-vscode.csharp-1.5.3/.debugger
• unzipped the content of coreclr-debug-ubuntu.16.04-x64.zip in .debugger
• chmod +x OpenDebugAD7 and clrdbg (not sure why these two lost their executable properties, maybe zip doesn't understand those?)
• open C# project and finally enjoy debugging

for your info: /etc/OS_RELEASE#NAME="Arch Linux"
ID=arch
PRETTY_NAME="Arch Linux"
ANSI_COLOR="0;36"
HOME_URL="https://www.archlinux.org/"
SUPPORT_URL="https://bbs.archlinux.org/"
BUG_REPORT_URL="https://bugs.archlinux.org/"
VERSION_ID="2016.06.20"

VERSION_ID is actually the installed date of the OS so this has nothing to do with the actual version of Arch Linux, Arch Linux is a rolling release distro so everybody that cares a bit for their machine is actually running recent stuff.

[harry-cpp]

You can also include Antergos if you are submitting something for Arch Linux, since it's like a glorified installer for Arch, the etc/os-release file for it looks like:

NAME="Antergos Linux"
VERSION="16.9-ISO-Rolling"
ID="antergos"
ID_LIKE="arch"
PRETTY_NAME="Antergos Linux"
CPE_NAME="cpe:/o:antergosproject:antergos:16.9"
ANSI_COLOR="1;34;40"
HOME_URL="https://antergos.com/"
SUPPORT_URL="https://forum.antergos.com/"
BUG_REPORT_URL="https://github.com/antergos"

[gregg-miskelly]

@cra0zy we will respect ID_LIKE so actually that will automatically work if I check for 'arch'.

Okay, I will try and get out a fix for this soon.

[gregg-miskelly]

Okay, I have what I think is a fix. If someone can validate it that would be helpful:

1. Download this file: csharp-1.6.0-dev-ArchLinux.vsix.renamed.zip
2. Remove the '.renamed.zip' extension from the file
3. Follow the instructions on installing beta releases for installing the .vsix into VS code.

Thanks!

[elangelo]

@gregg-miskelly just tested this. Works like a charm! (Y)

[gregg-miskelly]

@elangelo Excellent. I will merge the PR then. Thanks!

[NikkyAI]

@gregg-miskelly ID_LIKE seems to not be handled correctly
my /etc/os-release:

NAME="Manjaro Linux"
ID=manjaro
ID_LIKE="arch"
PRETTY_NAME="Manjaro Linux"
ANSI_COLOR="1;32"
HOME_URL="http://www.manjaro.org/"
SUPPORT_URL="http://www.manjaro.org/"
BUG_REPORT_URL="http://bugs.manjaro.org/"

i added the ID_LIKE line myself
and it always reports this: [WARNING]: The current Linux distribution 'manjaro' version 'unknown' is not currently supported by the .NET Core debugger. Debugging will not be available.

[gregg-miskelly]

@NikkyAI do you by chance have trailing spaces after the closing quote?

You can see the code here: https://github.com/OmniSharp/omnisharp-vscode/blob/master/src/platform.ts#L75

I don't see anything obviously wrong with the code. You are welcome to open a bug if you want somehow to help investigate.

[NikkyAI]

changing it from ID_LIKE="arch"
to ID_LIKE=arch fixes it, probably there was trailing spaces though

and yet another problem...

Debug adapter process has terminated unexpectedly
it crashes instantly after building
happens on my laptop (manjaro) and a friends arch laptop

[gregg-miskelly]

@NikkyAI there seems to be some dispute over which version of coreclr actually works on Arch. We had one user previously report that Ubuntu 16 worked, so that is what we went with. But we had another recent user report that Ubuntu 16 didn't work, but Ubuntu 14 did. Can you try this --

cd ~/.vscode/extensions/ms-vscode.csharp-1.7.0 (replace 1.7.0 with the version you have installed)

Find the ubuntu 14 URL with: grep coreclr-debug package.json | grep ubuntu.14.04 | head -1. This should give you something like: https://vsdebugger.azureedge.net/coreclr-debug-1-7-1/coreclr-debug-ubuntu.14.04-x64.zip.

Download and extact that zip to the '.debugger' folder under the extension root (ex: ~/.vscode/extensions/ms-vscode.csharp-1.7.0/.debugger).

echo install.complete > .debugger/install.complete
chmod +x .debugger/OpenDebugAD7
chmod +x .debugger/clrdbg

[NikkyAI]

i guess i should have opened another issue for this..
and sadly this seems to not change anything :(
i tested on 1.7.0 and after updating the plugin to 1.8.0 (after that the binaries changed to vsdbg and vsdbg-ui apparently?)

[starquake]

I think I managed to fix this. See the referenced issue.