News for hackers. Stuff that matters.
Re:C# Pattern Matching by S_A_P on Tuesday February 04, 2020 @03:59PM (#22240891)
Resharper has proven to be a great way for me to start learning and integrating new language features. I code in my original style and resharper suggests changes based on new features like pattern matching. At first I didnt see the benefit, but this is a hugely powerful feature once you start to wrap your mind around it.
Re:C# Pattern Matching by jcpst on Tuesday February 04, 2020 @06:55PM (#22242488)
I have clocked in way more hours in Rider than VS. I can flawlessly run and debug our decades old monolith with 40-50 projects and millions LOC, containing C#, VB, Web Forms, WPF, files with 80k lines...

And all of our .NET Core services on MacOS, with all my unix-y tooling.

There is “VS for Mac”, but it’s not really VS. It’s Xamarin Studio rebranded.

Rider works excellent on my Linux box at home as well, where the alternatives are MonoDevelop and Omnisharp + text editor.

Re:C# Pattern Matching by pjmlp on Wednesday February 05, 2020 @06:54AM (#22245973)
> There is “VS for Mac”, but it’s not really VS. It’s Xamarin Studio rebranded.

This was only true for the first releases, they have been integrating common code from VS and this is one of the reasons why VS moved away from COM plugins into a .NET ones.

https://visualstudio.microsoft.com/vs/mac/event/

Re:C# Pattern Matching by q-base on Wednesday February 05, 2020 @01:24AM (#22244468)
I have actually also switched more or less to only using Ubuntu, but have been using VS Code. It has become quite powerful in my book and I like that it is the same environment I use across React Native and C#. But I may have to have a little look at Rider then.
Re:C# Pattern Matching by stult on Wednesday February 05, 2020 @12:12AM (#22244221)
My only complaint is I can’t ignore auto-gen’d code like EF migrations in dotCover, so my unit test coverage looks terrible. It doesn’t help that I write terrible unit tests, but still!
Re:C# Pattern Matching by mtone on Wednesday February 05, 2020 @01:38AM (#22244535)
I run a little powershell script on build that adds the [System.Diagnostics.CodeAnalysis.ExcludeFromCodeCoverage] attribute to generated classes in certain folders.

https://gist.github.com/mtone/aded2ff636cb6dd9d428cf5800f344...

Funnily, I have no clue how to setup a build script in Rider, did that in VS (Rider do run it).

Re:C# Pattern Matching by stult on Wednesday February 05, 2020 @09:46AM (#22247044)
Holy crap you've made my job infinitely easier. Thank you!
Re:C# Pattern Matching by tucaz on Tuesday February 04, 2020 @08:54PM (#22243286)
I switched to Rider a few months ago but I still feel like I struggle with some things.

For some reason I can’t change the position of the debugger when running and aspnetcore app and make it go back so I always have to re-run whatever request I happen to be debugging. Does that happen to you?

It also seems like ReSharper had more tips and tricks going on when compared to Rider, but I can’t imagine that would be true.

Re:C# Pattern Matching by pbz on Tuesday February 04, 2020 @10:15PM (#22243693)
Dragging the current line arrow back (on the left side panel by the numbers) works for me; works in VS too btw
Re:C# Pattern Matching by flamtap on Tuesday February 04, 2020 @07:13PM (#22242633)
As a long-time ReSharper user, I’ve been meaning to give rider a close look for some time now. Unfortunately the last project I was on was heavy into WPF, and that was about the only box VS didn’t tick.

Any tips, tricks, or pitfalls to avoid making the switch from VS to Rider?

Re:C# Pattern Matching by emodendroket on Tuesday February 04, 2020 @07:52PM (#22242943)
I used VS for years before switching to Rider and honestly... just jump in, there's not much to know. If you've used ReSharper the features should seem pretty familiar.
Re:C# Pattern Matching by BigolJones on Wednesday February 05, 2020 @03:52AM (#22245100)
I've actually considered it, but didn't really bring myself on doing it. How is it in general? Why do you prefer Rider?
Re:C# Pattern Matching by emodendroket on Wednesday February 05, 2020 @09:07PM (#22252868)
It is snappier than VS+R# (and I can't bear to give up all the R# features), it supports emacs key bindings, it has (IMO anyway) much better support for ancillary stuff like directly issuing DB calls or interacting with source control, and I'm just used to the IntelliJ platform after using it for years.
Re:C# Pattern Matching by tucaz on Tuesday February 04, 2020 @08:55PM (#22243289)
What do you think is better in Rider? I’m using it myself for a few months now but feel like going back to VS all the time.
Re:C# Pattern Matching by paranoidrobot on Tuesday February 04, 2020 @11:24PM (#22244003)
I've moved my laptops/desktops over to Ubuntu from Windows.

Rider was what I thought I'd give a go, with the idea that if it was really terrible I'd fire up a VM with Windows and VS.

As someone who's used Visual Studio since VS 2002, and ReSharper since (probably) 2006 - moving to Rider was pretty much run and go.

There's a few minor differences, but the only one that bugged me was the regional formatting options for the debugger. I still havn't figured out how to set it to use ISO8601 or something like it for formatting dates/times, and instead it picks something based on my OS configuration.

Re:C# Pattern Matching by emodendroket on Wednesday February 05, 2020 @09:08PM (#22252872)
Repeating myself, but I like the key bindings and performance and find the support for VC and databases better.
Re:C# Pattern Matching by nwsm on Wednesday February 05, 2020 @02:44PM (#22250334)
VS for Mac doesn't even have an enterprise edition.
Re:C# Pattern Matching by keithnz on Tuesday February 04, 2020 @04:11PM (#22241010)
as an aside, if you got Rider as part of your resharper subscription, try it out, it is basically a drop in replacement for visual studio but faster and with many many little quality of life improvements you never knew you needed :)
Re:C# Pattern Matching by tablloyd on Tuesday February 04, 2020 @05:35PM (#22241837)
I've recently switched to Rider full time from VS, so far it's been a really good experience & has fixed the main issues that I was experiencing with VS.

I've found it quite problematic to reliably connect to private NuGet feeds though which is a bit of a pain.

Re:C# Pattern Matching by bob1029 on Tuesday February 04, 2020 @05:00PM (#22241493)
The spell checker is probably the single greatest feature in Rider. It works really well on composite type names. E.g. 'CustomerPreferences' would not get a squiggle under it for spelling, but 'CusomerPreferences' would. Performance is arguably better in most circumstances, but it doesn't support some of the bleeding edge .NET Core functionality as well as VS2019 does.
Re:C# Pattern Matching by keithnz on Tuesday February 04, 2020 @05:15PM (#22241641)
It also doesn't support some dried up crusty .NET functionality like webforms either (it compiles it fine, but doesn't have the code generation tools that VS has )
Re:C# Pattern Matching by emodendroket on Tuesday February 04, 2020 @07:52PM (#22242949)
Every release has more and more stuff though. Like they have added Windows Forms pretty recently.

Right now SSDT and some ancient Linq2Sql stuff is the only thing I still find myself needing VS for.

Re:C# Pattern Matching by SigmundA on Tuesday February 04, 2020 @05:15PM (#22241647)
Resharper spell checks in VS for me too.
Re:C# Pattern Matching by to11mtm on Tuesday February 04, 2020 @05:48PM (#22241943)
I started using Rider recently.

It's faster yes, but seems to be a bit more memory hungry out of the gate than VS+Resharper.

There is one HUGE thing I miss however - the Package Manager console. There's still a few things I have to do in there and thus have to switch back to VS.

Re:C# Pattern Matching by tigershark on Wednesday February 05, 2020 @02:29AM (#22244739)
VS is 32 bit, so instead of getting more memory when it needs it slows to a crawl and eventually crashes. I think that the early versions of VS are a bloodbath. VS 2019 just crawled with a small solution just because there were mixed C# and F# projects. I should remember to upgrade always after 2 or 3 minor revisions instead of being a guinea pig for MS. On the other hand some time ago I got a bug in rider where the F# code worked perfectly in VS but didn’t work at all in rider and until today I have rider highlighting some errors in perfectly valid c# code but the build is successful while for resharper that code is fine. And the biggest current pain that I have is that I cannot debug ny tests in VS but they work perfectly in rider. So for now I’m sticking to both of them until rider irons up some small wrinkles.
Re:C# Pattern Matching by peteri on Wednesday February 05, 2020 @08:18AM (#22246448)
Tests not running might be X86/X64 issue. Certainly nUnit will find the tests but not run them until you change the default architecture (Resharper will run them happily in VS).
Re:C# Pattern Matching by m_fayer on Tuesday February 04, 2020 @07:07PM (#22242580)
Definitely more memory hungry. But I see it as a good deal. I feed it all the memory it wants, it gives me stability, xplat, and an embarrassment of riches as far as features and conveniences. It's earned that memory.
Re:C# Pattern Matching by tablloyd on Wednesday February 05, 2020 @03:41AM (#22245043)
Theres a nuget & terminal tab across the bottom bar which combined offer the same functionality as the nuget package manager console.
Re:C# Pattern Matching by to11mtm on Friday February 07, 2020 @08:27PM (#22273036)
See my other reply. There's not 100% replication, there are some things you just plain can't do outside VS. =(
Re:C# Pattern Matching by eyegor on Tuesday February 04, 2020 @07:39PM (#22242858)
You can achieve this through nuget.exe from your hidden /.nuget directory iirc.
Re:C# Pattern Matching by to11mtm on Friday February 07, 2020 @08:26PM (#22273032)
Not everything.

I can't do the equivalent of

update-package -reinstall

A forced package restore doesn't quite do the same thing. (I'm really glad Rider has that feature though!)

Add-BindingRedirect (would be extra handy since Rider doesn't handle redirects at all [1])

[1] https://youtrack.jetbrains.com/issue/RIDER-5482

Re:C# Pattern Matching by brynjolf on Wednesday February 05, 2020 @02:09AM (#22244659)
For our 32 project solution, Rider is so awkwardly slow at startup and if you pull from master it just dies. Also it just loves to notify you about everything. I still prefer VS.
Re:C# Pattern Matching by qwerty456127 on Tuesday February 04, 2020 @05:53PM (#22241991)
> replacement for visual studio but faster

How can a IntelliJ Idea derivative written in Java be faster than VistalStudio which is native code? Both Idea and PyCharm work much slower than VisualStudio on my machine.

Re:C# Pattern Matching by GordonS on Tuesday February 04, 2020 @06:38PM (#22242360)
At least for me, Rider is definitely faster than Visual Studio, both in startup time (easily human-measurable) and operation (also easily human measurable, by lack of intermittent hangups and laptop fans constantly whining).

I'd also say that Rider is more stable - I've only ever seen issues with preview versions; the production versions are solid, which can't be said for Visual Studio.

I was a Visual Studio fanboi for many years before discovering Rider, so wouldn't be easily swayed - please, try it and see for yourself!

Re:C# Pattern Matching by eberkund on Tuesday February 04, 2020 @05:55PM (#22242019)
Because VS has limitations on the amount of memory it can use and although they have been working on this, there is still functionality which is highly single threaded whereas Rider tends to offload most of the functionality from the UI thread into background processes.
Re:C# Pattern Matching by eyegor on Tuesday February 04, 2020 @07:44PM (#22242887)
The memory limitations can be partially kicked down the road by setting /largeaddressaware on devenv.exe. Ofc it's still beyond frustrating when you have a large solution with many component projects. I personally ram against the 4gb ceiling constantly.
Re:C# Pattern Matching by qwerty456127 on Wednesday February 05, 2020 @03:42PM (#22250774)
I see, this means Rider is faster than the VS on many-core machines with huge amounts of memory. That's why it isn't going to be fast for me - I only use laptops, with 4 GiB RAM and dual cores each.
Re:C# Pattern Matching by fuzzy2 on Tuesday February 04, 2020 @06:09PM (#22242142)
Visual Studio isn't native though. It's .NET and COM. That's also why we're still stuck with 32-bit VS.
Re:C# Pattern Matching by hermitdev on Tuesday February 04, 2020 @07:55PM (#22242967)
That's not why VS is still 32-bit. Apparently folks at MS dont think the extra address space isnt worth it and think it would adversely affect performance [1].

In my own experience in migrating servers from 32 to 64-bit on Linux 12 years ago, 64-bit was around 10-20% slower than the 32-bit build. Dont how itd fare today (no longer at that job). Even though performance was demonstrably slower, 64-bit it was due to edict from the CEO.

For what its worth, neither of the services I was responsible benefited from the extra address space. Mem usage for bother services peaked at around 750 MB.

[1] https://docs.microsoft.com/en-us/archive/blogs/ricom/revisit...

Re:C# Pattern Matching by ygra on Wednesday February 05, 2020 @04:23AM (#22245264)
Rico has a point to a degree and every VS version since then reduced memory footprint and improved performance (mostly due to not calculating stuff up-front which may never be needed and doing it on demand).

Microsoft has also pushed since VS 2008 (!) for plug-ins and extensions to use an out-of-process model. I think ReSharper got the message in summer 2019 that it might be a good idea – and incidentally, a lot of their performance comparison of Rider vs. VS comes down to "Rider uses ReSharper in another process, so the IDE doesn't slow down when ReSharper does things", while they themselves still pursued the slower model in VS. Heck, until a few releases ago ReSharper was still using the old synchronous COM APIs for querying the solution after loading, leading to severe pauses when opening a solution or re-loading it after switching source control states.

Vanilla VS is plenty fast and not that memory-hungry. In my experience it's extensions that try to sync with IDE state where a lot of the waiting comes in and in-process extensions where a lot of the memory usage comes from.

Re:C# Pattern Matching by pjmlp on Wednesday February 05, 2020 @07:04AM (#22246018)
Out of process model is actually much better idea, given the instability and possible exploits of in-proces plugins.

I also never liked ReSharper, the performance drop versus vanilla VS isn't worth it.

Re:C# Pattern Matching by int_19h on Tuesday February 04, 2020 @06:25PM (#22242281)
COM is an ABI, and is often implemented in native code, C++ usually. There's still plenty of C++ inside VS.
Re:C# Pattern Matching by Ididntdothis on Tuesday February 04, 2020 @07:53PM (#22242957)
Visual Studio is written in WPF which is not exactly a speed demon.
Re:C# Pattern Matching by pjmlp on Wednesday February 05, 2020 @07:04AM (#22246024)
Still way faster than Swing.
Re:C# Pattern Matching by yread on Wednesday February 05, 2020 @03:00AM (#22244850)
I haven't used rider but VS can spin up some Nodejs processes if you work with js and they are an abomination
Re:C# Pattern Matching by emodendroket on Friday February 07, 2020 @03:39PM (#22270651)
A faster algorithm matters more than the choice of programming language, as algorithm textbook authors love to remind you.
Re:C# Pattern Matching by jen20 on Tuesday February 04, 2020 @08:02PM (#22243006)
Visual Studio has been unable to keep up with my (not notably fast) typing since like 2005. Rider has no issue. Nor does IntelliJ or CLion or Goland.
Re:C# Pattern Matching by michalstanko on Wednesday February 05, 2020 @02:41AM (#22244790)
I worked in Visual Studio full-time for many years, now I'm coding in PhpStorm (IntelliJ IDEA) since July 2019, and while overall it's really powerful, I still kind of miss VS. One notable problem I have with PhpStorm is that oftentimes when I'm trying to find files or text in files, I press the respective keyboard shortcut and start typing immediately, in WebStorm the first few letters often end up being typed into the currently opened file instead of the "Find..." dialog, which never happened to me in VS. A minor issue, but it occurs every single day.

A similar thing makes me go nuts in Windows as well - in Windows 7 I pressed the WinKey and started typing immediately to find an application, never had a problem, but Windows 10 often misses the first few keystrokes after the Start menu opens. I can't believe this hasn't been fixed for years.

--

EDIT: fixed a typo

Re:C# Pattern Matching by throwaway8941 on Wednesday February 05, 2020 @03:15AM (#22244916)
Windows 10 start menu is so bad I cut it out from every Windows machine I have any authority over. Try Keypirinha, it's very snappy and supports fuzzy search.

https://keypirinha.com/

Re:C# Pattern Matching by qwerty456127 on Thursday February 06, 2020 @01:11PM (#22258507)
Why is it bad? It lists installed apps alphabetically, almost the same way all the previous Windows versions did and it has a search field to find an app quickly (AFAIK it can also search through other things but I always disable indexing and integrated web search functionality). How often do you even have to use it? I've just pinned everything I use regularly to the task bar and only use the start menu on rare occasions.
Re:C# Pattern Matching by LandR on Tuesday February 04, 2020 @09:42PM (#22243528)
Rider is miles faster than visual studio for me!
Re:C# Pattern Matching by qwerty456127 on Wednesday February 05, 2020 @03:47PM (#22250829)
That probably is because you have more than 4 GiBs of RAM and/or more than 2 CPU cores.
Re:C# Pattern Matching by jtms on Tuesday February 04, 2020 @10:45PM (#22243824)
Rider has the far superior VIM plugin as well
Re:C# Pattern Matching by bradenb on Tuesday February 04, 2020 @05:24PM (#22241714)
Does Rider work as a XAML designer yet?
Re:C# Pattern Matching by erikbye on Wednesday February 05, 2020 @08:57AM (#22246711)
Reshaper is known to be quite slow, slowing down VS by a lot, how much depends on the project. Besides, newer versions of VS and its refactoring features have come a long way, for me, it has made Resharper obsolete.

https://resharper-support.jetbrains.com/hc/en-us/articles/20...

Re:C# Pattern Matching by apk-d on Wednesday February 05, 2020 @11:42AM (#22248473)
Having switched from VS to JetBrains Rider a few months ago, I cannot recommend it enough. Way faster and less clunky than VS without Resharper, especially if you're targeting Unity. They're so far ahead I simply don't see any way for Microsoft to catch up any time soon.
Re:C# Pattern Matching by bilekas on Tuesday February 04, 2020 @06:23PM (#22242268)
Resharper is amazing, I absolutely love it but I think it makes me lazy..

Infact, I get nervous when I'm working on a VS without it..

I don't want to NOT know why ReSharper is screaming at me!

Re:C# Pattern Matching by erikbye on Wednesday February 05, 2020 @09:05AM (#22246756)
Have you attempted to use VS recently without it? Newer versions of VS have come a long way to match its refactoring features. What feature specifically are you missing?
Re:C# Pattern Matching by qwerty456127 on Tuesday February 04, 2020 @05:51PM (#22241967)
Indeed. A cool feature I love too. I miss this a lot when coding Python (in PyCharm) and JavaScript (in VS.Code).
Re:C# Pattern Matching by skocznymroczny on Wednesday February 05, 2020 @06:28AM (#22245869)
I don't understand why upcoming programming languages completely ignore the IDE experience or at most throw some basic code completion (which works half of the time) and syntax highlighting at you (not even semantic highlighting).

I'll take a "limited" language with excellent IDE support over a "powerful" language that you use notepad with.

Re:C# Pattern Matching by kashug on Wednesday February 05, 2020 @07:57AM (#22246329)
I'd argue that Kotlin is still a "Upcomming programming languages" - and I think one of its reasons for success is how well integrated it is into the IDE. (especially if you use intelliJ)
Re:C# Pattern Matching by terminaljunkid on Wednesday February 05, 2020 @07:58AM (#22246333)
The same applies for other tooling as well; one of the reasons why go is so popular.