Microsoft's do-it-all IDE Visual Studio 2022 came out late last year. How good is it really? Visual Studio goes back a long way. Microsoft always had its own programming languages and tools, beginning with Microsoft Basic in 1975 and Microsoft C 1.0 in 1983. The Visual Studio idea came from two main sources. In the early days, Windows applications were coded and compiled using MS-DOS, and there was a MS-DOS IDE called …
Main thing that kept me on C# rather than Java was the quality of VS versus Netbeans/whateverElseIsFlavourOfTheDay.
I just wish they'd stop removing stuff. I'm running 4 versions of VS on various development VMs just because I'm nervous of upgrading.
AMBxx
Yup, MS continually moving the dev goalposts.
WinUI? There won't be a Forms / GUI builder in VS on full release.
Can't even stick to UWP for their own apps.
MS, still divisional and not the "one Microsoft" that they claim to have become.
You're not saying "Linux is better than Windows", more like "I'm not familiar with Windows development so I stick to what I know."
That's a perfectly valid statement but it says nothing about the quality of Windows, it says that you're not the person to go to for cross platform development work.
> That's why even Linux developers swallowed their pride (vi included) and
> started to use VisualStudio Code.
Hah, no we didn't
(n)vi / Vim usage statistics didn't change. The only real difference was full fat Visual Studio user numbers decreased as many moved to VSCode.
They finally realised Vim users were right, you *don't* need one big fat old-school IDE for every task. Smaller text editors are the future.
Sure. If you're idea of being productive is constantly having to toggle between cursor and edit mode.
Give me a Linux console text editor that has all the key bindings one normally finds on Windows. It has been needed for a long time. nano is kind of close, but, not quite.
vi is garbage IMHO.
I never got this obsession about Vim.
I don't think this fad will last long.
I like to write my code using my Royal 10 Typewriter, then use my old scanner + OCR for the A4s and Bob's your uncle.
The N is missing, so I have to add them all in by hand, but hey...
I am thinking of getting rid of all this over engineering anyway, and just use card board and a single hole puncher, like normal people.
Here's what you get with a default install of VS Code.
1. While typing, a sea of distracting pop-up's from IntelliSense or whatever covering up your code so you can no longer see what you're typing.
2. Selecting text via double-click with a mouse may or may not cause a pop-up from IntelliSense with help links on the first click, thus the second click hits a "help" link and opens a random page in your browser.
3. *IF* successful at double clicking text to copy/overwrite, it might not select the text and copy, which you'll soon find out when you go to paste.
4. Everything it can see in the directory tree up to root will be parsed for "helpful" data, it specifically parses and collects data on any .git you have in the tree, regardless if it's part of the project.
5. All plugins are always checked at startup no matter which project you want to work on. So you just wanted to edit a script... TOO BAD... your PlatformIO needs to update and you need to restart the application.
There's so much wrong with VS Code that people pretend there isn't all for promotion and advertising of a Microsoft product. Either these Microsoft mouth pieces are getting paid or have never seriously used a IDE. If it's the second case, it's no wonder why they don't understand the real reasons Linux developers want VS Studio.
By all means, if you type less than 20 words per minute, can NOT click a mouse 3+ time per second and love distractions, go ahead and use VS Code. Sadly, even if you love distractions but still type and click "fast", you just can't use VS Code as it's sooooooooooooooooooo slow.
Are you complaining that they killed FoxPro, or that it existed in the first place?
I'm in the unenviable position of having to maintain legacy applications written in "good ol' Fox" alongside my other work of new development, done principally in C# in VS. Some of these Fox apps have a codebase that is getting for being 40 years old. As they have grown, despite best efforts of those involved, they have become more labyrinthine and tightly bound.
Foxpro is a bastard halfbreed of a language, caught somewhere between pure procedural scripting and not-quite-really-object-model-based stuff. It enforces no sort of encapsulation, or any other SOLID principles, uses its own display engine that is a tangential fork of Ye Olde Winformse that doesn't quite give you the flexibility you need for any one situation, and likes to spray temp files all over your OS. Whilst you can get it to work alongside saner .Net code, it does so through COM, which needs you to jump through several hoops, and isn't exactly the most stable thing in the world, especially when it comes to memory management.
I say we take off and nuke it from orbit; it’s the only way to be sure.
It's not quite as bad these days because you could use QTCreator, VSCode, Atom, CLion, Eclipse or a few others and have a reasonable working environment that makes use of the GUI. I personally think CLion is a really good IDE assuming you're prepared to pay for something.
But it has been traditionally true and there is nothing that comes anywhere close to the breadth and scope of stuff you could do inside Visual Studio. It's odd though in a way that VS is actually moving away from proprietary stuff like .sln files and .vcproj and closer to stuff like Ninja, CMake. It does make cross-platform development easier if the files and tools you use to describe your project are also cross-platform.
Even debugging with gdb, even with a front-end feels painful and retrograde compared to debugging in VS because it has integrated debuggers for every language. Actually GUI development on Linux can be also horrible depending on whether you're writing for QT or GTK.
>That's why even Linux developers swallowed their pride (vi included) and started to use VisualStudio Code.
Linux has always had Eclipse. VS looks a bit like it but then there's only so much you can do with a main window with a bunch of sub-windows. I've used them since the PWB and various Borland language environments; they're OK but I used to keep away from them because they only allow a limited set of options for configuring compiler flags and the like (and VC used to get things wrong quite often meaning you had to dig around in the XML to sort it out).
I find that pluma (the Mate version of gedit that uses the older (superior) interface) does what I generally need for development on Linux and FreeBSD.
I've been using gedit (then pluma) since 2005-ish. Works VERY well. And with an RPi you can use DISPLAY to make it work across a network so you can run pluma on the RPi directly but have it display on a proper WIMP display running Linux or FreeBSD (along with some ssh sessions for building and testing etc.).
But if people want the MS IDE that's fine with me. I just do not like the 2D FLATASS look. Maybe I could get Micros~1 to use something like 'TraditionalOK' for the Linux version...
"At one time, Microsoft's advice for those trying VS previews was to wipe and reinstall Windows afterwards;"
This is a strong contender for the most-microsoft advice ever.
Wipe, and re-install the OS after testing some software?
What were they smocking?!
Icon: the nice gentleman has got his dose right,
unlike those who considered wiping the whole OS is not a huge parade of red flags indicating that they were doing something massively wrong.
I intentionally did write programmers in the previous sentence, because there is nothing 'pro' in such conduct.
Yes indeed, I had the pleasure too. That thing had “logged itself into the operating system” so deep that a removal resulted in a “non-operating system”.
Both Eclipse and Visual Studio are more of an operating system than just an IDE. Both are extremely clumsy and slow. Other IDEs show that this is unnecessary and can be done much, much better.
Both are extremely clumsy and slow.
I don't know what your use-case is but for web development Eclipse is in the order of 4 - 5 times slower than using VS Code for any like-for-like operation, whether that's starting up or trying to configure some workflow. Slow and clunky are words I associate with Eclipse but my experience of VS Code has been the complete opposite.
VS Code is not Visual Studio
Just saying.
In my experience Visual Studio starts up very fast since the 2019 version, faster than most other IDEs.
The Perforce plugin then turns it into a snail, but that's Helix for you. There's a reason Microsoft don't use Perforce anymore...
Huh. VS starts up really quickly, yes. But then it's unusable for a couple of minutes because it's loading stuff in the background. Admittedly a fair chunk of that for us is R# getting ready but not all of it is.
I would far rather VS be honest and upfront and tell me to wait while it gets ready. That would be better than the current situation where you just have to keep prodding the thing until it finally seems to be up to speed.
You could uninstall it. It just required uninstalling 50 components under Add/Remove Programs. Yes, a huge chore and way more work than it should have been. NetBeans installed in less than 5 minutes and probably only took 2 max to uninstall. I never understood why Visual Studio install/uninstall was as horrible as it was. As I think someone else mentioned, I think it's all the COM crap. It has to write out 5 million registry entries to function.
Dunno how long ago that was but it's no longer the case now. I'm on the preview programme and I update VS many times a year with no problems. I've also over the years moved from 2k8 to 2k22 on this machine and uninstalled previous versions with no apparent problems.
Wipe, and re-install the OS after testing some software?
After testing some preview software.
Because of the way that Windows works, every piece of software installed gets its claws into the registry, installs COM objects, and so on.Visual Studio is a complex beast, and comes with a lot of COM components, and makes a lot of changes to the registry.
It's perfectly possible to unravel all of this in a deinstaller, and I would hope that Visual Studio releases do this.
I'm not surprised that a preview doesn't come with a production-quality desinstaller, though. A preview is still Work-in-Progress. The best way to get rid of all the cruft - and to be confident that you really have got rid of it all - is to reinstall (or, yes, revert to a snapshot).
Really bugs me how Microsoft cannot seem to figure out the confusing they often cause naming things so badly.
ASP and then ASP.NET didn't help, but then ASP.NET Core, and then deciding to have the new 5+ version called simply .NET and now calling the old stuff .NET Framework just adds to the confusion.
They've managed to do a similar thing with Blazor, so we have Blazor web assembly and Blazor server, being client or server side.
Then Visual Studio and Visual Studio Code, which are really entirely different things that do broadly the same thing.
At the very least it makes Bing-ing for things confusing, because you invariably end up finding information about something entirely different to what you're actually after.
Microsoft is big enough that it really shouldn't need to leverage established names for new products, Visual Studio Code would surely have stood on its own without name-checking its older brother.
True, they have made a total mess of the naming and versioning. Trying to search for documentation on specific .Net or C# features is a bad experience as the Microsoft docs try to direct you to the latest version with features that are not present in the framework you have to work with. VS started suggesting code changes which are not compatible with the version of framework we run with, so that made VS code helpers a bit less helpful.
Their philosophy seems to be that everybody should throw out their old software solutions and write a whole new set in the latest version of language and framework. This seems quite disconnected from reality to me.
I keep on working with old ASP.Net forms and would dearly like to be able to start replacing it with their shiny new .Net, but I'm kind of frozen whenever I try to determine which bits of the technology I should concentrate on learning. There are just too many different streams of toolsets and frameworks. At least ASP.Net development and debugging in VS is simple and mostly trouble free.
It is actually a well known (internally) tactic deployed to spread uncertainty or to avoid people thinking that Microsoft software "dies".
Classic examples are:
Visual Basic completely died and an entirely new language called Visual Basic.NET replaced it. Completely different languages, tools and concepts. When in actual fact, Microsoft killed VB as a standalone tool and broke *many* business workflows. I think VBA is next on the cutting board as Office moves entirely into Javascript restricted online. Writing a VBA interpreter will be too much work for them. They no longer have the skilled workforce.
C# is actually not related to C or C++ or Objective-C *at all*. It used to be called J# until Sun sued Microsoft for trademark infringement. However C and C++ is not a commercial product; there is no company behind it to defend the trademark. There is no trademark. So Microsoft saw it as a good way to get free "advertising" and convince people that C# was the logical modern "next step up".
To be fair, both VB and VBA are evil and should be destroyed with fire.
As far as I am aware, VB was pretty tightly hooked into a very old version of their operating system, with API calls that they, quite understandably, thought they might like to get rid of in favour of better, faster, or more secure alternatives that weren't written at a time when the internet was something nerds used over dial-up modems to play games with WOPR.
VBA is that abomination that is responsible for middle managers thinking that they can make everyone do their jobs via Excel spreadsheets that take quarter of an hour to load and are inherently single-user.
VBA enables you to do things in spreadsheets that you really should be doing elsewhere. It lets middle managers think that they are programmers; the old adage of a little knowledge being a dangerous thing leads to unmanageable messes of macros with nobody knowing how they work.
Admittedly, this isn't the fault of VBA itself, it's the fault of people who think they know what they're doing when they don't, but it sure as hell enables those people.
To me, anyone who uses the phrase, "let's do that in a spreadsheet" in response to trying to solve a particular problem is just adding another problem into the mix.
Not true about C# and Java. J# was the increment on Visual J++. There would probably never have been a C# if Sun Microsystems had not gone to court about COM+ interop annotations. Only now with GraalVM is Java remedying the omission.
C# never had Java's declarative exceptions (a good thing - exceptions as part of the interface were an experimental feature that was never removed).
C# always had structs as a value-type (including complex types like DateTime that Java has to shred to place in arrays). struct make GPGPU interop simple
C# always had property methods that Java only has thanks to IDE support (or via abominable JDO)
C# always had multidimensional arrays (like Fortran). Makes GPGPU interop simple
C# 2.0 introduced proper generics without type-erasure in the GJ fudge for Java 1.5
C# only looks like Java, if you've never used C++
> J# was the increment on Visual J++
Yep and Visual J++ was an earlier clone of Java. They went through increments but it was still to clone Java. Visual J++ certainly is not similar to C++.
Your examples above are... fairly minor. And notice that they are simply "improvements" over Java rather than C++. Mainly EEE strategy than anything.
1) Exceptions; C++ doesn't even have finally (C# inherited that from Java). Unnecessary with RAII. Though C++ does have exception specifiers (optional)
2) C++ has structs but unlike Java or C#, it only alters default accessibility. C# identified a flaw of Java that heap for everything and lack of pass by value is awkward. (extension)
3) C# properties are improving the Java get / set mechanism. Generally a flaw of overly object oriented languages which C# inherited by being a clone of Java in the first place.
4) Multidimensional arrays are unsafe in C++. We don't use them. Contiguous memory with std::vector is recommended by Stroustrup and Sutter. Fine with managed languages which C# is by being a clone of Java
5) C++ always had templates. C#, being a clone of Java started life without them. But then added them as an extension to be better than Java (EEE)
6) C# only looks superficially like C++ because it is a clone of Java which was modelled after C and C++. For one RAII (for better or worse) has made the C++ language quite unique (Rust comes close). std::shared_ptr<T> for example changes entire architectures compared to just letting a garbage collector clean up the memory. Even the PIMPL pattern would be weird with C#/Java. Partial classes perhaps?
In fact, the C from C# came from its original name of "Cool". Cool-lang. How tacky is that?
5) Templates were not in 1st edition TC++PL (1985). They were first described in the ARM (1989), They were implemented in Cfront3.0 (1991) and documented in 2nd Edition TC++PL (1991).
It's safer to say generic programming was always intended to be in C++, but it took a while for it to be added.
[1] C++ structured exception handling has finally, but is used to close a try block.. sure Java recognized that a finally block could include code that would otherwise be duplicated.. but did not originate with Java. It is not replaced by RAII because resource access is not the only source of exceptions
[2] structs (and classes) in C++ can be allocated on the heap or stack.. C# introduced boxing to pass structs by reference. By convention (like Hungarian notation) structs are used as value types in C++. Java hotspot supports stack allocation of classes, but only if the object cannot escape the scope of function
[3] Properties were inherited from Visual Basic.. Java never had a notion that could be "improved on"
[4] multidimensional arrays are not "unsafe in C++" but are dense arrays where the index is calculated explicitly. Array of array is preferred for efficiency, not for safety. For GPGPU multidimensional arrays are needed to avoid pointer dereferencing in kernel functions
[5] C# 1/1.1 did not have generics (like VB), C# 2.0 acquired generics from C-omega (research project), with explicit support in the runtime, and not GJ style type erasure - it was not to be "better than J2EE", but to support a clean and efficient type system
[6] A std::shared_ptr<T> contains a pointer to the object and a pointer to the reference counter, there is no change to the object (or architecture), and no "garbage collection" passing std::shared_ptr<T>& is preferred to avoid interlocked increment/decrement. PImpl pattern is C++ specific (to avoid #define public private), it has no meaning in managed languages.
It is touching to see such affection for Java, but if we're honest the JVM was inspired UCDS p-system.. outside of academia Microsoft was the main proponent of p-code from their Cobol, Pascal and Basic compilers.. it is not unreasonable to say that Java RMI was inspired by dynamic p-code generation of DCOM proxies.
Sure "Cool" is a tacky name, but Java got its name from the HotJava browser, which got its name from the high caffeine coffee from the island of Java
Certainly no touching affection for Java. If you notice my argument was that C# *is* effectively Java. Neither are something I am interested in.
Many of your points were just adding details to mine and also agreeing that C# is very different from C++ so I won't argue here. The only point is your first one.
C++ does *not* have finally. You might be talking about Microsoft's non-standard extension?:
https://www.stroustrup.com/bs_faq2.html#finally
>> JVM was inspired UCDS p-system
This is interesting. Assuming the AT&T Plan 9 Limbo VM (that was created in parallel, again very similar technology) had the same inspiration?
You are correct. Visual Studio Code versus Visual Studio, is just like ASP.NET versus ASP.NET Core. Core should not even contain the name ASP.NET. It is completely different. I strongly disagree with them not moving Web Forms forward also. MVC was NOT a replacement. Not even close when it comes to intranet apps developed using something like Telerik's UI controls. I'm not sure Blazor is even a real replacement at this point. New is not necessarily better. Maybe better in some respects, but, lacking in many other. I'm still on Web Forms. Maybe at some point I will switch to server-side Blazor once it is mature. I have no interest in client-side web development. I have no interest in switching to Code either. It's multi-platform. Other than that, it's not even comparable to Visual Studio, at least with regard to .NET development.
We also have a huge legacy codebase on webforms, and I think it's a mistake for them to dump it. At the very least, they should open-source it so others can try to implement it in .NET (the new one, not the old one).
The irony is that most of the hate for webforms stems from the view that it's a layer of abstraction between the code and the resulting HTML, which is a bad thing, reduces performance, etc. even if it makes coding easier. And yet, you are now virtually pushed towards EF, which is an abstraction layer between the application and the database which supposedly makes coding easier, but is 5-10 times slower. Considering that online apps are nearly always database limited when it comes to performance, this seems a curious paradox. You make the application code a bit harder to write, but cleaner and faster, but then do the exact opposite with the database.
We've dabbled with server side Blazor, but it doesn't seem anywhere as well supported as webforms and still feels like it's a trial being chucked out there to see if it sticks rather than a well-considered replacement for webforms.
Some errata for you:
Visual Basic did not completely die, it lives on, VB6 is supported in Win 11.
C# was always called C# and was separate from J#. J# was built at the same time and converted Java source/bytecode to MSIL to run on the .NET Framework.
C# is related to C and C++ as an ancestor. It was original called "Simple Managed C". Did you know it stands for C++++, the four pluses meaning +2 and forming a #? If you look under the hood of 1.0, C# is more like C++ but in the early days it looked enough like Java for people to convert over.
I agree more with the original comment that naming is a complete disaster zone but not for the reasons you give.
the .net core it's a huge fail in my view, starting from the naming.
.net core 1.x -> .net core alpha 1.x
.net core 2.x -> .net core alpha 2.x
.net core 3.x -> .net core alpha 3.x
.net 5 -> .net core beta 1
.net 6 -> .net core RTM
assuming they don't add more breaking changes with version 7 or yet another format for project and/or special files like startup.cs
AS for naming issues, did anybody noticed that the blue theme is not blue?
Not sure why they did not the blue one and call the current violet them as VS default. small things, but annoying
C'mon, it's Microsoft. Of course they are going to break something important as soon as a certain level of aoption is reached. They couldn't even leave the C++ runtime redistributables alone, for fax ache. Someone in their manglement must have read something about disruption and instructed the whole company to do just that.
The Microsoft C++ redists are shockingly stable.
Backwards compatible all the way back to 2015 is an outstanding achievement. I don't think there is any other native code toolchain that's even tried to be half as compatible.
Or indeed any toolchain - Java is a hot mess if versions, after all.
They shifted the distribution model back and forth multiple times in the last few years. For a long time, you were allowed the ship the dlls with your own dlls or exes. Then they changed it to obligatory installer run (without any possibility to run the installer silently), than back and forth again once more, iirc. Same with MSVC: at one point, there even was no legal documented option to install it headless (without VS gui). Interesting times, at least for our CI people.
Don't get me wrong, I can understand that these changes may very well have been necessitated, most probably outside the respective teams (the changes often corresponded with major developments in Windows' isolation, runtime and virtualisation structures). But my point is that Microsoft as a whole can't keep even their most stable, innerest core development landscape straight for a few short years these days, so one would be best advised not to expect any such stability with the .Net Framework/Core thingy.
I am old enough to remember when ASP.NET first came out and was called ASP+, and I swear the web.config file was originally called config.web. Which made no sense, when the filetype was really a config file, and it seemed likely you may have config files relating to other things in the future. Some of these significant changes seem to be made very late in the day, often after the RTM. They don't seemed to have learned these lessons.
I did think the blue theme didn't look very blue, but I am a bit colour blind, so assume that was my problem not theirs.
The first rule is not to use any 1.x version unless you really have to.
What I do not like about the .net core is that they pushed out version after version with overlapped support windows and breaking changes one after another while calling them all "production ready".
Lots of people apparently jumped on the core bandwagon (or at least the vocal ones who write blogs and are very active in the community) providing free beta testing while enjoying it.
To me (close to 20 years of professional development) it was a disappointment.
I was able to smell the scam and I did not do anything relevant in .net core until very recently, but they managed to "pollute the internet" so when you look for documentation there is a ton of noise related to what I call "alpha" versions, especially when you are trying to troubleshoot funky behaviours.
Most likely the .net core is to asp.net MVC what Webforms has been to classic Asp: a great improvement that turns into something you don't even want to think of as soon as the next "big thing" is out.
Kinda like windows, 1 every other version is ok :-)
Coming at this from a web dev perspective. Mostly using PHP, sass, ES6 JavaScript in Docker containers and CI processes on GitHub.
Previously we used Eclipse PDT and/or NetBeans with a fuckton of "workarounds" to try and make our workflow happen.
The nice thing about VS Code is the number of decent extensions you can get for it to support almost any workflow. The built in terminal seems to be something other IDE's lacked and you really do question why, in hindsight, these other tools didn't have that.
It's an environment I can work in pretty much all day without needing to switch between applications. Finally.
For us we can now do pretty much all our work in VS Code. We run our tests locally and then push to GitHub before using a CI process on there which can be configured so code can only be merged once it passes all the required checks.
The lack of a Linux build hasn't stopped us although it is odd given the number of people who develop directly under a Linux environment. Can't comment on the Windows build but on a Mac it works flawlessly.
Oh, and as a final nail in the NetBeans / Eclipse coffin - it starts up in under 3 seconds and doesn't use all my RAM! Why this was such an issue - in IDEs that did *so much less* - is beyond me.
I am in the "wow I want a Linux version" department. It would really promote my adoption of Linux as a primary platform. In what universe is being built in JavaScript a good thing? (unless your main goal is being cross-platform)
Aside from the overall feature set of VS being so substantial for C++, I don't really like the philosophy of CS Code. I am capable of working a terminal and JSON for commands and configuration, but I don't want to. Since I don't use each individual command or configuration very often, I'm not going to have memorized a lot of the things I will need these tools to do. Hence, I'm often going to wind up having the manual open on another monitor so I can know what values are appropriate for a setting, or what command does what I want.
Here's a thought: what if I wrote an add-on that allowed me to link the IDE with the browser, and when I clicked on the text for a particular command it would be automatically executed by the terminal? Saves me from having to type it, keeps the click/keystroke count down. The add-on would just tell the command to park it's butt on to the terminal.
Joking aside, I appreciate having terminals and raw config files AS AN OPTION. However, unless I do something frequently enough to have memorized it, a GUI makes more sense. Try sitting somebody down with a C64 and no manual. Ask them to load a game from a disk. That's going to be a long and painful experience (LOAD, 8, 1 obviously!). This is why we invented the WIMP interface; humans prefer to learn through the UI, rather than through reams of documentation. People want to get things done, not read docs (I should know, I used to write docs).
Cue the downvotes.
I've tried JetBrains Rider on Linux. Seems to work mostly quite well, on .NET-core projects. Not so much on the old Windows-only old framework projects.Community version is also available, although I've got a paid license. Worth trying and testing, it might work for you or then not.I'm not affiliated with the company, although I like them a lot. Because they've got their origins in Europe, former Czechoslovakia, nowadays Czech Republic, and the headquarters are in Prague.Someone could now guess that I'm an European and don't like much American companies over-dominance.
64-bit IDE is the biggest change. Inteli-sense was a big problem for very large projects, that drove developers to use VS Code.
Support for Clang, CMake and WSL2 debugging makes Linux development with VS straightforward. It's unlikely there will ever be a port of VS to Linux because it is no longer needed with GUI supporting wsl/g (Win11 inclusion of Wayland and GPU virtualization kinda turns windows into a hybrid Linux OS for developers)
WSL2 is pretty good, but there's a lot of vwry silly issues (eg RAM usage is crazy) and things you just can't do because of the way it's hidden behind Windows.
For example, it doesn't appear to be possible to send any UDP packets into a WSL2 VM - the Windows portmapper is TCP only.
So you can't test things like HTTP/3 servers at all.
Really miss that from vs2019 is my preferred way of managing and tweaking deployed azure resources, ive never been a fan of kudu and find that tool window indispensable.
Other than that vs2022 performs nicely for everything ive thrown at it, and is noticably better at handling large solutions, still has its performance destroyed by resharper (and i have a stupidly overspec works machine current gen xeon, 128gb ram, rtx gpu... its not lacking grunt), yet still if i enable resharper for its superior unit test explorer/runner i can expect the text editor to hang for 20 secs at least and same when an intellisense window opens :(
Jetbrains, please make the resharper unit test windows available as a standalone plugin, everything else resharter does/did well is now baked into visual studio, and no rider is not a suitable replacement for anything other than new green field trivial projects
yet still if i enable resharper for its superior unit test explorer/runner i can expect the text editor to hang for 20 secs at least and same when an intellisense window opens :(
That's weird. I have an aging i7 with 32MB of RAM and I have no performance issues with R# once the solution has loaded. I typically have three or four VS instances open all with fairly large solutions.
Yes, resharper is a resouce hog. If you go into Reharper > options > products and features > You can select which features from resharper you want to use. You will probably only need to tick "Resharper" and "navigation and search". If you untick everything else Visual Studio will respond much faster and you still will have access to the main resharper refactoring tools.
Reharper is pretty much disabled in terms of features
There is a years long thread on the support forum and boils down to to it choking on mixed project types particularly Web ones which have been upgraded through multiple versions of vs.
The official line is wait for out of process version of r# but frankly they have ignored the performance issues for years and seemingly decided to write rider rather than fix the thing properly.
The fact I have such performance issues on a seriously over spec machine is laughable. It's a shame as I love the dot suite of tools (cover, memory, trace and peek) so the sub is still worth it and we have no appetite to ditch teamcity for trendier CI solutions it does what we need and is well understood internally but reharper really spoils the experience. Especially given the improvements ms have added to vs
.editorconfig files, built in useful refactoring tools (not the code suggestion crud r# adds on top), ctrl+t for type/member search, roslyn code analysis etc.
And still full of bugs. The UI is poor verging on awful and they seem to have no interest in fixing it. They occasionally bugger around with the icons or the menu text but that seems to be the extent of their ability.
It's the best tool available for me (Desktop and C# developer) but lordy the experience sucks.
On the plus side the move to 64-bits has finally given it enough memory that R# is no longer choked so it is now at least stable and fast.
'tis for me. Of course it depends what you consider to be 'large'. I currently have four VS instances with (between them) nearly 5,000 individual source files. If I try and include references between solutions that can probably be expanded to 7,000 files. Then of course there will potentially be references to several hundred more files courtesy of external dependencies.
There is rarely any delay with R# and if there is it's usually only a couple of seconds.
Typically each R# instance claims to be using around 2GB of memory but during heavy refactoring exercises I've seen it rise as high as 4GB before subsiding after a while. That fits in with my previous experience of R# which was sluggish performance and crashes during heavy refactoring. I can even switch branches without suffering now whereas that used to be another source of issues.
We also have a legacy solution which is I think over a decade old. It loads just fine and R# operates well. That solution I think only has a few thousand files in it.
I'm not trying to be funny (and historically I've tried to dump R# several times having a love/hate relationship with it) and I'm not a fanboi but since vs/64 arrived I've stopped hating R#. I'd hate to think of any VS developer not using it or suffering issues so I'd urge you to investigate the reason behind your problems. R# doesn't have to be slow or unstable.
Oh and FWIW I'm a major R# user. It's not something I consider occasionally. It's pretty much my primary editing tool. Any time I see something underlined my first thought is to tap Alt+Enter and see what is on offer. I sometimes think that most of my coding is being done by R# with me just directing it :)
Same mate,
Been what i consider a R# power user since 2008 or so, pushed for its adoption when ive worked at places that didnt use it
On a small solution its ok, the killer is as soon as we try and do something on the larger solutions 5000-10000 files (its legacy and a previous dev drank heavily from everything needs an interface cup) it chokes, i can literally disable everything and just rely on the refactoring renaming and namespace moving dialog and still it will suck the life out of VS.
It gets even worse if i load the single project web front end solution, where some bright spark decided telerik web controls was the way forward and has all the kendo chod in the solution :(
And like you ive tried to ditch it several times but keep coming back. If you havnt tried vs22 without it enabled i suggest you do, the inbuilt refactoring tools (that i use YMMV, i ignore the linqify a readable foreeach loop into an unreadable brain spraining mess tool) are on par with r# (especially if you config r# to use VS keyboard shortcuts) but with no discernable impact on performance.
I literally only enable resharper now when im updating or writing new tests as the r# test runner is brilliant especially if you have several test frameworks in use because legacy, and the integration with dotTrace is cant live without it good.
Unfortunately though ive given up on it ever being fixed as i have had several frustrating and long winded support tickets with jetbrains to the point where they admit the problem and now just say wait for the out of process version, or use rider which just isnt in the same league as VS when it comes to dealing with framework based projects, and i dont really see why i would use a different IDE for core/.net6 projects...
"the team at Microsoft is relatively responsive to feedback – according to the feedback site, Visual Studio 2022 closed 1,177 requests"
My experience of them closing requests is usually "not enough people voted, we're not doing it*", "too hard, can't be bothered*" or "that's how it works, suck it up buttercup*".
I suppose saying that's responsive is technically correct. It's just the type of response that I find dispiriting.
* my paraphrasing, not the actual words, obvs
I have deliberately not used MVS as my IDE - I made the mistake of following a course offered by Mark Lassoff - yes, the course required MVS IDE! So I installed it. Whoa! big mistake.
I finished the course and tried to uninstall it.. It did uninstall until the next boot up and then all hell broke lose. My system started spewing messages that files were missing, access was denied, XXX was unable to run...so I ran a repair and lo-and-behold MVS was re-installed by then I was faced with a rude message that I needed to sign into my M$ account in order to activate the software. Of course, I did not.
I returned to my tried and trusted Netbeans and Atom because it was easy for me and it does what I need it to. I deliberately did not associate any files for projects with it. But - BUT - a day does not go by when the unwanted installation tries to open my projects, rudely informs me I am not signed in or do not have a license to use MVS and it uses an inordinate amount of space on my hard drive. No, I cannot uninstall it because the M$ geniuses have decided win10 needs it for something. Plus it is one of the first pieces of software to be updated when my system boots up - Wireshark all but spews out connection after connection as if it is ready to choke!
So avoid it if you can.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
