Visual Studio 2022

Amanda

Visual Studio 2022 launch is here!


Join us at our free online event to celebrate the launch of Visual Studio 2022. Learn about what’s new, hear tips & tricks, participate in the live Q&As, and be the first to take the latest version for a spin.

 

All of our product development begins and ends with you—whether you posted on Developer Community, filled out a survey, sent us feedback, or took part in a customer study, thank you for helping to continue to steer the product roadmap for Visual Studio. I have exciting news—the first public preview of Visual Studio 2022 will be released this summer.

The next major release of Visual Studio will be faster, more approachable, and more lightweight, designed for both learners and those building industrial scale solutions. For the first time ever, Visual Studio will be 64-bit. The user experience will feel cleaner, intelligent, and action oriented.

Development teams have become more geographically dispersed than ever. It’s become apparent over the last year that organizations need their development teams to collaborate securely, deliver solutions more quickly, and continuously improve their end-user satisfaction and value. We’re making it easier to collaborate with better GitHub integration making it seamless to go from idea to code to the cloud.

Visual Studio 2022 is 64-bit

Visual Studio 2022 will be a 64-bit application, no longer limited to ~4gb of memory in the main devenv.exe process. With a 64-bit Visual Studio on Windows, you can open, edit, run, and debug even the biggest and most complex solutions without running out of memory.

While Visual Studio is going 64-bit, this doesn’t change the types or bitness of the applications you build with Visual Studio. Visual Studio will continue to be a great tool for building 32-bit apps.

I find it really satisfying to watch this video of Visual Studio scaling up to use the additional memory that’s available to a 64-bit process as it opens a solution with 1,600 projects and ~300k files. Here’s to no more out-of-memory exceptions. 🎉

64-bit VS opening 1600 projects

We’re also working on making every part of your workflow faster and more efficient, from loading solutions to F5 debugging.

Designing for everyone

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.

Visual Studio 2022 icon refresh

Personalization

Developer to developer, we understand that personalizing your IDE is as important as picking your desk chair. We have to make it “just right” before we can be at our most productive. It will be easier than ever to make Visual Studio 2022 “just right” for you, from the ability to customize aspects of the IDE to syncing settings across devices for those who maintain multiple dev boxes.

Developing modern apps

Azure

Visual Studio 2022 will make it quick and easy to build modern, cloud-based applications with Azure. We’ll get you started with a good supply of repositories that describe common patterns used in today’s apps. These repositories are made up of opinionated code showing these patterns in action, infrastructure-as-code assets to provision the Azure resources, and pre-built GitHub workflows and actions setting you up with a complete CI/CD solution when you first create a project. Plus, the required development environment will be defined in the repository so that you can start coding and debugging right away.

.NET

Visual Studio 2022 will have full support for .NET 6 and its unified framework for web, client, and mobile apps for both Windows and Mac developers. That includes the .NET Multi-platform App UI (.NET MAUI) for cross-platform client apps on Windows, Android, macOS, and iOS. You can also use ASP.NET Blazor web technologies to write desktop apps via .NET MAUI.

.NET MAUI app types

And for most app types like web, desktop, and mobile, you’ll be able to use .NET Hot Reload to apply code changes without needing to restart or lose the app state.

.NET Hot Reload in action

C++

Visual Studio 2022 will include robust support for the C++ workload with new productivity features, C++20 tooling, and IntelliSense. New C++20 language features will simplify managing large codebases and improved diagnostics will make the tough problems easier to debug with templates and concepts.

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. If you want to upgrade to Visual Studio 2022 but are worried about compatibility, binary compatibility with the C++ runtime will make it painless.

Innovation at your fingertips

Diagnostics and debugging

The ability to confidently debug your applications is at the center of your daily workflow. Visual Studio 2022 will include performance improvements in the core debugger, with additional features like flame charts in the profiler for better spotting the hot paths, dependent breakpoints for more precise debugging, and integrated decompilation experiences which will allow you to step through code you don’t have locally.

Real-time collaboration

Live Share opens new opportunities for collaborating with others, exchanging ideas, pair programming, and reviewing code. In Visual Studio 2022, Live Share will introduce integrated text chat so that you can have quick conversations about your code without any context switches. You’ll have options to schedule recurring sessions that reuse the same link, simplifying collaboration with your frequent contacts. To better support Live Share within organizations, we’ll also introduce session polices, that define any compliance requirements for collaboration (e.g. should read/write terminals be shareable?).

Insights and productivity

The AI IntelliCode engine in Visual Studio continues to get better at seamlessly anticipating your next move. Visual Studio 2022 will provide more and deeper integrations into your daily workflows, helping you to take the right action in the right place at the right time.

Whole word completion

Asynchronous collaboration

Visual Studio 2022 will include powerful new support for Git and GitHub. Committing code, sending pull requests, and merging branches is when “my code becomes our code.” You’ll notice a lot of built-in logic and checkpoints to guide you efficiently through the merge and review process, anticipating feedback from your colleagues that could slow things down. Our guiding principle here was helping you to have higher confidence in the code you deliver.

Code search is an integral part of the software development lifecycle. Developers use code search for lots of reasons: learning from others, sharing code, assessing the impact of changes while refactoring, investigating issues, or reviewing changes. We’re committed to delivering better performance for all these critical activities in Visual Studio 2022 to make you even more productive. You will also be able to search outside your loaded scope, to find what you’re looking for no matter what code base or repo it’s located in.

Refreshing Visual Studio for Mac

Our goal with Visual Studio 2022 for Mac is to make a modern .NET IDE tailored for the Mac that delivers the productive experience you’ve come to love in Visual Studio. We’re working to move Visual Studio for Mac to native macOS UI, which means it will come with better performance and reliability. It also means that Visual Studio for Mac can take full advantage of all the built-in macOS accessibility features. We’re updating the menus and terminology across the IDE to make Visual Studio more consistent between Mac and Windows. The new Git experience from Visual Studio will also be coming to Visual Studio for Mac, beginning with the introduction of the Git Changes tool window.

Let us know what you think!

We’ve only shown you a few highlights of our work in progress, but we welcome your initial thoughts on the direction we’re taking for Visual Studio 2022. As always, you can head on over to the new Developer Community to browse through existing feature requests to upvote and comment or create your own.

Stay tuned for announcements about the 64-bit Visual Studio 2022 Preview 1 availability, which will include our UI refinements and accessibility improvements. (And remember! Like any work in progress, these features are still in development, so some of them will be coming to Visual Studio 2022 after the first public release.)

Thank you!

 

Editor’s Note: The post was originally published on 4/4/21 and was updated on 7/16/21 to add a note that Visual Studio 2022 Preview has been released.

429 comments

Comments are closed. Login to edit/delete your existing comments

  • Tony Henrique

    That is great! Looking forward to use Visual Studio 2022 and .NET 6!

    (Suggestion for Cascadia Code parenthesis (): I think they could get a little adjustment to look more like Consolas)

    • Carlos Henrique Carniatto

      I have stopped using windows and Visual Studio for programming as I was having a lot of headaches with VS and Windows Defender, but what I wanted to know is if Microsoft has any plans for a decent port of VS to Mac os, as VS Code when talking about Blazor I find it lacks a bit of features and Visual Studio for Mac os is really bad.

  • leoniDEV

    “Visual Studio 2022 will include powerful new support for Git and GitHub.”

    But we lost the support for Azure DevOps… 😞

    • PandaSharp

      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)

    • Steven Bone

      I, and others, have asked if/when SourceLink would be supported for Azure DevOps (non-Git TFVC), and there have been no responses to these lines of inquiry, though many other comments have received replies. Reference the blog posts Improving Debug-time Productivity with Source Link and ‘Producing Packages with Source Link‘. Other tools that work with TFVC, such as the Power Tools and Shell Extension have been unsupported for VS2019, with the claim being made that the functionality of the power tools were moved into the command line (which is not the case for a number of them). 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.

    • Greg Wojan

      Losing support for Azure DevOps would be horrible! Is this really true?

    • Pratik NadagoudaMicrosoft employee

      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.

      • Steven Bone

        Please see my above comment as to the lack of Source Link support for Azure DevOps (TFVC), and other tooling, and please explain how this is relates to ‘continue to support our devs and scenarios using Azure DevOps’. I git that you are enhancing parts of the experience, but please don’t do so at the cost of ignoring others that devs are (and have been) relying upon.

      • Burton Rodman

        I feel like your team should take off your rose-colored glasses and actually try to use VS against AzureDevOps/TFVC in a real project sense — acknowledging that some CANNOT transition to Git at this time — and then tell us how great things really are. I’ve reported several real regressions that were promptly closed as “not enough customer impact”. I’m fine that you’re focusing on improving the Git experience — just stop breaking the TFVC experience in the process — and when you do, actually fix it.

        • Ian Yates

          We are still Dev Ops with TFVC. It’s easier to understand for some of our team that aren’t coders but need to contribute some files. It’s also what we had when we migrated from on-prem TFS.
          It’s OK, but we do have the auth issue hanging around where we’ll be told we are not permitted to check in code. Happens randomly, but once it has happened it stays stuck that way. We used to have to restart VS to fix but now just flick back to the home panel of source control and click the little refresh button. That seems to refresh the auth token and allows check-in to proceed again.

          It’d be nice to get things like source link for us.

          • Pratik NadagoudaMicrosoft employee

            We’re still committed to support TFVC in Visual Studio. If you experience any regressions, please report them on Developer Community. Our team will make sure they’re correctly triaged and addressed.

          • Paul Guz

            @Pratik Nadagouda, the issue that Ian Yates refers to is already open in the Developer Community, and has been for years. There are hundreds of responses to it, confirming it remains a widespread problem in Visual Studio with TFSVC. These responses are being largely ignored.

            TFSVC is painfully slow these days. It would be good if you guys would just admit that TFSVC is a deprecated technology.

          • Henry Jimenez

            It’s really simple. They don’t care and they don’t want to tell you. It’s been that way for years.

      • Gavin

        To be honest, you ripped out all the built-in integration with DevOps. The ‘new’ Git experiences are basically just the Git window from before, but with zero integration. It’s a pretty miserable change. I can only assume that after dropping a couple of billion on GitHub there’s a lot of pressure to make it look like a success.

      • PandaSharp

        Correct me if I’m wrong
        – New GIT integration lacks PRs and Work Items integrations with ADO (with GIT), that are possible with GH.
        – VS recently added GitHub actions tooling, but no Azure Pipelines

        • Gavin

          Yep, they’re claiming it’s a ‘new’ integration but as far as I can see it’s almost functionally identical to the old Git integration, they’ve just burned all the DevOps integration. It’s very sad.

        • PandaSharp

          I just noticed one more thing, when you click on `create git repository` there is only github and no ADO

      • Asbjørn Riis-Knudsen

        Sorry, that’s just not true. Look at the dialog you get when creating a new Git repository from VS. It offers to publish to GitHub, but not Azure DevOps, like the old dialog did. It is pretty clear that Azure DevOps is being de-prioritzed in favor of GitHub. I expect to see it closed down in favor of GitHub eventually, given that there has been virtually zero investment in Azure DevOps in the past year or so – just look at the sorry state of the roadmap (https://docs.microsoft.com/en-us/azure/devops/release-notes/features-timeline). I just wish you would come clean and say what your plans are.

        • Gavin

          About 18 months back we had a Microsoft evangelist visit the company I was working for and he explicitly said that GitHub was going to be the future, and that our (large enterprise) should plan to move to GitHub.

          I was horrified and checked with a colleague who now worked for Microsoft and he confirmed that this was Microsoft’s position. He said that MS would continue to support DevOps but they wanted to get enterprises to move to GitHub.

          GitHub is essentially just Repos and a bit of Pipelines. The fact that Microsoft is having to remove existing, already developed integrations in order to try to push people away from DevOps to GitHub is telling. Given that DevOps is already at the end-game for GitHub what’s the point?

          We have no plans to go to GitHub, the open source fans in the company have all moved to GitLab anyway so we certainly wouldn’t be moving to GitHub.

          • PandaSharp

            Totally agree Gavin, also we’re using ADO, and there is no way (at least in the short run) that GH can replace ADO for us (repos, boards, pipelines, test, azure AD…)

          • Rune Moberg

            Before ya’ll move to GitLab… Make sure you evaluate how pull requests function in that environment. I have a suspicion that GitHub is better (although not by much). GitLab is a horrible mess compared to how Pull Requests are implemented in TFS 2017.

            Another GitLab disappointment is their Nuget repository. They haven’t even bothered implementing descriptions, so when you browse the repository none of the nuget packages hosted there will have anything in the Description.

            Things you might take for granted elsewhere might not be so easy/supported in GitLab — even if you pay for their “Premium” product.

            So make sure you identify the areas you care about, and then evaluate those thoroughly. I think you will be surprised.

            My old team members certainly misses TFS, and we were still on an older version. Jira + GitLab is a very poor replacement. WIth TFS you could tell that much thought was put into each feature before it was released.

            That said: Git all the way all day long. I do not miss TFVC one bit. YMMV.

          • PAthum Bandara Premaratne

            It’s just Microsoft went to imitation from innovation…. And they’re in the process of killing their own innovations in favor of others. There were standards, quality & class in M$ but now that’s all gone. TFS may the newest but not the last. Seems like they are not gonna stop until they kill windows too… And it’s already started btw.

      • simmse

        All business users of the formerly named TFS, now named Azure DevOps Server, will demand the on premises integration to continue. If that does not happen, customers will not use Visual Studio 2022. It is as simple as that. Please keep this in mind when implementing Azure DevOps integration in Visual Studio 2022.

        • PAthum Bandara Premaratne

          They want everything in their cloud…. Keep us feeding their money making cow…. Cloud is a trap…. To keep us locked into them they’re killing onprem tech one by one….

        • Clint StLaurent

          Totally agree. So many of their moves over the last few years to me feel like a shift away from enterprise customers to small outfits. They don’t care about the companies with 300 developers. They’re more interested in 300 companies with 3 guys each.

          You can see that in how they would rather pander to the web-devs than actually fix functionality issues in Xamarin (oh look: HTML page creation instead of XAML: But the controls don’t work any better). Then rebrand everything so it seems new. Xamarin becomes MAUI. TFS becomes DevOps. But again, nothing works better just named different.

          It almost feels like they are deliberately keeping companies off balance so they are so busy changing with the times they don’t have time to realize that nothing new or innovative is actually happening.

          Companies like mine with devs in 6 cities, 50 people each… numerous 3rd party and in-house TFS integrations for story tracking and management aren’t going to throw all that away for “repos”.

    • Gavin

      Yep, while they’re slowly trying to port a fraction of the functionality of Azure DevOps over to GitHub (Actions, anyone?) they’ve decided to essentially EOL their own SDLC product which is already offering what so many other solutions promise as their ultimate future endgame.

      The irony here is that the cool kids they’re so desperate to woo have all run off to GitLab anyway. I’d love it if DevDiv could recall that they already have an incredible end-to-end SDLC solution and go support that.

    • Guido Geurts

      does this means we can no longer user tfs ?
      If so, than go the who ever thought if this and ask him what hobby’s he is having
      Then tell him to search a job in that direction
      Because computers and IT is not for him, that can never work…

      • simmse

        I hope that is not the plan. Many businesses will not accept dropping TFS integration. Who wants their proprietary source code away from the business owned computer systems?

        • Kenneth Beaton

          We moved to git from TFS a year ago (but we had not invested much effort in TFS for years – just using it for source code control).
          Surprisingly we were able to migrate the history as well.

          But git simply is not as good – two stage check in/check out; problems merging files.

          We moved to a private cloud instance of git (though could equally have moved to on premises). GitHub may be great for home/hobby use, but I cannot imagine risking important proprietary code there.

        • Pratik NadagoudaMicrosoft employee

          Visual Studio 2022 will indeed support Azure DevOps Server (on premises). Please let us know through Developer Community if you see any regressions for the integration as we release preview versions of VS 2022, so that we can catch and address any issues quickly. Thanks!

    • Christopher Pursley

      This is deeply concerning. As a team lead, I literally just fought to have my whole company convert over to Azure DevOps. It was expensive and painful but I counted it a success. If less than 6 months after we have completed our migration, it’s announced Microsoft is pulling support in VS, we might just start need to move away from Microsoft altogether. As developers, we can’t keep putting our trust in a company that disregards the huge investment of time, energy and money we put in to adopting their technologies. It feels like Microsoft has little concern of the impact these decisions have on our companies, lives and careers.

    • x x

      For Windows development? That would be masochistic 🙂
      They invented 6 kinds of string types (String, Str, CString, Cstr, OsString, Ostr), maybe if they decided on just one, they would have time to write a proper tooling for VSCode.

      • 外山高裕

        I believe that rust support is very promising.
        I’m using the WIN32 API and INtime RT OS. I’m currently accessing them through C++17, and frankly, our C++17 development experience sucks.

      • Luke Chu

        I don’t believe you have used Rust before, at least in a serious project. CString, Cstr are only used to deal with the mess created by C/C++. OsString and OsStr is to deal with the mess on Windows because Windows does not use UTF-8. As long as you are not dealing with C FFI or windows APIs, you would only need String and str. And that is much better than C++’s std::string, std::string_view, char*, std::wstring, hstring, and all the other strings provided by Windows and boost and whatnot. Just look at this to see what I mean.

        In fact, I find Rust’s differentiation between String and str making a lot of sense. It requires minimal cognitive load to handle and does not force strings to be immutable which is bad for performance.

  • Edhy Rijo

    Hi Amanda,
    This is just great!

    Thanks for listening to the community and keep making all the investments in new tech for all of us.
    Greatly appreciated!

  • André Ziegler

    Hopefully updating of VS extensions works without restarting the VS (extensions must be out of proc).

    Also the new icons look even more worse. Best clarity, legibility, and contrast had the VS2010 icons, they were perfect.

    • Andy Patrick

      Agreed. Just look at the green tick and the red cross. Why are the tick and the cross smaller and harder to make out? Who decided to waste a bunch of time on that?

    • Muhammad Miftah

      I agree, and I also loathe all of this ‘change for its own sake’ silliness. They could go back to the same icon style used in Visual Studio 2010 and nothing about the app’s usability will change.

    • Eric Kassan

      I, for one, am thrilled they finally flipped the floppy disk save icon upside down- that was super-important in my work. NOT! How does MS see fit to waste time on such “work”? Do they have horrible employees they can’t fire and can’t trust with important stuff, so they have them spend time on icon updates (and with no one trustworthy reviewing their work)?

    • Chiramisu

      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! 😉

    • Jason Hurdlow

      Agreed. The new icons have worse contrast than the existing ones, and look ‘fuzzy’ by comparison.

    • Cesar Maroun

      And also best check-in experience. The experience that started with 2012 is still simply horrible and time wasting and very clumsy. They are not really listening… I still have an 2010 installation only for TFS operations (for example, when there are no changes it shows a popup saying that, but in 2019 it still opens the files side by side and force you to deduct they are identical, and more and more, very stubborn VS architects!)

  • David N

    If it’s coming with Cascadia Code does that mean full ligature support at last? I’m thinking of ‘->’ and ‘<-' which just don't work in the current version (including preview). That would be popular with F# developers 🙂

        • Stuart Lang

          This has been requested for years and it’s only going to become more obvious with a ligature font shipped out of the box, please can we have a fix for this 🙏

        • Adam Marciniec

          Maybe if you can get in touch with the company who develops WPF they could make this happen. 😉

        • David N

          I had heard that before. But maybe VS 2022 will move to .net 6 itself, and maybe that means WPF can get fixed at last? I try to stay optimistic 😊🤞

  • Michael Taylor

    This is good to hear. Just please learn from the mistakes of previous VS releases and don’t do any UI changes that are “current” from MS but not really liked by the dev community. Think back to the compact menus, lower case menus and Start Window craziness. Any major changes to the UI needs to have options to allow folks to make it look similar to the way it did before.

    Also remember that many companies are not marching to the “latest and greatest” stuff from MS so support for MVC 5, web forms, .NET framework and other “old” technologies needs to be supported.

    I’m particularly excited about LiveShare supporting recurring, unchanging sessions. This solves the problem I have today where every class I have to share a new link to LS for my students. Just please make it stable. LS has been anything but stable over the years. Every semester begins with a “what doesn’t work” session. Sometimes students cannot see updates, other times I cannot debug, yet other times I cannot edit. Stability needs to be paramount.

    Finally 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.

    • Leslie RichardsonMicrosoft employee

      Thanks for your feedback Michael! To respond to your extensibility question, 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.

      • MgSam

        @LeslieRichardson Will you guys be providing an update on the Extension API redesign you solicited feedback for last year? Really hoping to see Visualizers become first-class Extension features.

      • Yann Duran

        Leslie, are you saying that extensions compiled for AnyCPU won’t support 64-bit?

    • Clint StLaurent

      MAUI is just the new incarnation of Xamarin. If you’re excited to use it, you should have started using it by now – or for the last 5 years.