asdf-dotnet-core
asdf-dotnet-core copied to clipboard
Rider can't detect dotnet sdk
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
@heuristicAL
You could fix this with: sudo ln -s ~/.asdf/shims/dotnet /usr/bin/dotnet
Linking the user-wide installation system-wide.
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!
@heuristicAL How did you overcome this issue? I've tried to set the path manually, and so far no issues.
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)"
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
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
Yes, Rider try to detect SDK in folder contains dotnet binary. I will try to fix it.
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
The issue got related to another issue at jetbrains.
@thewoolleyman I hope to fix it in the Rider 2020.2 scope.
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
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.
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'
JetBrains says: "Fixed in Branch"
🥳
Please test with Rider Next EAP 2021.2.
Rider EAP1 shipped this week.
I will test today!
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.
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?
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?
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.
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.
I don't agree. Other languages work differently from dotnet. There asdf
does make sense.