I am starting to hate Visual Studio.
-
I know, I know - its the best dev environment out there. Just give me a minute.
I made a tiny, inconsequential addition to an old app (to cope with a new thought. Literally one line of code. ran it in the debugger, and tested it. Worked fine.
So I built it for release. And all hell broke loose. Errors everywhere, all complaing that one of my classes was an ambiguous references with a system class. 522 errors. So I start qualifying my class reference. Which (understandably) is taking quite a while.
But then I had a thought. "What if I switch to var instead of an explicit class when I declare the variables?" (Which I tend to avoid as the maintainer - i.e. me - has to work out the type from context, which takes longer than an explicit typing.)
And what do you know? it works. With "var x = ...;" it works out what class it is from context. With "MyClass x = ...;" it doesn't ... For fawks sake MS!
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt -
Maybe add a global using alias directive to the project?
global using MyClass = MyNamespace.MyClass;Add that to a single file in the project - eg, an empty
GlobalUsings.csfile - and every reference toMyClasswill resolve toMyNamespace.MyClassrather than generating an ambiguous match. -
I did, in the end. It's just so sodding annoying that MS adds the confusion, can sort it out from context and not blow compilations of older projects, but refuses to do so and throws hundreds of new errors instead. If it can working out from context for an explicit var definition, why not from an explict class?
I'm becoming convinced the devs at MS are not testing anything they don't use ... and they don't have to maintain their own code ...
-
I know, I know - its the best dev environment out there. Just give me a minute.
I made a tiny, inconsequential addition to an old app (to cope with a new thought. Literally one line of code. ran it in the debugger, and tested it. Worked fine.
So I built it for release. And all hell broke loose. Errors everywhere, all complaing that one of my classes was an ambiguous references with a system class. 522 errors. So I start qualifying my class reference. Which (understandably) is taking quite a while.
But then I had a thought. "What if I switch to var instead of an explicit class when I declare the variables?" (Which I tend to avoid as the maintainer - i.e. me - has to work out the type from context, which takes longer than an explicit typing.)
And what do you know? it works. With "var x = ...;" it works out what class it is from context. With "MyClass x = ...;" it doesn't ... For fawks sake MS!
Soo... not actually Visual Studio, but MSbuild or whatnot?
Visual Studio 2010 was the last usable version. Versions after that are too intrusive, definite productivity inhibitors.
-
Soo... not actually Visual Studio, but MSbuild or whatnot?
Visual Studio 2010 was the last usable version. Versions after that are too intrusive, definite productivity inhibitors.
@PIEBALDconsult Nope, it's VS. If you use a var, the IDE picks up on the context to work out for itself what the type is. If you explicitly state the type it will not even try to infer it from context.
Thinking about it that way, it makes some sense - but when you are faced with several hundred errors in a project that compiled fine in previous versions it's rather annoying ...
-
@PIEBALDconsult Nope, it's VS. If you use a var, the IDE picks up on the context to work out for itself what the type is. If you explicitly state the type it will not even try to infer it from context.
Thinking about it that way, it makes some sense - but when you are faced with several hundred errors in a project that compiled fine in previous versions it's rather annoying ...
Then what happens when you compile it outside of VS? Calling MSbuild from the command line?
-
Then what happens when you compile it outside of VS? Calling MSbuild from the command line?
@PIEBALDconsult Dunno - I never do that!
-
Sailing in the same boat here. Each new version of Visual Studio seems to come with more and more bloat. Up until around 2015–2017, it was still somewhat bearable. At this rate, people might just skip it altogether, install the .NET SDK, and use plain VS Code with a heavier command-line workflow. Maybe that’s the direction they’re nudging us toward with all this extra cruft!
-
Sailing in the same boat here. Each new version of Visual Studio seems to come with more and more bloat. Up until around 2015–2017, it was still somewhat bearable. At this rate, people might just skip it altogether, install the .NET SDK, and use plain VS Code with a heavier command-line workflow. Maybe that’s the direction they’re nudging us toward with all this extra cruft!
a heavier command-line workflow.
Because VS is so heavy, I consider my command-line workflow to be lighter, not heavier.
My primary use for VS is the debugger, but that's been giving me trouble lately, not loading symbols (VS 2017 Pro at work, I can't upgrade it or anything). Everything else VS provides is either "nice to have" or "I don't want that".P.S. Here at home, I have VS 2022 and one of the nicest-to-haves is Regular Expression coloring.
-
I've had VS 2022 go insane with small changes making huge numbers of errors that didn't make sense. I end up just restarting VS and reload the solution. Problem solved and sanity returned.
-
I know, I know - its the best dev environment out there. Just give me a minute.
I made a tiny, inconsequential addition to an old app (to cope with a new thought. Literally one line of code. ran it in the debugger, and tested it. Worked fine.
So I built it for release. And all hell broke loose. Errors everywhere, all complaing that one of my classes was an ambiguous references with a system class. 522 errors. So I start qualifying my class reference. Which (understandably) is taking quite a while.
But then I had a thought. "What if I switch to var instead of an explicit class when I declare the variables?" (Which I tend to avoid as the maintainer - i.e. me - has to work out the type from context, which takes longer than an explicit typing.)
And what do you know? it works. With "var x = ...;" it works out what class it is from context. With "MyClass x = ...;" it doesn't ... For fawks sake MS!
@OriginalGriff Do you mind sharing the version of VS you are using ?
I have a W7 machine running VS 2019 works fine for VB.Net & C# appsI have a new W10 machine and can not find a community edition of VS 2019
Considering VS 2022 or VS 2026 my concern is the evasiveness of AI in 2026
Your thoughts Paul or anyone else care to comment. Thanks in Advance -
I know, I know - its the best dev environment out there. Just give me a minute.
I made a tiny, inconsequential addition to an old app (to cope with a new thought. Literally one line of code. ran it in the debugger, and tested it. Worked fine.
So I built it for release. And all hell broke loose. Errors everywhere, all complaing that one of my classes was an ambiguous references with a system class. 522 errors. So I start qualifying my class reference. Which (understandably) is taking quite a while.
But then I had a thought. "What if I switch to var instead of an explicit class when I declare the variables?" (Which I tend to avoid as the maintainer - i.e. me - has to work out the type from context, which takes longer than an explicit typing.)
And what do you know? it works. With "var x = ...;" it works out what class it is from context. With "MyClass x = ...;" it doesn't ... For fawks sake MS!
@OriginalGriff This conversation reminds me of this video: VS2008 vs VS2026 speed (not the title of the video, but what the video is about)
-
@OriginalGriff Do you mind sharing the version of VS you are using ?
I have a W7 machine running VS 2019 works fine for VB.Net & C# appsI have a new W10 machine and can not find a community edition of VS 2019
Considering VS 2022 or VS 2026 my concern is the evasiveness of AI in 2026
Your thoughts Paul or anyone else care to comment. Thanks in Advance@Choroid I'm using 2022, having updated from 2019 when it came out.
The debugger was weird - it didn't work quite the same (becuase it's been reworked to better support multithread9ing, I think) and it took me a while to get used to it's new quirks in unthreaded apps.Some bits are really nice to have though - the AI suggestions also included sensible code fragments which can really speed your dev work once you are used to them - autocompleting foreach for example using context from existing code.
All in all, it takes some work to switch, but it's probably worth it. Just be careful when opening old projects or you are goign to get a shit-ton of new errors and warnings!
-
For my part, if visual studio starts getting slow I start eying the price of new hardware. Not that visual studio should drive hardware purchases per se, but when my computer can't handle it anymore, there are other things it no longer does as quickly as I'd like, like compiling large C/++ projects. So it's indicator for me that it's time for a change/upgrade. YMMV.
That being said, I am on VS2022. VS2019 or VS2022 (i think 2019) was the first one that shipped with a C++ compiler that would compile my C++17 standard code, so I won't use an earlier version. People say otherwise, but damn if Microsoft's attempts at providing a standards based compiler aren't hot wet garbage. Finally they've achieved something usable for me, so I'll put up with slowdowns just for that.
I don't need anything newer, and I paid for a license relatively recently as far as I am concerned so I'm hesitant to upgrade.
