News

Hundreds of Developers Sound Off on Visual Studio 2022

• By David Ramel
• 04/20/2021

Based only on a sneak peek of an upcoming preview, hundreds of developers have weighed in with strong opinions on what's coming with the milestone Visual Studio 2022 release.

VS 2022 was introduced April 19, with Microsoft promising a leaner, faster and 64-bit IDE. The 64-bit surprise was a leading topic of developer discussion in comments to the announcement post as well as on the Reddit and Hacker News developer-oriented forums. Those three sites alone combined for more than 700 comments (and counting as this is being written).

Other hot topics were support (or perceived lack thereof) of Azure DevOps, along with Linux, the legacy .NET Framework, and even refreshed icons.

Here's a sample of what readers had to say.

64-bit
Comments on this were primarily of "what took so long" nature. Many were also concerned with VS extensions that would need to be updated.

• I'm sure a lot of people will be happy with the 64-bit VS version. But that means none of the existing extensions we have will work anymore which means a likely long wait for extension authors to update (if they ever do). I'm also concerned that MS has spent a lot of time moving workloads out of process to resolve the memory issues at the cost of speed and reliability. Switching to x64 means my VS instances (of which I can run several) can easily grow out of control but if that means more stability because of less out-of-proc work then great.

  A Microsoft dev responded: "We are aware that all extension authors will need to migrate their extensions to 64-bit in order for you to successfully use them in that version. We're currently working on guidance for extension authors to migrate successfully and quickly in time for 64-bit VS's general release."

• 64bit cannot happen soon enough. I have to restart VS 2019 multiple times a day working with Blazor WASM and no extensions because VS freezes while debugging and the memory of devenv.exe hovers at 2gb.

• Commenting on a GIF/video that shows a solution being opened with 1,600 projects and 300,000 files: That's what is scary actually... Instead of working extremely hard to reduce that usage of memory, say by 20% or more, you just cheat by providing more memory space.

  

  Long gone are the times when developers at Microsoft tried to make their software do more on much less powerful hardware, were able to do so, and the whole thing could run with only ~100 MB of memory!!

• Congratulations on finally taking the 64-bit leap. It only took 18 years after the first 64-bit release of Windows back in 2003! Sorry, couldn't resist that little dig – I am genuinely grateful and excited that things are progressing in the right direction 😀

Icons/UI
Microsoft's announcement post said:

We're refreshing the user interface to better keep you in your flow. Some of the changes are subtle cosmetic touches that modernize the UI or reduce crowding. Overall, we aim to reduce complexity and decrease the cognitive load so that you can focus and stay in the zone. Also, making Visual Studio more accessible delivers better usability for everyone – the next version of Visual Studio will include:

• Updated icons for better clarity, legibility, and contrast.
• Cascadia Code, a new fixed-width font for better readability and ligature support. (If you like, you can try Cascadia Code today! https://aka.ms/CascadiaCode)
Refreshed and improved product themes. Integration with Accessibility Insights to detect accessibility issues early on—before they get to your end-users.

As to be expected (developers love their icons), the icons were on the minds of many developers:

• The new icons look even more worse. Best clarity, legibility, and contrast had the VS2010 icons, they were perfect.
• I actually think the 2010 icons are a bit dated and prefer those in 2019, but we can definitely agree that the new 2022 icons are hideous!
• Agreed. The new icons have worse contrast than the existing ones, and look ‘fuzzy' by comparison.
• I do like the refreshed icons / design though and always appreciate it when you guys tackle these small details. I'm also excited to see what ui customization options will be available in the next version. I'd love to see a way to change colors without having to use an extension.

Speed, Performance and Reliability vs. New Features
Many developers said they would prefer a focus on improving and fixing existing functionality instead of concentrating on introducing new features:

• I have mixed feelings about this. Everything sounds good, however I feel it could be as buggy as VS2019 or worst. Delivering a solid code editing experience would be enough for me.
• After the release, it would be good if you stopped all the new development and have a break. We don't really need that many new features. Focus on fixing all the bugs in the backlog for a couple of of months. All of them. Hi and low prio. All the productivity improvements made by new features are actually cancelled by all the bugs and times I need to restart VS or even the machine.
• Unfortunatelly they are focused at adding (buggy and slow) features, as this is main reason for charge money for ‘new version'
• All these are excelent, but please put some more effort on performance. You guys did a great job on making openning solutions faster, keep working on that and do the same for all actions.
• I don't think we need that many new features all the time. Performance and stability are the main features needed at the moment.

Azure DevOps
Much discussion ensued about this comment:

"'Visual Studio 2022 will include powerful new support for Git and GitHub.' But we lost the support for Azure DevOps..."

That resulted in comments like:

• I was going to comment the same, I love the GitHub support, but we love and use also Azure DevOps, VS cannot move all the attention away from Azure DevOps (with GIT)
• The sad fact is that many of us can't move to Git without impacting many years of process and tooling. I can't imagine that a small investment in making Source Link work (when I imagine most of the code required already exists from the Azure DevOps Index Sources build task) is an unreasonable ask.
• Losing support for Azure DevOps would be horrible! Is this really true?

Microsoft responded: "That's not true! We continue to support our devs and scenarios using Azure DevOps. It already has and will continue to have great Git integration in VS. You can see how we're supporting Azure DevOps repositories in our new Git experiences. In the past, the GitHub support has been lacking in the IDE and that's why you're hearing more news about the increasing GitHub functionality from us as we build it out. You can also take a look at the Azure DevOps roadmap."

.NET Framework
Several comments about the old Windows-only framework concerned whether it was still supported (the answer, many times, was "Yes"). Also, surprising to this reporter, was the statement from Microsoft's Mad Kristensen in reply to this question:

"Will it be a .Net 6 application or still old tech? Would be good if you used new .net 6 to make use of speed improvement and a bit of dog feeding. Using WPF? Or .net MAUI?"

Kristensen replied: "Visual Studio 2022 will continue to run on .NET Framework using primarily WPF." Readers commented:

• MS has all but announced that NF is dead and .NET 5 is a 'seamless' transition that existing NF apps should use unless they rely on an unsupported tech like WCF Server. It is surprising that VS isn't going to target .NET 6 as that means it is running on a deprecated technology. I think it would be a very interesting blog if somebody on the team wanted to explain the challenges of moving VS to NET 6 and why VS isn't going to be doing so. Many teams are asking the same questions the VS team did I'm sure – size of the app, risks involved in conversions, ROI, unsupported features, etc. I'm even more interested in the NET team's response to these issues and what they are going to do (and the timeframe) to make it easier to migrate VS over. Given the 2-3 year lifetime of VS versions that would mean VS is going to be skipping NET 5/6 and probably 7.
• What's holding back Visual Studio from switching from .NET Framework to .NET 6? If it's backwards compatibility, I personally would be happy with just using older versions of VS for older project types. With WPF officially supported in .NET 6, that's one less barrier. Plus with all the performance improvements implemented in .NET Core over the years, it seems like a no brainer. Would it be the next big priority after the 2022 release?
• Since Visual Studio 2022 is moving to 64-bit, why not move to .NET 6 to embrace the performance and overhead improvements? Also, .NET 6 is a LTS version and it already has .NET Standard, C++/CLI and WPF support, so I think the compatibility won't be a problem. I've created a feature request on Developer Community: https://developercommunity.visualstudio.com/t/Move-Visual-Studio-2022-to-NET-6/1402400

Linux
Linux was mentioned only once in the announcement post, in the C++ section: "We're also integrating support for CMake, Linux, and WSL to make it easier for you to create, edit, build, and debug cross-platform apps."

It was mentioned many times by developers commenting on the post and on Reddit:

One comment read: "According to http://www.statista.com 48% of software developers use linux. Visual Studio's lack of linux support is massively hurting microsoft."

Microsoft's Tim Heuer replied: "We've added new support for leveraging WSL and Linux containers to enable you to do things like debug in Linux from your Windows environment, or running test suites targeting Linux all from Visual Studio."

Other comments included:

• You can run Visual Studio Code on Linux, you can develop .NET 5/.NET 6 applications with the .NET SDK and the VS Code C# extension.
• Windows Version , Mac Version…
  And the Linux Version
  Visual Studio 2025 maybe?
• It's nice that it can build for Linux targets, but I wonder if they're ever going to release a Linux version of VS
• I wonder if they will allow for remote debugging on Linux. With Azure being Linux primarily it can be hard to deal with the lack of remote debugging.

ARM Support
This was mentioned by several developers commenting on the announcement post and on Hacker News:

• Would be nice to know if 2022 is future proofed for ARM64.
• I hope this is one step closer to ARM64 support!
• Make sure it will run natively on Windows on ARM.

In reply to that last comment, Microsoft's Andy Sterland replied: "There is a developer community suggestion for native ARM support: https://developercommunity.visualstudio.com/t/native-arm-support-for-visual-studio/1161018. Please vote on it, and anyone else reading this who needs a native ARM VS!"

Such votes, and other feedback, can be sent to Microsoft's Developer Community.