There are some problems connecting to the language server

[wosledon]

OS: Ubuntu 23
Env: snap dotnet 7.0.11
Error: unknown command /home/powers/.vscode/extensions/ms-dotnettools.csharp-2.5.30-linux-x64/.roslyn/Microsoft.CodeAnalysis.LanguageServer.dll

[dibarbet]

It looks like for some reason the path we're getting to the dotnet executable (from $PATH) is /usr/bin/snap which is not a valid dotnet executable.

@DonPangPang would you mind sharing a bit more info here

1. The contents of the /usr/bin/snap folder? Is there a dotnet executable inside of it?
2. The output of running which dotnet from the terminal

[dibarbet]

I was able to reproduce this. It appears to be due to an issue with snap and symlinks.

Running the following on a snap dotnet installed system

dibarbet@dibarbet-Virtual-Machine:~$ which dotnet
/snap/bin/dotnet
dibarbet@dibarbet-Virtual-Machine:~$ realpath /snap/bin/dotnet
/usr/bin/snap

The issue is that we are expecting the real path to point to a dotnet executable, but with snap it points to the snap executable. I'm not familiar enough yet with snap yet to understand why.

The 'real' location of dotnet appears to be /snap/dotnet-sdk/221/dotnet or /snap/dotnet-sdk/current/dotnet

@DonPangPang I think you could probably workaround this issue if you set the dotnet.dotnetPath option to /snap/dotnet-sdk/current/

[wosledon]

Reference

1. dotnet notfound
2. watch run is /snap/bin/dotnet

[wosledon]

I was able to reproduce this. It appears to be due to an issue with snap and symlinks.

Running the following on a snap dotnet installed system

dibarbet@dibarbet-Virtual-Machine:~$ which dotnet
/snap/bin/dotnet
dibarbet@dibarbet-Virtual-Machine:~$ realpath /snap/bin/dotnet
/usr/bin/snap

The issue is that we are expecting the real path to point to a dotnet executable, but with snap it points to the snap executable. I'm not familiar enough yet with snap yet to understand why.

The 'real' location of dotnet appears to be /snap/dotnet-sdk/221/dotnet or /snap/dotnet-sdk/current/dotnet

@DonPangPang I think you could probably workaround this issue if you set the dotnet.dotnetPath option to /snap/dotnet-sdk/current/

path: /snap/bin

powers@ubuntu:bin$ ll
lrwxrwxrwx  1 root root   17 10月  9 18:35 dotnet -> dotnet-sdk.dotnet*
lrwxrwxrwx  1 root root   13 10月  9 18:35 dotnet-sdk.dotnet -> /usr/bin/snap*

the dotnet had linked to dotnet-sdk.dotnet

[wosledon]

when i set Dotnet:Dotnet Path to /snap/bin, it looks fine;

[wosledon]

there is also something wrong with C# Dev Kit, it was not get the dotnet path from the C# extension..

[dibarbet]

Thanks for the info!

FYI @AArnott for the C# devkit side. In summary, a dotnet installation from snap will have the dotnet on the path symlinked to the snap executable instead of the actual dotnet executable.

Am talking to @nagilson to see if there is a better way to find the dotnet executable. I don't have a specific solution here yet, but potentially looking 2 folders up from the SDK path output by dotnet --info.

[nagilson]

which dotnet should typically return the same thing as dotnet --info. which dotnet returns the .NET on the path. dotnet --info will return the assembly location of the currently running dotnet assembly and use that to find the SDK path, and the dotnet that gets called should be the one on the PATH. But because the PATH and therefore which dotnet might be a symlink, dotnet --info will be different, because it is going to use the assembly location, which would be the unreferenced symlink.

I suggested @dibarbet reach out to the runtime team to confirm that this approach works. Note that the SDK team advises people to not use dotnet --info because it could change and isnt super machine readable, but we don't have a better option for you yet...

[AArnott]

What does ls -l /snap/bin/dotnet print out? I'm curious whether it's realpath that's failing or whether the symlink for /snap/bin/dotnet really does resolve to /usr/bin/snap.

[dibarbet]

@AArnott I think it genuinely is /usr/bin/snap, from my vm:

dibarbet@dibarbet-Virtual-Machine:~$ ls -l /snap/bin/dotnet
lrwxrwxrwx 1 root root 17 Oct 10 13:43 /snap/bin/dotnet -> dotnet-sdk.dotnet
dibarbet@dibarbet-Virtual-Machine:~$ ls -l /snap/bin/dotnet-sdk.dotnet 
lrwxrwxrwx 1 root root 13 Oct 10 13:43 /snap/bin/dotnet-sdk.dotnet -> /usr/bin/snap

Also pasting snippets of my offline conversation with @elinor-fung

Assuming you always have an SDK installed (as opposed to only having a runtime installed), dotnet --list-sdks and the parent of the sdk folder should work.

And answering if the same applies to the runtime folder output by dotnet --list-runtimes

Yep, it would be two above the runtime folder. The sdk and runtime folders have a known layout relative to the root, so you should be able to rely on having the root location relative to the runtime/sdk folder path.

So as Noah mentioned, a potential solution here is to get the path from dotnet --list-runtimes and find the dotnet exe two folders up, based on the known layout. And then we can avoid any snap/symlink shenanigans

[wosledon]

My sln is: create a link as ln -s /snap/bin/dotnet /usr/bin/dotnet

[dibarbet]

The C# extension side fix should be released next week. I've filed microsoft/vscode-dotnettools#605 to track the fix on the devkit side.

[wosledon]

The C# extension side fix should be released next week. I've filed microsoft/vscode-dotnettools#605 to track the fix on the devkit side.

okey，thanks.