Code Review Videos > How I Fixed > How I Fixed: No frameworks were found in JetBrains Rider

How I Fixed: No frameworks were found in JetBrains Rider

by

When switching from Dot Net 6 to Dot Net 7 on Ubuntu, I found that the Dot Net manual installation process went fine, but JetBrains Rider was less than happy with the result.

After upgrading, and changing my project to build for Net7, I got the following error when trying to run the project in development mode:

/home/chris/RiderProjects/LinkVisitorCSharp/LinkVisitorCSharp/bin/Debug/net7.0/LinkVisitorCSharp
You must install or update .NET to run this application.

App: /home/chris/RiderProjects/LinkVisitorCSharp/LinkVisitorCSharp/bin/Debug/net7.0/LinkVisitorCSharp
Architecture: x64
Framework: 'Microsoft.NETCore.App', version '7.0.0' (x64)
.NET location: /usr/lib/dotnet

No frameworks were found.

Learn about framework resolution:
https://aka.ms/dotnet/app-launch-failed

To install missing framework, download:
https://aka.ms/dotnet-core-applaunch?framework=Microsoft.NETCore.App&framework_version=7.0.0&arch=x64&rid=ubuntu.22.04-x64

Process finished with exit code 150.Code language: Shell Session (shell)

As a relative beginner to Dot Net, this kinda threw me for six.

What’s happening here – as best I understand it – is that the program does build. That’s because Rider has been able to use the Dot Net Framework to build the project:

Framework: 'Microsoft.NETCore.App', version '7.0.0' (x64)Code language: JavaScript (javascript)

However, in order to run your compiled Dot Net applications, you need the corresponding runtime.

So above you need both the SDK 7.0.102, and one of the runtimes. For Ubuntu the one I installed was the ASP.NET Core Runtime 7.0.2.

This could then be validated as such:

dotnet --info


.NET SDK:
 Version:   7.0.102
 Commit:    4bbdd14480

Runtime Environment:
 OS Name:     ubuntu
 OS Version:  22.04
 OS Platform: Linux
 RID:         ubuntu.22.04-x64
 Base Path:   /usr/share/dotnet/sdk/7.0.102/

Host:
  Version:      7.0.2
  Architecture: x64
  Commit:       d037e070eb

.NET SDKs installed:
  7.0.102 [/usr/share/dotnet/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 7.0.2 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 7.0.2 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

Other architectures found:
  None

Environment variables:
  DOTNET_ROOT       [/home/chris/.dotnet]

global.json file:
  Not found

Learn more:
  https://aka.ms/dotnet/info

Download .NET:
  https://aka.ms/dotnet/downloadCode language: Shell Session (shell)

Which looks like everything is good.

Indeed, I could run apps using /usr/share/dotnet/dotnet – and that was why things got confusing. Because if I tried to run apps from inside Rider, I was getting this:

/home/chris/RiderProjects/LinkVisitorCSharp/LinkVisitorCSharp/bin/Debug/net7.0/LinkVisitorCSharp
You must install or update .NET to run this application.

App: /home/chris/RiderProjects/LinkVisitorCSharp/LinkVisitorCSharp/bin/Debug/net7.0/LinkVisitorCSharp
Architecture: x64
Framework: 'Microsoft.NETCore.App', version '7.0.0' (x64)
.NET location: /usr/lib/dotnet

No frameworks were found.

Learn about framework resolution:
https://aka.ms/dotnet/app-launch-failed

To install missing framework, download:
https://aka.ms/dotnet-core-applaunch?framework=Microsoft.NETCore.App&framework_version=7.0.0&arch=x64&rid=ubuntu.22.04-x64

Process finished with exit code 150.Code language: Shell Session (shell)

The strange thing, from my point of view, is that the dotnet --info command doesn’t list the frameworks (that I can see?) – so it was hard to know what, if any, frameworks I actually had installed.

But surely I had something installed, or running from the command line shouldn’t have worked:

cd /home/chris/RiderProjects/LinkVisitorCSharp/LinkVisitorCSharp/

➜  LinkVisitorCSharp dotnet run LinkVisitorCSharp
args
System.String[]
[
  {
    "url": "LinkVisitorCSharp",
    "status": -1,
    "statusText": "Invalid URL",
    "ok": false,
    "redirected": false,
    "headers": {}
  }
]
Code language: Shell Session (shell)

That was actually pretty useful in figuring out, because that implied the problem was with Rider, not with my system as a whole.

The Fix (Errr… workaround)

As best I can tell, this is a pathing issue. As in, something to do with my user’s $PATH.

However, this fix works around this.

The Dot Net installation instructions for Ubuntu have me running two commands:

tar zxf dotnet-runtime-7.0.2-linux-x64.tar.gz -C $HOME/.dotnet
tar zxf aspnetcore-runtime-7.0.2-linux-x64.tar.gz -C $HOME/.dotnetCode language: PHP (php)

And that ties up to the info output by the dotnet --info command:

Environment variables:
  DOTNET_ROOT       [/home/chris/.dotnet]Code language: JavaScript (javascript)

But Rider looks elsewhere. Not sure why, or how to change that – I’m sure it’s possible, but I couldn’t figure it out.

Rider looks at:

/usr/lib/dotnet

So the fix is pretty straightforward.

Copy the contents of $HOME/.dotnet to /usr/lib/dotnet.

/usr/lib/dotnet# ls

3.1.300.aspNetCertificateSentinel               5.0.401_IsDockerContainer.dotnetUserLevelCache  7.0.102_MachineId.dotnetUserLevelCache
3.1.300.dotnetFirstUseSentinel                  5.0.401_MachineId.dotnetUserLevelCache          7.0.102.toolpath.sentinel
3.1.300_IsDockerContainer.dotnetUserLevelCache  5.0.401.toolpath.sentinel                       corefx
3.1.300_MachineId.dotnetUserLevelCache          5.0.402.aspNetCertificateSentinel               dotnet
3.1.300.toolpath.sentinel                       5.0.402.dotnetFirstUseSentinel                  host
3.1.301.aspNetCertificateSentinel               5.0.402_IsDockerContainer.dotnetUserLevelCache  LICENSE.txt
3.1.301.dotnetFirstUseSentinel                  5.0.402_MachineId.dotnetUserLevelCache          MachineId.v1.dotnetUserLevelCache
3.1.301_IsDockerContainer.dotnetUserLevelCache  5.0.402.toolpath.sentinel                       optimizationdata
3.1.301_MachineId.dotnetUserLevelCache          6.0.110.aspNetCertificateSentinel               packs
3.1.301.toolpath.sentinel                       6.0.110.dotnetFirstUseSentinel                  sdk
5.0.400.aspNetCertificateSentinel               6.0.110.toolpath.sentinel                       sdk-advertising
5.0.400.dotnetFirstUseSentinel                  6.0.111.aspNetCertificateSentinel               sdk-manifests
5.0.400_IsDockerContainer.dotnetUserLevelCache  6.0.111.dotnetFirstUseSentinel                  shared
5.0.400_MachineId.dotnetUserLevelCache          6.0.111.toolpath.sentinel                       TelemetryStorageService
5.0.400.toolpath.sentinel                       7.0.102.aspNetCertificateSentinel               templates
5.0.401.aspNetCertificateSentinel               7.0.102.dotnetFirstUseSentinel                  ThirdPartyNotices.txt
5.0.401.dotnetFirstUseSentinel                  7.0.102_IsDockerContainer.dotnetUserLevelCacheCode language: PHP (php)

And that fixes it.

Additional Info

One extra step I took in figuring this out (I haven’t figured it out, I’ve found a hacky workaround), was to remove everything starting with a number from the /usr/lib/dotnet dir.

When I did this, I guess I broke everything, but I did get a telling error:

/home/chris/RiderProjects/LinkVisitorCSharp/LinkVisitorCSharp/bin/Debug/net5.0/LinkVisitorCSharp
A fatal error occurred. The required library libhostfxr.so could not be found.
If this is a self-contained application, that library should exist in [/home/chris/RiderProjects/LinkVisitorCSharp/LinkVisitorCSharp/bin/Debug/net5.0/].
If this is a framework-dependent application, install the runtime in the global location [/usr/lib/dotnet] or use the DOTNET_ROOT environment variable to specify the runtime location or register the runtime location in [/etc/dotnet/install_location].

The .NET runtime can be found at:
  - https://aka.ms/dotnet-core-applaunch?missing_runtime=true&arch=x64&rid=ubuntu.22.04-x64&apphost_version=5.0.17

Process finished with exit code 131.Code language: Shell Session (shell)

There’s three bits of useful info there:

  • install the runtime in the global location [/usr/lib/dotnet]
  • use the DOTNET_ROOT environment variable to specify the runtime location
  • register the runtime location in [/etc/dotnet/install_location]

I guess Rider is using the global location.

I thought I had set the DOTNET_ROOT environment variable – and as above it does output as expected when running dotnet --info.

But that third one was new to me:

cat /etc/dotnet/install_location

/usr/lib/dotnetCode language: Shell Session (shell)

I’ve included my info here in the hope it helps someone.

I’ll be honest, my arrival at a working solution was a fluke. But hey, it works.

3 thoughts on “How I Fixed: No frameworks were found in JetBrains Rider”

  1. Hi, I got the same issue, I solved it by fixing PATH AND DOTNET_ROOT in .zshrc, turned out my main console used bash and bashrc, but rider used zsh and zshrc, therefore Rider couldn’t find dotnet in PATH

    Reply

    • Nice… that had not occurred to me. And tbh I know I switched to another dot net project a few months later and hit on different issues, and I bet this would have been part or all of it. Thanks for sharing!

      Reply

    • To follow up on this, it seems there is an option in the Rider settings to control this. Mine was automatically set to my default terminal – zsh.

      jetbrains rider terminal settings

      Reply

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.