sdk: SDK resolver does not work with snap installations of SDK on Linux
See https://github.com/OmniSharp/omnisharp-vscode/issues/3160
When installed via snap:
sudo snap install dotnet-sdk --beta --classic
sudo snap alias dotnet-sdk.dotnet dotnet
Then dotnet on PATH resolves to a realpath of /usr/bin/snap and not to a dotnet executable next to the sdk foler.
This breaks an assumption of the resolver that we can use realpath on dotnet on PATH to find the SDK.
We could maybe implement something like the much slower option of shelling out to dotnet --info as msbuildlocator and legacy omnisharp do. Or we would need a way to resolve to the real directory somehow. I am not sure if snap gives us this ability. Is there a way to query snap to know if there is a dotnet-sdk installed and where can we find it’s real directory. Can we do this without forking processes and parsing stdout?
The slow path could be a fallback. If there is a dotnet on PATH, but it does not resolve to a realpath with an sdk directory, try running it with --info. This would fix other hypothetical deployments like a dotnet that is a shell script that execs dotnet with custom args or whatever. It may make sense to keep this as an ultimate fallback even if we find a more efficient way to handle the snap case.
About this issue
- Original URL
- State: open
- Created 5 years ago
- Reactions: 5
- Comments: 37 (14 by maintainers)
I was struggling with omnisharp not resolving the dotnet-sdk snap on 20.04 until I discovered that a simple
ln -s /snap/dotnet-sdk/current/dotnet /usr/local/bin/dotnetdid the trick. No need for msbuild path exports or an omnisharp json legacy resolver.
DO NOT USE Ubuntu. Not even the Binary file from https://dotnet.microsoft.com/download/dotnet/5.0 works because the dotnet executable is not recognized on Ubuntu. I guess it is related to dotnet-sdk on snap on Ubuntu.
I have no problems using the .net5 RC1 on Fedora 33 beta.
Download the dotnet-sdk SDK manually. I have downloaded the Binaries from https://dotnet.microsoft.com/download/dotnet/5.0 No package manager.
Start VSCode with a script file with this content: export PATH=$PATH:/YYY/ /home/XXX/Downloads/VSCode/code-insiders
where you have to adapt XXX and YYY to your case. YYY is the folder where you have stored the SDK.
DO NOT USE Ubuntu snap. Someone working on snap dotnet-sdk must have introduced an automatic “dotnet” alias that is listed but can not be removed with the “sudo snap unalias dotnet” command because Error: “cannot find manual alias “dotnet” in any snap”. Unfortunately the people working on omnisharp do not care about this problem.
From my console:
xxx:~$ dotnet
Usage: dotnet [options] Usage: dotnet [path-to-application]
Options: -h|–help Display help. –info Display .NET information. –list-sdks Display the installed SDKs. –list-runtimes Display the installed runtimes.
path-to-application: The path to an application .dll file to execute. xxx:~$ snap aliases Befehl Alias Anmerkungen dotnet-sdk.dotnet dotnet - xxx:~$ sudo snap unalias dotnet Fehler: cannot find manual alias “dotnet” in any snap
Previously:
I made this post already here and here.
On Ubuntu 20.04.1, the problem is the snap alias. Do not install it.
Instead do this:
sudo snap install dotnet-sdk --channel=5.0/beta --classic
DO NOT install the alias because it makes Omnisharp not find the SDK. sudo snap alias dotnet-sdk.dotnet dotnet
It can be removed with: sudo snap unalias dotnet
Start VSCode with a script file with this content: export PATH=$PATH:/snap/dotnet-sdk/current/ /home/XXX/Downloads/VSCode/code-insiders
You have to adapt the second line, that starts VSCode insiders, to your case.
For anyone else having this problem after installing the dotnet sdk using apt on ubuntu, I found that having dotnet at /usr/share/dotnet doesn’t work on its own. However, if I create a symlink from /usr/share/dotnet to ~/dotnet, it works. I also have set the MSBuildSdksPath:
export MSBuildSDKsPath="/usr/share/dotnet/sdk/$(dotnet --version)/Sdks"Thanks! It’s works as a charm!
Only, I found other problem, for example, if you want execute your project from command line:
dotnet run <your.dll>ordotnet run bin/Debug/netcoreapp3.1/<your.dll>threw an exception. I solved this problem here: https://github.com/dotnet/core/issues/2186#issuecomment-472629489p.d: My apologies, but my English is not very good.
I don’t think only the snap is affected. The very same problem occurs on Manjaro/Arch Linux (issue has been reported by many) when you install
dotnetwithpacman. In this casepacmanpulls the package from community repo. And the package containsdotnet.shwhich is effectively added toPATHafter being installed to/usr/bin. Obviously it is not a symlink, so the resolving process fails. The SDK itself is installed to/opt/dotnet/, all SDK folders and the executable are in place. BTW, adding .json with legacy option solves/hides the issue.Fantastic. This solved for me too. Thank you