I’m a huge fan of Visual Studio – it’s by far the best IDE I’ve ever used. I’ve used it for C++ development on several platforms (mainly Windows and Sony consoles but most recently Windows and Linux using a shared codebase and cross-compiling then debugging various targets running on x32, x64 and ARM chipsets though the one IDE and PC).
I’m still in the early stages of getting to know VS 2022. Superficially it looks very much like VS 2019, at least to someone who uses it mainly for native C++ development, but if the whole IDE has indeed been updated to run natively as a suite of 64-bit processes then that’s quite some engineering feat in itself.
It feels a little quicker than 2019, though I’m not sure if that’s just an illusion from my assumption that all of its processes are now free to address the whole of whatever memory is available on a modern PC.
Adding new features probably wasn’t high on the list of goals for this release given the wholesale upgrade and the risks that must have introduced. I’m really rather glad as I’m a big fan of the adage ‘don’t fix what isn’t broken’ – very important when tools of the trade are concerned. Certainly most of the things I’ve loved about Visual Studio since its last major (and quite brilliant) revamp in 2015 seem largely unchanged.
I’m finding quite a few niggles and bugs, though, and some of them are really quite bad considering this is a release branch, with at least one update I can remember applying.
Where does one report bugs and feature requests to Microsoft these days? I have no idea… I’ve tried @VisualStudio on Twitter once but that almost certainly isn’t the correct avenue, so for now I’ll list them here in the hope that some Microsoft spider will find them and take them back to its bug-stash in the cloud where they can be expeditiously ignored:
All of the below are present in…
Microsoft Visual Studio Community 2022 (64-bit) – Current Version 17.1.6
… and for the record, I’m currently developing using CMake rather than a .vcxproj based project.
- Diagnostic Tools window prevents the edit/code window gaining focus when hitting a breakpoint:
This one is really annoying. The Diagnostics Tools window is enabled by default. This window can take so long to finish initialising when debugging a simple Win32 console application that it often hasn’t finished drawing its graphs and controls until some time after your program has been running. This messes up debug focusing when you hit a breakpoint in a console application: neither the console window nor the editor window are focused. Instead, it seems the focus when hitting your breakpoint needs to be on that Diagnostic Tools window, leaving your IDE’s editor window, with that all important breakpoint arrow and red dot, to finish a poor third behind (and I really do mean ‘behind’) your console window.
- Diagnostic Tools window not staying closed:
This is more bad design than bug, but I don’t recall this behaviour from VS 2019 and I only discovered it when trying to find a workaround for the previous bug:
Closing the Diagnostic Tools window when debugging is remembered between debug sessions but not between successive IDE sessions (i.e. after closing and restarting the IDE), unlike changes to visibility and position for nearly every other IDE component which persist between restarts. This unique behaviour seems to be be triggered by a hidden toggle in Tools->Options->Debug called ‘enable Diagnostics Tools whilst debugging’. I don’t know why this is needed when there is a perfectly good ‘Show Diagnostic Tools Window’ option in Debug->Windows where it has, unless I’m mistaken, been since the dawn of time (i.e. circa late 2014 in my modern Visual Studio calendar).
I strongly advise you to disable that checkbox in the options menu until the focusing problem mentioned in my first bug has been addressed.
- Typing three forward slashes into an editor window causes this to appear in my source code:
/// <summary> /// /// </summary> /// <returns></returns>
This happens when editing files with .CPP and .H extensions. I don’t really want this markup in my files and I already use multiple forward slashes to delimit my function and file headers. This new, built-in (or at least enabled-by-default) behaviour now prevents me from typing my own– instead I have to copy and paste my lines of ‘////’ from elsewhere. This behaviour wasn’t present in previous versions of Visual Studio and it also interferes with much better functionality offered by third party add-ons. I can’t yet see any obvious way to switch this annoying ‘feature’ off (if it is such – for now I have to assume it’s just a plain and dirty bug!)
- Visual Studio with Visual Assist. Sadly many problems spoil the interaction between a great IDE and one of its best (dare I suggest indispensable? I think so…) add-ons:
Visual Assist when installed for VS 2022 doesn’t import its options from previous Visual Studio installs (these are saved in the registry if I remember). This is a gripe with Whole Tomato, too – it’s your software. Some aspects of Visual Assist don’t even work correctly unless I run Visual Studio 2022 with administrator privileges every time I start it (highlighting of read and write references for the current symbol being one such example). Visual Assist is a fantastic productivity aid, but its VS 2022 support is poor at present.
I have no idea how the managed side of development (managed C++ and other .NET languages) are with the new 64-bit IDE. .NET isn’t a land I venture into often but I don’t doubt I will need to write some managed wrappers for my library code at some point soon. For the moment I have to assume all is great with Visual Studio 2022 in .NET-land.
That’s all for now. First impressions are that insufficient testing of the software happened before release, at least as far as native C++ development and support for existing add-ons is concerned. I shall post more bugs on this page as I find them though I realise that my history of (not) updating this website is hardly conducive to keeping that promise…
Update – July ’22
I’ve been rather busy these last few weeks preparing to release some free C++ library code into the wild – more on this soon – so I haven’t been back to post an update to say that Visual Studio Community Edition 17.2.0 fixes point 3 (markup) and, I’m fairly sure, point 1 (annoying diagnostic tools focus problem), so many thanks to Microsoft for a speedy resolution, even if those issues were already on their bugs list from other sources before I reported them here (and I jolly well hope that they were!) I’m back to enjoying writing C++ with Visual Studio again.