I also feel like VS is getting worse. I run into far more errors and issues now than I did several years ago. My theory is the success of Azure and the end of the era of "Developers developers developers" has caused Microsoft to place less of their best engineers on the tooling team.

There’s always some degree of a rotating cast of people, that’s always been the case.

Really there’s three important factors in perceived VS perf issues:

1. Your codebases have gotten bigger. More projects in a solution and more code in a project means more work the IDE has to do. Various components have their breaking points and it’s not uncommon to hit them.

2. VS is really really really really big. Some components in there run like a well-oiled machine. Others, like those last touched in 2013 and with less than 10k users per month, are rickety and will freeze your UI or cause the GC to freak out or both. If you’re one of those 10k users, whoopsie!

3. For many years the mandate in the VS org at Microsoft was that of a feature factory. That changed around 2016 or so, maybe a little earlier. But cleaning up a decade of feature factory work while still needing to innovate on a growing userbase that throws more and more at the IDE each year is hard.

I don't feel that VS is necessarily getting worse (it's always had weird errors and issues; some people just have nostalgia goggles for certain older versions), but relatedly I feel that VS Code is getting too good. So many new features seem designed for VS Code first and VS integration is an afterthought. An increasing amount of the time I find I want to work in VS Code more and switch over to VS only "when I have to".

On the one hand this is great for cross-platform development (as is the topic here), as VS Code is about as cross-platform as it gets.

On the other hand it feels increasingly interesting/weird/almost-sad that the expensive flagship of the VS brand sometimes seems to be left behind by its tinier, free (as in beer and speech) counterpart.

I don't think your theory is entirely correct, but I think some of it applies here: VS Code started as an Azure project (the core editing experience Monaco was designed for the Azure Portal first and foremost) and seems to get a lot of love precisely because of its cloud synergies and its place near Azure's heart. It does seem to have captured the hearts and minds of most of Microsoft's best tooling engineers. That said, it's possibly the most "Developers developers developers" they've ever been given how much of that tooling is now cross-platform, isn't tied so much to Windows specifically, and isn't tied as much to Microsoft-only languages either.

Interesting article from last November that touches on the tension between VS and VS Code: https://www.theregister.com/2021/11/08/dotnet_6_vs_2022/

That's true. I guess when I think of Microsoft prioritizing Azure over Visual Studio (which I understand) I'm thinking of VS code on the Azure side even though it is a tool.

Counterpoint: I've been extensively using VS 2019 for years and VS 2022 for a few months. Neither has been notably buggy other than the occasional glitch with Live Unit Testing.

For further comparison, I've also used JetBrains products a lot over the past few months. They are also solid and work great.

I don't know -what impressed me about VS 2022, is just how amazingly fast the new UI is - everything is instant now, it's by far the greatest speedup I experienced in a new VS release. Probably it helps that they moved to .NET Core from Framework, and to 64-bit as well.

Okay, I keep seeing people say this, and I have had the complete opposite experience. VS 2022 brings my somewhat beefy work laptop to an absolute crawl sometimes. I can open VS 2017, load a solution, and close VS 2017 all before I can even get to the solution selection screen for VS 2022.

Often a big difference is plugins: check and triple check what plugins you have installed.

There's a couple extremely common plugins "everyone loves" that just murder VS performance and everyone blames VS and not the plugins.

+1 on this. Previously worked in the developer tools division that builds VS, and whenever someone got assigned to work on a performance or crash bug you'd almost always wind up hearing them mutter "it's f*cking ReSharper again". The VS team has had a huge push in the last few years to improve code analysis, introspection, and refactoring (with Roslyn) specifically to try to replace / kill ReSharper. The company has no animus with JetBrains, and the team has nothing but respect for the value it's added to the ecosystem, but it's by far the biggest source of perf and crash issues in VS.

I know people feel like they just can't possibly live without it, but the refactoring tools in VS nowadays are much better, so I encourage folks to test drive by going a couple weeks without installing ReSharper. If you still really miss it and are willing to pay the performance penalty to have it after that, go for it. But give VS a fair shake without it.

Resharper is kind of a dog in terms of performance, and I think it's a major source of performance issues under VS - especially with large project.

One of the reasons for this is you can't turn off the Roslyn-based MS engine in VS (which IMO is reasonable, since it's needed for a lot of stuff) so there are always 2 code analysis engines running.

That's one of the main selling points of Rider Imo, that it doesn't run 2 completion engines simultaneously, which makes it much faster.

Unfortunately Resharper is still far superior to VS with the quality and quantity of built-in refactorings.

Another thing with Resharper is that it seems to run synchronously, meaning if you type something and press the completion button, the suggestions always pop-up. A major pain point in previous VS versions is that this wasn't the case with the built-in engine.

Sometimes you just pressed the autocomplete button and nothing happened, because VS was still parsing your code.

Thankfully 2022 fixed this, and this is one of the reason I would never consider going back to the older versions.

> One of the reasons for this is you can't turn off the Roslyn-based MS engine in VS (which IMO is reasonable, since it's needed for a lot of stuff) so there are always 2 code analysis engines running.

Roslyn is extremely well tuned. (Anecdotally in any IDE including VS Code without ReSharper it's performance is incredible and hardly noticeable.) ReSharper's performance problems are ReSharper's performance problems.

Blaming ReSharper's performance on Roslyn is just as wrong as blaming ReSharper's performance on Visual Studio. It's pointing the finger at the wrong thing in the stack.

Of course that's a big selling point for Rider. It's incredibly wonderful marketing luck that almost all of ReSharper's performance problems get blamed on Visual Studio itself or on Roslyn and almost never directly on ReSharper. As long as people keep pointing the fingers away from the plugin, JetBrains gets just about free marketing from every VS performance complaint real or imagined. Their incentives aren't aligned to improve ReSharper performance when "everyone" just answers "Just switch to Rider already" because they mistakenly blame Visual Studio rather than the ReSharper's own engineering.

VsVim is the only plugin I have, and perhaps it's slowing things down that badly, but that would be surprising to me.

VS 2022 is still based on .NET Framework. It’s faster because a lot of talented folks worked very hard to improve it :)

we are developing a connected vehicle platform in .net on azure and one dev is using Rider on Ubuntu and is quite happy.