Support remote alpine containers (and other linux-musl based-OSs)

[mipnw]

Issue Description

I'm unable to run or debug C# xUnit tests directly in VSCode with Remote to WSL/Alpine. I am however able to run those test on the WSL command line with dotnet test. This seems to be a problem with Omnisharp's C# extension to VSCode.

Steps to Reproduce

• On Windows, with WSL installed and an Alpine Linux distribution.
• VSCode has the "Remote- WSL" extension.
• VSCode has the "C#" extension installed locally, and installed in WSL/Alpine (the server part)
• In VSCode open a Remote WSL folder that contains an xUnit test.
• Then open a specific *.cs unit test file.

Expected Behavior

The *.cs file should soon be decorated with "Run Test" and "Debug Test" around each unit test, allowing them to be run or debugged directly from VSCode.

Actual Behavior

The unit test do not contain "Run Test" or "Debug Test" decorations.

The same *cs file loaded with VSCode on a local folder instead of a remote WSL folder, shows those links. These links are only missing when running on Remote WSL.

Logs

The logs show that Omnisharp fails to load ld-linux-x86-64.so.2.
An internet search showed this may be due to not having libc6-compat installed, but in my case that package is installed:

> apk info libc6-compat
libc6-compat-1.1.22-r3 description:
compatibility libraries for glibc

libc6-compat-1.1.22-r3 webpage:
http://www.musl-libc.org/

libc6-compat-1.1.22-r3 installed size:
12288

> apk info -L libc6-compat
libc6-compat-1.1.22-r3 contains:
lib/libm.so.6
lib/libc.so.6
lib/libcrypt.so.1
lib/librt.so.1
lib/libutil.so.1
lib/libpthread.so.0
lib64/ld-linux-x86-64.so.2

Double checking ld-linux-x86-64.so is actually installed

>ls -l /lib64/ld-linux-x86-64.so.2 
lrwxrwxrwx    1 root     root            26 Feb 28 19:27 /lib64/ld-linux-x86-64.so.2 -> /lib/libc.musl-x86_64.so.1

>ls -l /lib/libc.musl-x86_64.so.1
lrwxrwxrwx    1 root     root            19 Aug 20  2019 /lib/libc.musl-x86_64.so.1 -> ld-musl-x86_64.so.1

>ls -l /lib/ld-musl-x86_64.so.1
-rwxr-xr-x    1 root     root        580144 Aug  7  2019 /lib/ld-musl-x86_64.so.1

OmniSharp log

Starting OmniSharp server at 3/5/2020, 7:59:42 PM
Target: /home/username/path/file.sln

OmniSharp server started.
Path: /home/username/.vscode-server/extensions/ms-dotnettools.csharp-1.21.13/.omnisharp/1.34.13/run
PID: 264

Error loading shared library ld-linux-x86-64.so.2: No such file or directory (needed by /home/username/.vscode-server/extensions/ms-dotnettools.csharp-1.21.13/.omnisharp/1.34.13/bin/mono)

C# log

nstalling C# dependencies... Platform: linux, x86_64, name=alpine, version=3.10.2

Downloading package 'OmniSharp for Linux (x64)' (43753 KB).................... Done!
Validating download...
Integrity Check succeeded.
Installing package 'OmniSharp for Linux (x64)'

Downloading package '.NET Core Debugger (linux / x64)' (54207 KB).................... Done!
Validating download...
Integrity Check succeeded.
Installing package '.NET Core Debugger (linux / x64)'

Downloading package 'Razor Language Server (Linux / x64)' (52181 KB).................... Done!
Installing package 'Razor Language Server (Linux / x64)'

Finished

Environment information

VSCode version: 1.42.1
C# Extension: 1.21.13

Mono Information

OmniSharp using built-in mono

Dotnet Information

.NET Core SDK (reflecting any global.json): Version: 3.1.102 Commit: 573d158fea

Runtime Environment:
OS Name: alpine
OS Version: 3.10
OS Platform: Linux
RID: alpine.3.10-x64
Base Path: /usr/local/dotnet/sdk/3.1.102/

Host (useful for support):
Version: 3.1.2
Commit: 916b5cba26

.NET Core SDKs installed:
3.1.102 [/usr/local/dotnet/sdk]

.NET Core runtimes installed:
Microsoft.AspNetCore.App 3.1.2 [/usr/local/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 3.1.2 [/usr/local/dotnet/shared/Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs:
https://aka.ms/dotnet-download

Visual Studio Code Extensions

Extension	Author	Version
csharp	ms-dotnettools	1.21.13
Go	ms-vscode	0.13.1

[gregg-miskelly]

This is really a non-trivial feature request: we would need to either start packaging up Alpine-compatible bits for all the parts of the extension, or support remote test running.

[gregg-miskelly]

Work around in case anyone is feeling completely blocked by this:

1. Run unit tests from the command line
2. If you need to debug a unit test, add a while (!Debugger.IsAttached) Thread.Sleep(100); loop at the start of the test and remotely attach.

[rickardp]

This is kind of a blocker for using codespaces / VS code remote containers for our project since our entire build system is based on Alpine.

Can OmniSharp be made to run on the provided dotnetcore installation instead of using some bundled Mono? It must also reduce the installation time. I understand you want to improve portability, but depending on glibc shows this is currently not true anyway.

(Maybe my comment should be a separate issue though)

[JoeRobich]

Can OmniSharp be made to run on the provided dotnetcore installation instead of using some bundled Mono?

That future seems more and more likely as .NET 5 then .NET 6 ship, but currently there are no plans or timelines to drop Full Framework support from the C# extension (which is what mono provides).

[rickardp]

@JoeRobich I understand the point, but from a user base perspective, I think Alpine is quite big and IIRC the only reason to support the full framework is Xamarin and Unity (IIRC .NET core is supported for win Desktop apps these days). Wouldn't it be worthwile to consider the user base for backend services on Alpine containers at least as large as the Xamarin/Unity user base when it comes to VS code, considering the bespoke IDEs for the other ones?

Or could there be another path to supporting Alpine?

(I note that in MS docs, they tend to go with Alpine except for the codespaces templates. Maybe OmniSharp support is the reason?)

[rickardp]

I fixed the Mono bug blocking this a while back
mono/mono#7167

I think it should be possible to create an Alpine version of OmniSharp now. It is possible to work around this by baking mono into the Alpine dev image and setting "omnisharp.useGlobalMono": "always", but I think this should be properly supported by OmniSharp, given how useful Alpine is for developing microservices in c#

[wuhkuh]

A possible workaround would be installing the gcompat package on your Alpine Linux installation.

[rickardp]

@wuhkuh
It is probably a valid workaround, but IMHO it is not a reason not to fix this issue

[wuhkuh]

@rickardp Agreed 100%, just shared this so users could get their setup up and running if they hadn't already ^^

[filipw]

The next version of OmniSharp server will have a .NET 6 build specifically for musl-based distros like Alpine OmniSharp/omnisharp-roslyn#2395