Rider can't detect dotnet sdk

[heuristicAL]

even though the path is set to ~/.asdf/shims/dotnet, Rider says it cannot find the dotnet sdk. I don't know if this is something that others have encountered and if its even an asdf-dotnet-core issue

[s0kil]

@heuristicAL
You could fix this with: sudo ln -s ~/.asdf/shims/dotnet /usr/bin/dotnet
Linking the user-wide installation system-wide.

[heuristicAL]

Slight typo there, should be ln not ls :)

I also forgot to mention that I'm running on Macos so /usr/bin is blocked, even to sudo (Thanks Apple). I tried linking it to usr/local/bin JUST in case and no luck there.

Thanks for the suggestion though!

[s0kil]

@heuristicAL How did you overcome this issue?
I've tried to set the path manually, and so far no issues.

[s0kil]

However, I did encounter an issue with other tools not being able to find dotnet due to DOTNET_ROOT environment not set.
Turns out sourcing $HOME/.asdf/plugins/dotnet-core/set-dotnet-home.bash in .bashrc does not do anything, so I've manually set it as:

export DOTNET_ROOT
DOTNET_ROOT="$(asdf where dotnet-core)"

[heuristicAL]

So setting the vsersion of dotnet manually worked but that seems.... not ideal? Since we aren't actually using asdf to set the version for Rider.
Good enough for now though!

I personally did not have any problems using the set-dotnet-home script, although I use zsh, not bash. Are you sure you're using it correctly? I did not source it, I just used executed it like they say to do in the readme:
the first . is improtant: . ~/.asdf/plugins/dotnet/set-dotnet-home.zsh

[sarvasana]

I think Rider searches for MSBuild in the path that contains dotnet and it cannot find it there.
Would be nice if Rider would use the output from dotnet --info or something like that to find MSBuild instead.

Created ticket with JetBrains:
https://youtrack.jetbrains.com/issue/RIDER-56411

❯ sudo ln -s ~/.asdf/shims/dotnet /usr/bin/dotnet
❯ which dotnet
/usr/bin/dotnet
❯ dotnet --info
.NET SDK (reflecting any global.json):
 Version:   5.0.101
 Commit:    d05174dc5a

Runtime Environment:
 OS Name:     manjaro
 OS Version:  
 OS Platform: Linux
 RID:         linux-x64
 Base Path:   /home/kris/.asdf/installs/dotnet-core/5.0.101/sdk/5.0.101/

Host (useful for support):
  Version: 5.0.1
  Commit:  b02e13abab

.NET SDKs installed:
  5.0.101 [/home/kris/.asdf/installs/dotnet-core/5.0.101/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 5.0.1 [/home/kris/.asdf/installs/dotnet-core/5.0.101/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 5.0.1 [/home/kris/.asdf/installs/dotnet-core/5.0.101/shared/Microsoft.NETCore.App]

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

[mfilippov]

Yes, Rider try to detect SDK in folder contains dotnet binary. I will try to fix it.

[thewoolleyman]

Yes, Rider try to detect SDK in folder contains dotnet binary. I will try to fix it.

@mfilippov 👋 Any progress on this? It is still an open bug: https://youtrack.jetbrains.com/issue/RIDER-56411

[sarvasana]

The issue got related to another issue at jetbrains.

[mfilippov]

@thewoolleyman I hope to fix it in the Rider 2020.2 scope.

[sarvasana]

Replicating my comment from Jetbrains Ticket here:

Since then I have come to believe that dotnet and asdf are not compatible with each other and that this problem is not caused by Jetbrains Rider.

The recommend location to install dotnet to is:
/usr/share/dotnet

The recommend location to symlink to is:
/usr/bin/dotnet

To quickly install both LTS and Current is:

curl -sSL https://dot.net/v1/dotnet-install.sh | sudo bash /dev/stdin -c LTS --install-dir /usr/share/dotnet
curl -sSL https://dot.net/v1/dotnet-install.sh | sudo bash /dev/stdin -c Current --install-dir /usr/share/dotnet
sudo ln -sf /usr/share/dotnet/dotnet /usr/bin/dotnet

When I installed dotnet outside the recommended location, I always got errors with some MSBuild scripts.
This convinced me it is better to install at the recommended location.

Example errors:

• MSBuild.Sdk.SqlProj could not find dotnet
• Microsoft.Azure.WebJobs.Script.ExtensionsMetadataGenerator.targets(37, 5): Metadata generation failed. Exit code: '134' Error: 'No usable version of the libssl was found'

Maybe it would work if asdf would have some kind of post-version-switch-hook that symlinks to /usr/bin/dotnet instead.
But even then I think some MSBuild scripts simply expect dotnet to be found at /usr/share/dotnet/

I still think dotnet --info reveals the correct location of msbuild.

❯ dotnet --info

.NET Core SDK (reflecting any global.json):
 Version:   3.1.408
 Commit:    88530ea5c9

Runtime Environment:
 OS Name:     manjaro
 OS Version:  
 OS Platform: Linux
 RID:         linux-x64
 Base Path:   /home/kris/.asdf/installs/dotnet-core/3.1.408/sdk/3.1.408/

Host (useful for support):
  Version: 3.1.14
  Commit:  826c2c2f8f

.NET Core SDKs installed:
  3.1.408 [/home/kris/.asdf/installs/dotnet-core/3.1.408/sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.App 3.1.14 [/home/kris/.asdf/installs/dotnet-core/3.1.408/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 3.1.14 [/home/kris/.asdf/installs/dotnet-core/3.1.408/shared/Microsoft.NETCore.App]

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

[thewoolleyman]

My response on the Jetbrains issue:

Since then I have come to believe that dotnet and asdf are not compatible with each other and that this problem is not caused by Jetbrains Rider.

I don't think this is true. asdf is working perfectly fine to manage my dotnet environment in every other situation. This issue with Jetbrains Rider is the only problem I have encountered.

To quickly install both LTS and Current is:

curl -sSL https://dot.net/v1/dotnet-install.sh | sudo bash /dev/stdin -c LTS --install-dir /usr/share/dotnet

Manually installing to a hardcoded location is not a viable option, if you need to frequently switch between multiple projects which use different versions of the dotnet toolset.

This is not an issue for other asdf plugins under Jetbrains. For example, RubyMine handles multiple ruby versions via asdf just fine, and WebStorm handles nodejs versions just fine as well. I'm sure the same is true for other ecosystems such as python and java.

Bottom line, since I can run dotnet apps fine via the command line with an asdf-managed version of dotnet, I don't see any reason Rider shouldn't be able to support this as well.

[sarvasana]

Lets keep the discussion going at Jetbrains.
I think I agree with you after all.

I will test with asdf to see if the errors I mentioned are also there when using just the CLI.

MSBuild.Sdk.SqlProj could not find dotnet
Microsoft.Azure.WebJobs.Script.ExtensionsMetadataGenerator.targets(37, 5): Metadata generation failed. Exit code: '134' Error: 'No usable version of the libssl was found'

[sarvasana]

JetBrains says: "Fixed in Branch"

🥳

[sarvasana]

Please test with Rider Next EAP 2021.2.

[mfilippov]

Rider EAP1 shipped this week.

[sarvasana]

I will test today!

[sarvasana]

I did some tests and the results look promising.
Rider does not respect a .tool-versions file however.
You can read here:
https://youtrack.jetbrains.com/issue/RIDER-56411#focus=Comments-27-4934009.0-0

I would like to invite others to test this as well.
We have JetBrain's attention, so now is the time.

[matheus-santos-bonifacio]

I have the same trouble, but I change the default location of sdk path with dotnet MSBuild variable DOTNET_MSBUILD_SDK_RESOLVER_SDKS_DIR (the version too, here is the sdk which will use) to sdk folder inside the dotnet folder, this solved but after I got another error, now he can't find the target compile Microsoft.NET.Sdk/Sdk dir in sdk folder, he says that don't exist, I look if have this folder, but I not found, someone know how to have this folder?

[JamesMcMahon]

Jetbrains has since marked https://youtrack.jetbrains.com/issue/RIDER-56411 as fixed but looking through the thread I still unsure on how to go about setting up Rider to work with ASDF.

Anyone have specific steps?

[sarvasana]

To be honest...is there really a use case for using asdf to manage dotnet? I mean...using just dotnet, you can run multiple sdks on your machine, have projects target specific framework versions and nuget packages. I don't see what asdf could bring to the table.

[JamesMcMahon]

I think so,

• It documents and standardized project setup across machines
• It avoids package bloat on the OS's main package manager

You question is less, is ASDF useful with .NET, more is it useful with anything, because it's possible to install multiple Node, JDK, Python, etc versions. In my use case, I would say yes.

[sarvasana]

I don't agree. Other languages work differently from dotnet. There asdf does make sense.

[FiretronP75]

Rider still can't find it on Linux, even after I give it the path to it in the settings. It says "Check that .NET Core SDK is installed in '/usr/bin'. " But .Net installs to '/usr/share/dotnet/sdk' by default currently. I entered the correct path in the Toolset and Build settings. But it still says "Check that .NET Core SDK is installed in '/usr/bin'. "

[fmflurry]

However, I did encounter an issue with other tools not being able to find dotnet due to DOTNET_ROOT environment not set. Turns out sourcing $HOME/.asdf/plugins/dotnet-core/set-dotnet-home.bash in .bashrc does not do anything, so I've manually set it as:

export DOTNET_ROOT
DOTNET_ROOT="$(asdf where dotnet-core)"

Global tools execution was failing because it couldn't find .NET location, I'm so happy you wrote this comment. You saved me from headache.