Package Details: rider 1:2018.2.3-1

Git Clone URL: https://aur.archlinux.org/rider.git (read-only)
Package Base: rider
Description: A cross-platform C# IDE by JetBrains.
Upstream URL: https://www.jetbrains.com/rider/
Keywords: .NET ASP.NET C# editor F# IDE Jetbrains Unity VB.NET Xamarin
Licenses: Commercial
Conflicts: rider
Provides: rider
Submitter: tim.hellhake
Maintainer: tim.hellhake
Last Packager: tim.hellhake
Votes: 20
Popularity: 0.286736
First Submitted: 2017-08-06 22:00
Last Updated: 2018-09-14 11:51

Dependencies (2)

Required by (0)

Sources (2)

Latest Comments

1 2 3 Next › Last »

beanaroo commented on 2018-11-11 04:16

Thanks for maintaining this, @tim.hellhake!

I'd like to request the .desktop file to use Icon=rider instead of an absolute path. This allows the theme icon to be used (like for IntelliJ and Pycharm).

I believe this will also require copying the included icon to the system icons path. i.e.

  install -D -m644 "$pkgdir"/opt/$pkgbase/bin/rider.png "$pkgdir"/usr/share/pixmaps/"$pkgname".png

joalcava commented on 2018-05-11 16:01

@pulsar256 Thank you! I was having the same issue on fedora 28 and that fixed it for me.

tomwadley commented on 2018-04-27 16:38

@pulsar256 Thank you! Starting rider with TERM=xterm fixes it. I can debug again! And thanks for your help too @Lyynx92 - I hadn't seen that VSCode wiki page.

pulsar256 commented on 2018-04-27 12:32

@tomwadley, @Lyynx92

TLDR; - in Rider: tools->create command-line launcher - Close Rider - in a terminal: ᐅ TERM=xterm /usr/local/bin/rider

I did run into the same issue today. I could solve the issue on my end by setting $TERM to xterm. IIRC there was an ncurses update a couple of months ago which effectively changed the default TERM environment variable from xterm to xterm-256color. I might be wrong about that, but what I can confirm is that setting it back to xterm solves the issue on my end.

AFAIK You could also modify the .desktop launcher file if you do not want to fiddle with the environment variables passed to your desktop session of your choice as it might not always be trivial.

Google xterm-256color and gradle to get a bit background on that, they had/have a similar issue.

Lyynx92 commented on 2018-04-23 00:30

Can also try ICU55 and 60, as I had those installed around the same time and I do know that VSCode requires ICU55 for C# debugging (as per the archwiki).

tomwadley commented on 2018-04-20 20:30

Sorry I forgot to reply to this. Like @luisantoniojr is experiencing, installing icu57 did not fix this for me either (and I also have a Debian Virtual Box which I'm using for debugging right now!). @Lyynx92, can you think of anything else you did or installed that could have fixed this for you? I'll owe you a beer if you can solve this :)

luisantoniojr commented on 2018-04-20 20:00

I'm having the same problem as @tomwadley described, i already installed icu57 as @Lyynx92 suggested, the problem persists. Happens on Manjaro and Antergos distributions. I downloaded the Rider 2018.1 version, extracted and executed, found the same problem. Already tested on distribution not based on Arch, executed smoothly. All tests was maded inside virtualbox.

Lyynx92 commented on 2018-04-11 19:32

@tomwadley, I was running into that issue as well. Installing icu57 from the AUR fixed it for me.

tomwadley commented on 2018-03-29 15:46

Is anyone else having trouble using the debugger inside Rider? It did work at some point. But recently, when I click debug, it just sits there saying "Pending" and eventually pops up the error "Debugger worker was not initialized within 100000 ms". I've tried starting a fresh project, blowing away my Rider config and switching to the EAP build of Rider. If another Arch user can confirm that the debugger works for them, that would help be narrow down this issue.

ShalokShalom commented on 2018-02-02 11:37

Its a CLR IDE now: F# and VB support is added since years. Will you correct this? Thanks