Runtime: Installing through snap fails to create symlink

[Petermarcu]

@tristan957 commented on Wed Jun 06 2018

I tried to run the dotnet tool. Ended having to call it like this:

dotnet-sdk.dotnet help ln: failed to create symbolic link '/var/snap/dotnet-sdk/18/Microsoft.NETCore.App/2.1.0': No such file or directory

I installed it through snap using the commands in the README on Solus

[steveharter]

@tristan957 I'm not sure by what "Ended having to call it like this:" means. Did it work with dotnet-sdk.dotnet help but not just dotnet help?

Is the dotnet executable in your path?

[tristan957]

dotnet-sdk.dotnet help works and is on my path. The dotnet executable is not on my path. If I had to guess the error is because the snap failed to symlink dotnet to dotnet-sdk.dotnet.

[steveharter]

@rakeshsinghranchi ptal

[rakeshsinghranchi]

@leecow , are you aware of this issue?

[leecow]

@tristan957 , the need to call dotnet using dotnet-sdk.dotnet has to do with how Snaps are constructed and exposed commands are accessed and the way that all interacts with the dotnet host. Retaining the Snap namespace for calling dotnet was the direction we wanted to experiment with first as it will allow distinct calling of install SDKs and Runtime versions.

The easiest way to enable `dotnet for you will be to use Snap's alias feature. The following will get you going but will essentially tie the dotnet command to this Snap installed SDK.

sudo snap alias dotnet-sdk.dotnet dotnet

This unfortunately does not get us past the SSL errors when projects are trying to restore.

[tristan957]

I don't mind running the alias, but does that solve the symlink issue? That symlink error happens every time you run a dotnet command from what I remember. I had tried using the C# extension on VSCode. I am not sure if it was the name of the executable giving it fits or the extensions inability to find what it was looking for, but it is just something you may want to be aware of.

[leecow]

Thanks. I haven't been able to reproduce the symlink issue but will definitely keep an eye out. On a happier note, I believe I've figured out the SSL and restore issue in your other post.

[tristan957]

Awesome. I can try to reinstall the snap too. It has been a few weeks since I tried anything dotnet related. Do you know the directories that I should make sure got deleted when I snap uninstall/remove? Maybe something in $HOME/.snap and something in /var/lib/...?

[m5x]

Just a note that I have also encoutered this issue. Fresh install of dotnet snaps and snap itself on an updated Solus Linux. Snap tries to create symlink to directory /var/snap/dotnet-sdk/20/Microsoft.NETCore.App/2.1.0 but on my system it does not exist (directory /var/snap/dotnet-sdk/20 is empty).

[gmol1]

Thanks. I haven't been able to reproduce the symlink issue but will definitely keep an eye out. On a happier note, I believe I've figured out the SSL and restore issue in your other post.

@leecow, I was able to reproduce the issue under Ubuntu 16.04 and Solus 3, it happens when both the SDK and the runtime snaps are installed in the same system, to reproduce:

sudo snap install dotnet-sdk --classic
sudo snap install dotnet-runtime-21

I believe I've figured out the SSL and restore issue in your other post.

Do you have any update on this? I'm experiencing the same issue under Solus 3 (but not Ubuntu).

# dotnet new console -o hello_world
The template "Console Application" was created successfully.

Processing post-creation actions...
Running 'dotnet restore' on hello_world/hello_world.csproj...
  Restoring packages for ~/dotnet/hello_world/hello_world.csproj...
/snap/dotnet-sdk/23/sdk/2.1.403/NuGet.targets(114,5): error : Unable to load the service index for source https://api.nuget.org/v3/index.json. [~/dotnet/hello_world/hello_world.csproj]
/snap/dotnet-sdk/23/sdk/2.1.403/NuGet.targets(114,5): error :   The SSL connection could not be established, see inner exception. [~/dotnet/hello_world/hello_world.csproj]
/snap/dotnet-sdk/23/sdk/2.1.403/NuGet.targets(114,5): error :   The remote certificate is invalid according to the validation procedure. [~/dotnet/hello_world/hello_world.csproj]

[nicorikken]

@leecow thanks for suggesting the alias. That seems to work, but I guess I'm having the same issue still:

$ dotnet help
[sudo] password for nico: 
ln: failed to create symbolic link '/var/snap/dotnet-sdk/24/Microsoft.NETCore.App/2.1.6': No such file or directory
.NET Command Line Tools (2.1.500)
Usage: dotnet [runtime-options] [path-to-application] [arguments]

I find it particularly curious that I'm required to become sudo in order to run the command. Then again I still need that if I run the underlying dotnet-sdk.dotnet command:

$ dotnet-sdk.dotnet 
[sudo] password for nico: 
ln: failed to create symbolic link '/var/snap/dotnet-sdk/24/Microsoft.NETCore.App/2.1.6': No such file or directory

Usage: dotnet [options]
Usage: dotnet [path-to-application]

Options:
  -h|--help         Display help.
  --info            Display .NET Core 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.

I'm running Ubuntu 18.04
It doesn't seem to affect me at the moment, I mainly came here for the alias suggestion, as VScode has extentions calling the dotnet command. Hopefully my comment helps this discussion.

[KarlisVe]

I have same problem on "clean" Ubuntu 18.04.

Installation:

sudo snap install dotnet-sdk --classic

Running dotnet :
Command 'dotnet' not found, but can be installed with: sudo snap install dotnet-sdk

Running dotnet-sdk.dotnet help:
ln: failed to create symbolic link '/var/snap/dotnet-sdk/24/Microsoft.NETCore.App/2.1.6': No such file or directory .NET Command Line Tools (2.1.500) Usage: dotnet [runtime-options] [path-to-application] [arguments] etc ...

[mnavarrocarter]

This is a snap predefined behavior AFAIK. It is so in order to prevent binary names clashing. If you don't have another dotnet binary in your system or you don't plan to, you can safely run sudo snap alias dotnet-sdk.dotnet dotnet to alias the snap binary to the classic dotnet command.

[feliwir]

Having this issue aswell.

[thaxy]

Same issue here... on ubuntu 18.04 installed with sudo snap install dotnet-sdk --classic

[WereDev]

So it appears that the normal dotnet command is available via dotnet-sdk.dotnet eg dotnet-sdk.dotnet --version. I'm not sure if this is intended behavior, but was definitely unexpected.

Using notes from above, sudo snap alias dotnet-sdk.dotnet dotnet does make the normal dotnet command available. It's a bit annoying that this is something that would have to be managed manually. I'm also curious what sort of side-effects this might have.

[tristan957]

As stated before, its a namespacing by snapd. Canonical probably doesn't want to police binary names and make sure they don't conflict, so instead they just prefix all binaries with the package name because they can guarantee package uniqueness. It is not a bug or weird. It is a feature.

[LexVocoder]

I just ran into this. I wasted probably 20 minutes (including time finding this issue).

Could the recommendation to run the alias command be added to the installation? I have seen other snaps open windows with similar directions.

[phillipsj]

These are no longer allowed to be created using the snapcraft.yaml and will need to be requested by the team on the Snap Store. https://forum.snapcraft.io/t/process-for-aliases-auto-connections-and-tracks/455

[phillipsj]

If you want the alias "dotnet' you can create it yourself with the following command.

sudo snap alias dotnet-sdk.dotnet dotnet

[LexVocoder]

I understand the installer can't create the symlink, but popping up directions _in a dialog_ toward the end of the installation would really help.

[anirugu]

Same issue is happening in Ubuntu 20.04 for .net core 5.

[tristan957]

@anirugu refer to previous comments for a workaround

[JackTiber]

Adding on that this is not working for Ubuntu 20.04 fresh install, using the stable channel to install the 3.1 SDK. Happy to alias the command, but would definitely be nice to see that during the install rather than having to search for this issue.