The good parts of VS is hot-reload (when it works), the debugger, and the profiler. Otherwise I'm not a fan.
Yes you can. Change from solution view to folder view.
>The good parts of VS is hot-reload (when it works), the debugger, and the profiler
So everything you want from an IDE?
What are you actually angry at?
I'm not angry, I just don't think it's fair to claim that VS is a good IDE.
If that's all you expect from an IDE, I understand why you're happy with VS :D
If you're targeting .NET or C++ development for Windows, there's not a lot of competition to be able to claim that there's something substantially better. Rider, IMO, is on par, with better refactoring. However, VS debugger is still better.
Like this?
https://raw.githubusercontent.com/jchv/files/main/devenv_G81...
Use the "Switch between solutions and available views" button and select "Folder view." Seems about right to me.
> Visual assist is very inept compared to Jetbrains products
Jetbrains does have better refactoring, but you don't really have to choose one or the other; Resharper and Resharper C++ give you the best of both worlds. Jetbrains is missing some stuff that Visual Studio can do, too. Visual Studio does some static analysis to detect out-of-bounds errors and other mistakes, which is useful to have as quick feedback in the IDE, in my opinion.
VS isn't all too shabby, they've been shaping up recently. But it certainly isn't the best, or even among the better, in my opinion. Even the file editor is pretty weak compared to other editors IMO.
I find Resharper slows everything down significantly and makes VS worse overall.
ReSharper has been really slow, yes, but it's also much better than intellisense and noticably better than Visual Assist. As of now, it's at least usable for me. Have to turn off full solution scanning, but other than that it works.
I agree that the general experience is degraded by ReSharper, sometimes severely, but VS is just too dumb without it, IMHO.
Code completion is over thing that previously caused me to reinstall, but Intellicode is good enough by now. That one also comes with one very nice feature that I've used a few times by now: turning manual code changes into refactorings. Once you start editing the same thing over and over it starts suggesting you too do the same as a refactoring. And so far it's been very good with detecting such pattern changes and changing them on its own.
There are hundreds of things the prog does. But literally have no icon to click on or short cut bound to them. You have to dig them out of the options and bind them or add them to a menu item to even get at them. Its been like that since the mid 90s.
The list of actions for which closing visual studio, deleting a bunch of random folders, and restarting is long. Unfortunately it includes any changes to project files, because the project system is super broken with anything multitargeting related. That basically means I have to completely restart my IDE and run a script to clean everything maybe 15 times a day. And fuck me if I’m trying to find where a regression happened (which means changing dependencies, which live in the csproj).
I remember when I didn’t have to restart VS 30 times a day, and memorize which build errors actually aren’t errors, and do random sequences of events to work around bugs, and memorize which unsuppressable warnings are legitimate and which are not. Before those days, Visual Studio was indeed an incredible accomplishment.
The complaints in the original article fell rather flat to me, but this is one area where it's absolutely fair to criticize VS. More generally, the reason that build tooling in the .net sphere is such a mess is because of historical baggage from VS.
With that said, if you're coloring within the lines[1], VS is very powerful and productive.
[1] To an extent. There definitely are use cases that are "supported" only in name.
This is part of why the .NET hot reload fiasco was such a big deal to me; it felt like doubling down on one of .NET's biggest weaknesses.
The exception was Xamarin/Xamarin.Forms. Seriously, congrats to the Xamarin people for getting that project going, but it was (at least into Xamarin.Forms 1-3) more than a little hacky and extremely frustrating. Granted, it kind of had to be though given that it was intended for a broader audience targeting completely different platforms, and at least initially didn't have a lot of MS support iirc.
I think the issues surrounding cross-platform targeting were/are less a problem with the IDE itself than what it was/is forced to work with. The whole iOS "code in VS on Windows, but build on a Mac" was a nightmare, I don't know if things have gotten any better.
This is because the software you're building today is far more complicated than before (from the IDE's perspective), and it doesn't do a good job of keeping up. There's a reason why so many people jump to VSCode these days - it gives you less bells and whistles, but it won't blow up on you when you try to do something moderately complex.
So I worked on VS tooling for a few years and I'm proud of what me and my peers achieved, but I don't think this is the right perspective. People should not be surprised by the behavior of their tools, and they should not be frustrated by random freezes or crashes all of the time. What the person you're replying to has experienced is very real - I saw it come up again and again and again in reports - and I hope that things improve for them with subsequent releases.
VS 2022 is a fantastic new release (64-bit solves so many perf and user-perceived reliability issues), but there is so much more to go. VS still relies on a very very old COM-based UI model with one of the most convoluted and complex threading models to manage it that I've ever seen. It's so easy for any little component to mess things up, hang the UI, and make someone have a terrible experience. I know folks on the inside are working to improve this dramatically (they know roughly how to do it), but it's a long road ahead.
I believe Visual Studio to be one of the crown jewels of Microsoft.
I love how in tech everything is always evil one day and the next one nearly the panacea. Now I understand the timing component is actually not to get rid of entirely, in the sense that maybe a 64-bit VS would have been a bad idea the year AMD released x64, but among the stated reasons to stick to 32-bits not so long ago, and even one of the main, there was: performance.
I suspect the cold reality was that the code base was not ready and the migration just took some time :)
Yeah, this was from a series of articles that were a great example of managing to be right about all kinds of things but still be wrong in the end.
Specifically, the articles laid the blame for things like memory usage (which when high enough, causes a foreground GC in the devenv.exe process that freezes your UI), on language services that get all too happy to allocate tons of memory. If you make this 64-bit, pointers double in size and you could observe even more memory usage. 64-bit is also objectively slower than 32-bit in terms of CPU time to execute stuff. The solution it suggested was for memory-intensive components to move out of process, which is actually what many of them did in VS 2017 and VS 2019.
But the problem with this article is that it was entirely speculation. It did not account for several things:
* A 64-bit devenv.exe process gives the GC more "room to work with" and do more background GCs rather than foreground GCs, which will pause the UI far less
* Marshaling data between processes still requires use of the UI thread in VS in various scenarios, due to a wildly complicated threading model that people mess up all the time
* You really don't know what the impact of something is going to be until you actually do it
* If you commit to something ambitious like going 64-bit only, engineers can meet the challenge and produce something very good
My personal belief is that 64-bit could have been reasonably accomplished many years ago, and it would have been the right call to do it then. But I won't be looking a gift horse in the mouth. The codebase I contribute to is so much more pleasant to work in with VS 2022.
WPF has been more-or-less abandoned by the Windows team, and that's a little scary since VS uses WPF so much...
idk, I hope I'm wrong but they have been promising improvements for a while and I'll believe it when I see it.
it's pretty common amongst those who used Delphi 15 years ago (or those that use JetBrains products today)
Like Pretzold, I have a love hate relationship with IntelliSense. I think I can boil down my gripes with this: IntelliSense is wonderful for consuming APIs. It is an active hindrance for writing/designing APIs. It is great for telling you about what exists, but falls on its face when you're trying to write something new. If I am undoing the suggestions I didn't want, yet it insisted on placing, it is counterproductive. Personally, I get rather tired of slapping the escape key to cancel IntelliSense multiple times just so I can write out a dotted expression.
That's literally what GP is trying to say: "either you do it the VS way or screw you."
It takes like 20s to search source filenames of large projects, with fast SSD and 64 cores.
Hard disagree. VS makes code harder to navigate than any other popular IDE out there to the point where even vscode is more intuitive and capable, it's extremely slow at that too, and makes even the tiniest change to a build config something that requires jumping through a myriad arcane menus.
Having used other IDEs to develop Java, C# and C++ code, the only explanation I can find to explain Visual Studio's adoption, besides privileged access to Microsoft's emergent technologies and frameworks, is the boiling frogs analogy.
> If you are having to fight with VS, then you may not be using it for one of its main use cases.
I guess that writing software and building projects are not Visual Studio's main use cases, then.
Also use Visual Studio on the Mac - that one I could agree is terrible - but hope it will improve over time.
Probably helps that I have used every version of VS since it was released - so like anything else, if you are used to it and use it every day for 20+ years you become biased - but for C# programming, imo, nothing even comes close.