Using Rider under Linux: prerequisites

hi,

dnx is already deprecated & replaced with .net cli - so should rider work with .net cli too?

I'm running Ubuntu 16.04 with latest Mono (4.2.1) and .NET Core 1.1. When I try to open up a basic hello world project, I get the following:

Project 'helloworld' load failed
The lifetime has already been terminated.
Object name: 'Lifetime'.

Project 'helloworld' load failed: Can't connect to MsBuild project model process in 600000 ms

Any ideas on what the issue/solution could be?

@Brandon, You may try to update mono to 4.8 or 5.0, if it will not help, then zip and submit somewhere all logs from Help->Show log in Files folder. Follow up here.

Hi, I'm using Ubuntu 16.04 and I've installed Mono (5.2) and .NET (2.0). I created the sample shown here http://www.mono-project.com/docs/getting-started/mono-basics/#winforms-hello-world to verify that Mono is working.

I can run the application from the command line as the instructions say. But when I open the file in Rider 'Forms' in 'using System.Windows.Forms;' is red (and everything depending on it). Obviously I can not run the program from Rider and get the error: Program.cs(2, 22): [CS0234] The type or namespace name 'Forms' does not exist in the namespace 'System.Windows' (are you missing an assembly reference?).

What do I have to do to make Rider pick up the red parts? 

I have Ubuntu 18 running in a VirtualBox. Installed dot net core as shown under prerequisites link. Logged in to Ubuntu as root. When I run the ./rider.sh, It returns "Killed". I don't see that message in the .sh file... Linux newb. Any ideas?

EDIT: Problem was allocated memory in VirtualBox. Bumped to 6Gb and all is good.

On Linux Rider does not detect dot net core even though it is installed. Mono is detected. How does Rider find the dot net installation? The CLI tools are on my path and work just fine from the command line. I have looked and looked but I can't find any information or configuration settings that I can configure to make this work.

Thanks

@Richard, does it work if you manually set dotnet path in Rider settings?

@Ivan

Thanks for pointing that out. I was able to get things working with that information. It should be noted that Rider seems to be making some assumptions about the path where the dotnet executable is found at. In my case the executable in the /usr/bin directory is actually a shell script that sets up the environment before calling the real dotnet executable /opt/dotnet/dotnet . You have to point the configuration at the real dotnet executable or Rider will not find the SDK or runtime. I would think this would be more portable if Rider just ran "dotnet --list-sdks" to find the install SDKs and "dotnet --list-runtimes" verses making assumptions about how dot net is installed on the host systems. This is especially true of Linux distros which may move things around or like in my case use a wrapper script that makes things easy from the command line but not so easy for Rider to make assumptions about file system layout.

Again thanks I have things working now.

@Richard

We try to find dotnet in path and use it as a first choice. Why did you made such a thing with an executable in the /usr/bin directory? Is there recommendations to do things this way? Could you share with us? How common is this approach? It may also help, if you share the whole wrapper script (somewhere in gist). Thanks!

It is standard on all the linux distros ive used dotnet core on to have a shell script at /usr/bin/dotnet which then runs the actual executable /opt/dotnet/dotnet

/opt/dotnet is not on the path

I am having the same issue as @Leecannon.

Here is an example of /usr/bin/dotnet:

```

$ cat /usr/bin/dotnet
#!/bin/sh

export DOTNET_ROOT=/opt/dotnet
exec /opt/dotnet/dotnet "$@"

$ cat /usr/bin/msbuild
#!/bin/sh
MONO_GC_PARAMS="nursery-size=64m,$MONO_GC_PARAMS" exec /usr/bin/mono $MONO_OPTIONS /usr/lib/mono/msbuild/15.0/bin/MSBuild.dll "$@"

```

OS: ArchLinux

@Patrick

I'm on Arch as well and if you scroll up a few comments you will find the clues you need to fix this but the steps are:

1. In Settings -> Build, Execution, Deployment -> Toolset and Build -- Set .NET Core CLI executable path: Custom then /opt/dotnet/dotnet

Another issue you will have relates to msbuild the mono version of msbuild does not work in all cases with dotnet core. I don't remember off the top of my head where those failures are but to fix it you need to use the dotnet core version of msbuild which was included when you installed dotnet core. You can leave mono msbuild installed if you want just know that if you do you will have to call each explicitly depending on what you are building. I personally have a script file in ~/bin/msbuild which contains:

#!/bin/sh

exec /usr/bin/dotnet msbuild "$@"

where /usr/bin/dotnet is the script that sets things up for dotnet core and executes /opt/dotnet/dotnet

Then I have ~/bin first in my path so the msbuild that I have defined is found first. After doing that things have worked as expected in Rider.

Oh on the command line after you have that script defined and in your path correctly when you run it the out put will be :

Microsoft (R) Build Engine version 15.9.20.63311 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

Don't forget depending on how you are launching Rider you may need to logout/login so that your new path will be seen. Or if you are launching rider from a script you could just change/alter the path for rider then restart it.

@Richard thanks for your feedback!

As reference, here are the settings that seem to work with C# and F# on linux:

The previous mentioned workaround doesn't seem to apply to the newest .NET SDK anymore.

I now have the error:

The current .NET SDK does not support targeting .NET Core 2.2. Either target .NET Core 2.1 or lower, or use a version of the .NET SDK that supports .NET Core 2.2. at (137:5)

Arch Linux updated dotnet a few days ago. Current versions are:

$ dotnet --info 
.NET Core SDK (reflecting any global.json):
Version: 2.2.105
Commit: 7cecb35b92

Runtime Environment:
OS Name: arch
OS Version:
OS Platform: Linux
RID: arch-x64
Base Path: /opt/dotnet/sdk/2.2.105/

Host (useful for support):
Version: 2.2.3
Commit: 6b8ad509b6

.NET Core SDKs installed:
2.2.105 [/opt/dotnet/sdk]

.NET Core runtimes installed:
Microsoft.NETCore.App 2.2.3 [/opt/dotnet/shared/Microsoft.NETCore.App]

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

Any pointers?

Here are the relevant changes:

[2019-03-18 07:49] [ALPM] upgraded dotnet-host (2.2.1+102-1 -> 2.2.3+105-1)
[2019-03-18 07:49] [ALPM] upgraded dotnet-runtime (2.2.1+102-1 -> 2.2.3+105-1)
[2019-03-18 07:49] [ALPM] upgraded dotnet-sdk (2.2.1+102-1 -> 2.2.3+105-1)

@Ivan

If installing the .NET Core SDK using Microsoft's official Snap package on Ubuntu or other supporting Linux distros, Rider fails to auto detect the installation. By default, due to the way Snaps work, the command for dotnet is dotnet-sdk.dotnet, though this can be aliased to the usual plain dotnet with sudo snap alias dotnet-sdk.dotnet dotnet. 

Anyway, the dotnet CLI is installed in the following directory: /snap/dotnet-sdk/current/ and once this is set MSBuild is also auto-detected

@Paul, I have added a request for snap dotnet cli autodetect https://youtrack.jetbrains.com/issue/RIDER-27491

@Ivan, thanks!

How about dotnet core 3.0? I've done 2.2, and it worked fine, but I'm having trouble configuring Rider to use the 3.0 libraries. I have it installed via snap in Ubuntu 19.04, as described here: https://github.com/dotnet/core/blob/master/release-notes/3.0/preview/3.0.0-preview6.md

@Ifaako-5 have you ever solved the Winforms references being all red?

Is it possible to use Rider on Linux for a .NET Framework version 4 project?

Everything I've searched for says I have to install the .NET Framework version 4 using Wine.

When I load a project I've inherited I see: The reference assemblies for .NETFramework,Version=v4.0 were not found. 

What am I missing?

What's the point of Rider on Linux if it doesn't "just work".

I've installed Mono, dotnet core 3.0.  How do I get this last component?

Russell Robinson if you already have mono, try to open your project. If it fails, check what Build Tool is configured to be used in Rider - should be mono msbuild.

Ivan Shakhov I have a similar issue to @..., in detecting mono vs dotnet for run configuration. It always defaults to mono as the first choice for any .net executable file, regardless of the toolset settings correct dotnet path. I need to configure the run configuration to be run/built against dotnet and not mono for specific projects. Is there any work around for this?

I think we have discussed run configuration case with you on discord and found the solution to use Native Executable run configuration instead.

Yes, this message was for before. But, again, you haven't still come back to me to explain why it defaults to mono anyway, as it should be based on users' choice if they wish to use dotnet instead - specially for mono-incompatible .net executables.

Edit: After our conversation we agreed that the use-case prepending dotnet instead of mono is rare and once this situation changes as .net is moving to .net core 3 and .net 5, then there's more to think and discuss, so for now this seems to be non-issue.

I'm having a similar issue only with mono and macOS.  I used 'brew' package management to install mono 5.18 on my system and even though it manages to find msbuild and mono locations it cannot seem to find *any* of the .dlls (System, System.Core, System.Data, etc). I took a snapshot of the settings:

The libraries are there, here they are:
/usr/local/lib/mono/4.6.2-api
Js-Mac:4.6.2-api jfreyensee$ ls
Accessibility.dll System.Json.dll
Commons.Xml.Relaxng.dll System.Management.dll
CustomMarshalers.dll System.Messaging.dll
Facades System.Net.Http.Formatting.dll
I18N.CJK.dll System.Net.Http.WebRequest.dll
I18N.MidEast.dll System.Net.Http.dll
I18N.Other.dll System.Net.dll
I18N.Rare.dll System.Numerics.Vectors.dll
I18N.West.dll System.Numerics.dll
I18N.dll System.Reactive.Core.dll
IBM.Data.DB2.dll System.Reactive.Debugger.dll
ICSharpCode.SharpZipLib.dll System.Reactive.Experimental.dll
Microsoft.Build.Engine.dll System.Reactive.Interfaces.dll
Microsoft.Build.Framework.dll System.Reactive.Linq.dll
Microsoft.Build.Tasks.v4.0.dll System.Reactive.Observable.Aliases.dll
Microsoft.Build.Utilities.v4.0.dll System.Reactive.PlatformServices.dll
Microsoft.Build.dll System.Reactive.Providers.dll
Microsoft.CSharp.dll System.Reactive.Runtime.Remoting.dll
Microsoft.VisualBasic.dll System.Reactive.Windows.Forms.dll
Microsoft.VisualC.dll System.Reactive.Windows.Threading.dll
Microsoft.Web.Infrastructure.dll System.Reflection.Context.dll
Mono.C5.dll System.Runtime.Caching.dll
.

.

.

@Jay Freyensee Please report a new issue with Help->Report a Bug in Rider and agree to attach logs. I believe we would be able to help.

Fedora 32.
Both .NET Core and Xamarin are not detected.
My settings:

these settings produce the same outcome:

https://youtrack.jetbrains.com/issue/RIDER-48882?clearDraft=true&description=Version:%20RD-201.8538.1Timezone:%20Europe%2FBerlinEvaluation:%20trueEnvironment:%20RD-201.8538.1,%20JRE%2011.0.7%2010-b765.64x64%20JetBrains%20s.r.o.,%20OS%20Linux(amd64)%20v5.6.11-300.fc32.x86_64,%20screens%201920x1080.NET%20Core%203.1.3Logs:%20https:%2F%2Fdotnet-ea.services.jetbrains.com%2Ffiles%2Fso-attachments%2Fb9a7ffd8-a5dc-4e3c-95cc-51a000cb6937%2Frider-logs-attachment.tar.xz&c=Affected%20versions%202020.1.4%20(201.8538.1)

I cannot get Rider to recognize dotnet core. I have tried both 3.1 and 5.0 of the sdk and restarted multiple times but it cannot be auto detected nor do I have the capability to add the path manually

I find it super bizarre that there is no documentation or support beyond this page to get this set up on Linux.

Visual Studio Code works just fine right away.

Dasper, would you mind submitting a bug report with Help->Report a Bug and agree to attach logs?

Same exact issue as Dasper. Running on Ubuntu 20.04 with .net 3.1 installed via apt (ms apt repo). It would be nice to be able to at least manually enter these paths. Any workarounds available?