Visual Studio 2022

Amanda Silver

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


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


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.


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


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.


Discussion is closed. Login to edit/delete existing comments.

  • Tony Henrique 0

    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)

    • anonymous 0

      this comment has been deleted.

    • Carlos Henrique Carniatto 0

      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.

  • Igor Popov 0

    This is beyond amazing! Thank you!!!

  • leoniDEV 1

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

    But we lost the support for Azure DevOps… 😞

    • PandaSharp 0

      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 0

      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 0

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

    • Pratik NadagoudaMicrosoft employee 0

      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 0

        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 0

        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 0

          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 0

            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 0

            @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 0

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

          • Pete Wilson 0

            Reminds me of the .Net Framework story…

      • Gavin 0

        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 0

        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 0

          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 0

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

      • Asbjørn Riis-Knudsen 0

        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 ( I just wish you would come clean and say what your plans are.

        • Gavin 0

          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 0

            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 0

            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 0

            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 0

        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 0

          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 0

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

          • Dee You 0

            hell yaaa my man

    • Andy Patrick 0

      What??? PLEASE say this isn’t true!

      • anonymous 0

        this comment has been deleted.

        • Honey Gamer's 0


    • Gavin 0

      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 0

      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 0

        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 0

          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 0

          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 0

      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.

      • Dee You 0

        i agree i feel same as you my man

  • Patrick Hintermayer 0

    Any plans to support Rust?

    • x x 0

      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.

      • 外山高裕 0

        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 0

        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 0

    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 0

    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 0

      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 0

      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.

      • James Foye 0

        What I would give to have the VS 2010 icons back!

    • Eric Kassan 0

      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)?

      • Gavin Williams 0

        You’re kidding right?

    • Chiramisu 0

      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 0

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

    • Mads KristensenMicrosoft employee 0

      You still need a restart since the extensibility model and -installer aren’t changing just yet.

    • Cesar Maroun 0

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

  • Ion Sorin Torjo 0

    Finally, looking soooooo forward to this!

  • David N 0

    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 🙂

    • Mads KristensenMicrosoft employee 0

      Yes, ligatures are supported. You’ll see them in the latest Visual Studio 2019 if you install Cascadia Code too.

      • Oleg TkachenkoMicrosoft employee 0

        David, unfortunately specifically hyphen based ligatures are not supported by WPF yet, see

        • Stuart Lang 0

          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 🙏

          • Payton Byrd 0

            Shouldn’t WPF be moving to the new XAML editor?

        • Adam Marciniec 0

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

          • James Foye 0

            Lol, good one.

        • David N 0

          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 0

    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 0

      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 0

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

        • Leslie RichardsonMicrosoft employee 0

          We’re still working on the new extensibility model/API redesign and we hope to share a larger update on it after 64-bit VS’s general release. Your visualizer ask is noted however!

          • saint4eva 0

            Thank you, Leslie.

      • Yann Duran 0

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

        • Mads KristensenMicrosoft employee 0

          AnyCPU will support 64-bit VS

          • Shah Tirth 0

            Which is actually date relase date of Visual Studio 2022 ?

  • Salman Chishti 0

    This is brilliant, super excited to use MAUI!

    • Clint StLaurent 0

      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.

  • Steven Bone 0

    If this were posted 19 days ago, I would have thought this to be a 100% joke, though a sad one, because I’ve heard nothing but ‘we can’t do 64 bit’ for years. I’m very surprised!

    • simmse 0

      Yes. I think that answer covers +/- two decades.

  • MgSam 0

    I am shocked and thrilled to hear you guys are finally making a 64-bit VS! After a decade, literally thousands of developer requests (which have been closed over and over again) and all the bogus technical explanations for why 64-bit was impossible and undesirable, I had just about given up hope of this ever happening.

    • James Hood 0

      Maybe we should ask them to open source their excuse generator?

      • Mike-E 0


  • Tanvir Ahmad Arjel 0

    64 bit Visual Studio! 😲 Dream finally coming true. However, I have a curious question, which IDE is used by the developers those who are writing code to develop Visual Studio?

    • Mads KristensenMicrosoft employee 0

      Visual Studio is written in Visual Studio. Most internal developers use the latest CI build of Visual Studio.

      • Tanvir Ahmad Arjel 0

        Thank you so much, Mads!

  • Robert van der Hulst 0

    This is great news.
    Please make sure that 3rd parties get the chance to get their VS extensions ready for this new release by starting a 3rd party test program.
    It would be a shame if the release of VS 2022 would get negative feedback because of missing or failing extensions.
    And yes, my company also creates an extension to VS.


    • Leslie RichardsonMicrosoft employee 0

      Hi Robert, we’re currently establishing general guidance for migrating your extensions to 64-bit successfully in time for the new release and we’ll publish that guidance around the Preview 1 timeframe. To make sure you’re notified about that guidance, would you be willing to share your contact info with me via LinkedIn?

    • Rene Pajaron 0

      Hi Robert,

      Nice to see you here. Looking forward for X# on VS 2022.


  • Vítězslav Imrýšek 0

    Is Visual Studio 2022 still built on NET Framework or have you made a switch to NET 5/6? Would be nice to know if 2022 is future proofed for ARM64.

    • Tim HeuerMicrosoft employee 0

      Visual Studio 2022 will continue to run on the .NET Framework.

      • saint4eva 0

        Hi Tim, what about Visual Studio for Mac 2022, would it run on .NET 6?

        • Yann Duran 0

          if VS for Mac is updated to being built on dotnet 5/6 and VS for Windows isn’t, there’s going to be a full-scale revolt!

          in Microsoft’s rush to cater to the whims of every other platform/language, those of us who’ve been loyal to windows technology for years have been left in their wake.

          it’s sad and it’s infuriating!

      • Asbjørn Riis-Knudsen 0

        Hopefully you are planning to migrate to .NET 6 (or whatever version we end up on) in the future. It seems kind of silly that VS is still stuck on the ancient .NET Framework instead of benefitting from all the performance improvements in .NET 5 onwards.

        Given that 64-bit VS finally happened, I’m hopeful 🙂

      • Yann Duran 0

        that sounds like a very bad decision to me! and your answer didn’t even come close to a reasonable one, sorry.

        what are the factors holding back VS being built with something more up to date? extenders are always stuck with technologies a year to two years behind everyone else!

      • Charles Roddie 0

        > Visual Studio 2022 will continue to run on the .NET Framework.

        That is a shame. This makes VS a lot less flexible and will make the transition to ARM64 harder. Is work ongoing to migrate to the latest dotnet?

    • Tsahi 0

      Considering VS is based on WPF, which is a .NET Framework technology, it must run on .NET Framework. If they switch to MAUI in the future, they would also be able to switch to .NET (probably 7 or 8 by then).

      • Alex Lambert 0

        WPF also runs on .NET Core 3.0+ and .NET 5.

  • Stevie White (Dragnilar) 0

    Holy cow, I’m shocked that 64 bit VS is finally happening!! 😳

    This is some of the best news I’ve heard in a long time. Thank you for finally doing this Microsoft! I know you may not be able to, but I’d love to see a write up on what had to be done to refractor the IDE and it’s dependencies to get it to compile in 64 bit.

    I’m still not sold on MAUI due to the Xamarin issues that I’ve yet to hear of ever being resolved (I. E. Performance, hot reload, etc). I’ll be glad to be proved wrong about my skepticism but so far I haven’t seen much of anything to make me think otherwise. Here’s hoping that changes.

    Intellicode and LiveShare haven’t been very useful to me so I’m not too sure if I’m at all excited to hear that there will be more focus on them. I don’t use them in personal projects or at work. 😕

    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.

    Despite my concerns and/or lack of enthusiasm for some things, I’m really looking forward to this release!

  • Piotr Karczmarz 0

    It is surreal to read that after so many years Visual Studio will be finally running as a 64-bit app. Finally!

    Piotr Karczmarz, CTO at, building VS plugin allowing to jump to deep work quicker via “mental snapshots”.

  • Saurabh Gupta 0

    I am curious to know as new Visual Studio 2022 will depend on which version .net framework or .net core.

    • Tim HeuerMicrosoft employee 0

      Visual Studio 2022 will continue to run on .NET Framework

  • Eder Cardoso 0

    Make sure it will run natively on Windows on ARM.

  • Joseph Musser 0

    Does “dependent breakpoints” mean what I think it means? 🎉

    • Harshada HoleMicrosoft employee 0

      yes, this will add the capability for a breakpoint to become enabled only if another breakpoint is hit. If that what you were thinking then you are right 🙂

      • Joseph Musser 0

        🥳 This is going to be awesome!

      • Roberto Mencia Franco 0

        You can do that now. Not directly, but you can.

    • MgSam 0

      Hopefully this performs decently. Conditional breakpoints tank perform so horrendously that I never use them.

  • Sayan Raja 0

    64 bit! eagerly waiting.

  • Evgeny Vrublevsky 0

    Please tell that VS2022 will support Windows 7 x64 as VS2019 does =)

    • Muhammad Miftah 0

      It probably won’t. It would be nice. I still have to regularly run Windows 7 + VS2015 due to an old SharePoint Server 2010 farm solution still beeing maintained, but seeing as how this new VS version will probably be released in late 2021 or early 2022, I think now would be the right time to just drop support for Windows 7. Almost 2 years now since it exited extended support.

      • Evgeny Vrublevsky 0

        Many companies buy ESU updates for the Windows 7. It will be supported this way till 2023.

    • Gavin Williams 0

      Windows 7 .. how cute! 😊

  • kuzbas123 0

    cool. looking forward to complete c++20 implementation.

  • Deepak Bhagat 0

    Super VS 2022 for 64bit, only one question is it based on .net 4.8 or .net 5 or .net 6

    • Mads KristensenMicrosoft employee 0

      Visual Studio 2022 will continue to run on the .NET Framework. 

      • saint4eva 0

        Mads, are there some features required by Visual Studio 2022 in .NET Framework that are not in .NET 6? And what about Visual Studio for Mac, would it run on .NET 6?

      • Deepak Bhagat 0

        Thank’s for reply Mads Kristensen, i am waiting for the day when Visual Studio will be based on new cross platform .Net 5 6 7 or 8.. and also Visual Studio Code based on same

  • 真 暮間 0

    It’s nice to see that the floppy disk icon still survive in 2022.

  • Andrzej Pauli 0

    Please improve GIT experience to be at least as good as Visual Studio Code. I mean specifically: working with submodules (yes, I’m using those) and more than one git projects. better rebasing with interactive, accepting partial chunks of changes into staging/un-staging area, in-code visualization of history or previous changes. ATM this is night and day experience between VSCode and VS2019 now. Crrossing fingers and wishing us ALL living long and progress 🙂

    • Pratik NadagoudaMicrosoft employee 0

      Hi Andrzej, thanks for the feedback, you’re absolutely right about these feature gaps. In VS 2019, we’ve prioritized building the foundation of a great Git experience. Now that we’ve done that, looking ahead to VS 2022, we’ve already begun designing and working on the top feature requests you mention. We’re monitoring all Git specific suggestions through Developer Community. This is where we want you to engage with us on specifics of a feature and give feedback on designs. Could you please add your vote to the relevant tickets or create new ones to help us prioritize this work?

  • Kasper Bergh Østergaard 0

    I cannot explain how excited I am for 64bit VS finally! Just please tell me you’ll keep supporting and improving vertical tabs in the UI overhaul. I don’t think I could go back to horizontal now.

    • Mads KristensenMicrosoft employee 0

      The vertical tabs aren’t going anywhere. Glad you like them 🙂

  • César Intriago 0

    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.

    • saint4eva 0

      I think you are lying.

      • Gavin Williams 0

        @saint4eva how can he be lying? He’s expressing his concerns and desires. Don’t be a zealot.

  • Michael Barth 0

    Awesome! I just have one question. Will new projects still target 32-bit by default, or 64-bit by default?

    • Andy SterlandMicrosoft employee 0

      The default bitness of each project varies across the supported projects, runtimes, and languages supported by VS. Afaik, there are no plans to change the project defaults as part of VS moving to 64-bit. Though, teams might decide it’s time to change, but I don’t believe there are plans of those kinda in scope at the moment.

  • AC Thompson 0

    Your operating system updates and your visual studio updates continue to interrupt my development process. You continue to introduce regression bugs that negatively impact my development productivity. I dread any changes you guys make.

  • Kamlesh Rao 0

    This is a great news. Looking forward for Visual Studio 2022 Preview 1

  • HBelusca 0

    > Visual Studio 2022 will be a 64-bit application, no longer limited to ~4gb of memory in the main devenv.exe process. […]
    > […] 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.

    (video showing devenv.exe taking 5 GB of memory…)

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

    How the hell can 1600 projects with just 300k files can take 5GB of memory in devenv.exe, especially when one is going then to work on just one or two projects in that solution?? Are you caching the whole content of all the files (projects and source files), or what? Couldn’t you just load a representation of the minimal settings for all the projects, and some minimal information from the source files (for… IntelliSense or whatever) and store that in compressed form, whose portions of interest at any given time get uncompressed and used; and only when one works on a given project in said solution, would the full settings of that project be loaded?

    • David S. 0

      I believe they optimized the best they could without breaking any compatibility. Since VS2015 they pushed the support for large solutions and they had to hit a hard boundary eventually.

      Having a workstation with 64 GB of memory and the main process devenv.exe just freezing around 3 GB is a joke. I am glad they take advantage of the available resources now.

      • Payton Byrd 0

        Yes, and there’s a lot going on in an IDE that needs lots of RAM, like data structures containing symbol references, etc. You have to build those things early and keep them in memory so that intellisense and other live refactorings aren’t starved for data.

    • Michael Taylor 0

      It is more than just the source code that is loaded. MS has been making optimizations over the releases to speed things up, move things to background and load on demand. In fact there is an option in the settings to fast load stuff. It is the traditional speed vs space tradeoff.

      The dev team on VS are a smart bunch. If you have a great idea on how they can optimize solution loads as you believe can be done then you should submit feedback to them on how. Keep in mind that your productivity approach may not be others. It is particularly challenging to see how they could not load the entire solution and all its project and still provide intellisense support as the user types without a noticeable slowdown. Of course a DB would solve this problem but how do you know that the source code that VS just loaded (which you cannot parse for space reasons) is already loaded in a database (keeping in mind code can change outside VS).

      I do agree that opening up memory can lead to VS eating up massive amounts of memory but honestly this is the norm. Ever looked at your browser? Edge/Chrome eat up memory and start so many processes it is outrageous.

      Finally I would say that having a solution with 1600 projects is just a monolithic app that needs its own set of help. I cannot think of a single scenario where a dev would need all those projects loaded at once. It’s nice to know that VS can handle it but honestly I would be focused on fixing the architecture issues, not whether VS can load it in a small amount of memory. These “typical use case” scenarios I tend to disagree with as just an excuse. They are like benchmarks. You can prove anything given the right situation.

  • David S. 0

    I never expected you to port VS to x86-64 since this became a running gag in the community. And because the emulation for x86-64 is pretty decent on Windows 10 for ARM (preview builds), there is no need to rush an AArch64 port either.

    Good job!

  • Daniel Smith 0

    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 😀

    • Jan Děták 0

      Don’t be so happy. They build it on already obsolete framework and it will take at least a decade until they recognize this is just another stupid choice.

  • Payton Byrd 0

    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.

  • Nick Strupat 0

    The list of improvements looks great! I’m wondering if there’s any possibility of sharing the VS “language server” with VS Code? I’m imagining making it available to VS Code through a language server extension like OmniSharp.

    OmniSharp feels quite a bit behind what comes with VS. I use both IDEs daily, as well as JetBrains Rider quite often.


    • Jacob McDowell 0

      If you haven’t already, you can add a couple settings to your vscode settings.json to open up quite a bit of functionality:

      * “omnisharp.enableRoslynAnalyzers”: true

      Only some very basic analysis & refactoring is available without turning this on. However, after enabling, all of the same analyzers as full VS will be available, and the code fixes & refactorings will be there as well, but those that have UI elements in VS (previews, options) will lack previews, and use defaults where options would be given in VS. (For instance, “Extract Interface” extracts as if you’d checked all of the boxes in the VS popup.)

      * “omnisharp.enableEditorConfigSupport”: true

      Naming conventions, formatting, sort usings, error severity levels, and so on… all of VS “Code Style” settings is EditorConfig under the hood. By turning this setting on and exporting your VS settings to an EditorConfig file in your user directory or repo, VS Code will format code the same, offer warnings and fixes for bad naming conventions, and so on. See [here]( for a pic highlighting the “export” button.

      The C# extension will look for global SDK installs as well as VS installations and if i’m not mistaken select the latest version of Roslyn it finds, then hook into it and provide these goodies.

      Some PS…

      I like to set “editor.formatOnType”, “editor.formatOnPaste”, “editor.formatOnSave” all to true (not sure what the defaults are, i just make sure they’re on.) Also i have the following keybindings:

      { “key”: “ctrl+alt+o”, “command”: “o.restart” }

      This will restart OmniSharp if it gets goofy, sometimes after file renames or after using “Move Type to File…”

      When that doesn’t cut it:

      { “key”: “ctrl+alt+r”, “command”: “workbench.action.reloadWindow” }

      Will restart VS Code itself. Both typically on par or faster than a Clean/Build and certainly faster than a full VS reload…

      Hopefully this info is helpful to someone out there !


      “editor.semanticHighlighting.enabled”: true,
      “csharp.semanticHighlighting.enabled”: true

      + C# Extension includes a “Visual Studio 2019 Dark” theme

      • Payton Byrd 0

        There’s not an `omnisharp.dontCrashOnBigProjects` option yet.

      • NN 0

        The best comment for today. 🙂 Didn’t know about it. Thanks!

  • Wayne 0

    Will the whole IDE/Window/Chrome be able to zoom in (rather than just the editor) as you can with VS Code?

    • Mads KristensenMicrosoft employee 0

      You can do that in Visual Studio 2019, though it is a little difficult to find. I use the Font Sizer extension that makes it much easier

      • TSX 0

        it is not the same

        • Mads KristensenMicrosoft employee 0

          How is it different? Perhaps I misunderstood.

          • TSX 0

            Font Sizer changes only fonts, but icons, lines, scrollbars, buttons remain unchanged

    • David S. 0

      VS Code is a fancy single page web application and zooms just like any other webpage.

      For Visual Studio you will have to change the system or monitor DPI.

      I wish Microsoft would enhance the High-DPI support in Windows. We have Per Monitor-DPI awareness already, why can’t we have Per Application-DPI awareness? The OS should be able to scale applications independently.

  • Jan Ringoš 0

    I sure hope there’ll be also ARM64 version for my laptop.

  • Anthony Barranco 0

    The 64 bit support is legendary. We all thought it was a myth over here in game-dev land. Something that only the forgotten dared whisper of. Forsaken words etched on stone walls and lose rocks.

    VS 2022 is going to be Excalibur over here.

  • Roberto Mencia Franco 0

    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?
    I really hope the high density screen has got better support. Currently is a hit and miss.

    • Mads KristensenMicrosoft employee 0

      Visual Studio 2022 will continue to run on .NET Framework using primarily WPF

      • Michael Taylor 0

        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.

        • MgSam 0

          VS is written in so many different technologies I’m sure its a huge undertaking to move it to .NET Core. The work they’re doing to port WPF and WinForms likely needs to be even further along before VS could make the jump.

          • TSX 0

            you are wrong. VS is NF NET app, and NET can do the same as NF NET. Components written in other languages are orthogonal here, locked in assemblies or COM objects, have nothing to do here.

        • Jon 0

          They’ve never said anything like “seamless transition” and (to my dismay) they’ve committed to indefinite support of .NET Framework specifically because so many customers are not willing to make the leap.

          I gather the .NET (Core) port to WPF was kind of an MVP porting effort, and I’ve also read that VS takes many liberties with WPF which I imagine may not play nice with the off-the-shelf WPF the rest of us get, so I’m not especially surprised VS hasn’t made the leap yet, either.

          They’re probably waiting for something like MAUI to mature. Xplat VS would be a huge bang-for-the-buck.

  • Ian Yates 0

    How does the move to 64 bit affect extensions? Do you expect authors to have to update, or if they’ve just used regular .net code in them then they ought to be OK?
    I wonder what JetBrains are doing with R#… Much of it was being moved out of process (like Telerik’s JustCode back in the day). I still use R#, maybe out of habit, but it’s a habit I’m happy to have. I’ll go check their blog in the coming days to see their thinking.

    • Mads KristensenMicrosoft employee 0

      Extensions would have to be updated to support 64-bit. More info will be published soon on what’s involved. You can also watch the extensibility live stream this Friday.

  • Nick Fotopoulos 0

    *eagerly* Does this mean VS2022 will be supported natively on the Surface Pro X when it’s released?

  • Roberto Mencia Franco 0

    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.
    Last VS 16.9 is a mess. Blazor just not ready. Git DevOps… Don’t get me started with the mess of changing branches, Pull request management.
    If I start, I won’t be able to finish.

    • TSX 0

      great post. Unfortunatelly they are focused at adding (buggy and slow) features, as this is main reason for charge money for ‘new version’

      • Andrey Gerasimenko 0

        I guess they have to. With Catalyst and SwiftUI and M1 the only answer is MAUI supported by other cross platform and Cloud features.

  • Mike M 0

    Will Visual Studio 2022 be build/compiled with “.NET 5/6”?

    • Mads KristensenMicrosoft employee 0

      No, Visual Studio 2022 will continue to run on the .NET Framework

      • John King 0

        Then make it run .net 6 😛

  • André Villar 0

    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.

    • Tim HeuerMicrosoft employee 0

      Any particular area dragging you down right now? We’re definitely taking an eye on perf on a few fronts!

        • Payton Byrd 0

          Gotta echo this. Debugging Blazor WASM is a nightmare. It’s slow (to the point that if running in a VM it throws constant timeouts cause a page reload loop). And when devenv.exe get to 2GB while debugging Blazor WASM it freezes and you have to kill devenv.exe directly.

  • Emmanuel Adebiyi 0

    This is awesome news! Great job!

  • Marcel Ratnam 0

    Amazing! Thank you team! Best news from Microsoft dev land in a LONG time!

  • Daniel Smith 0

    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?

    • Roberto Mencia Franco 0

      I agree.
      I don’t think we need that many new features all the time. Performance and stability are the main features needed at the moment.

      Mads Kristensen is doing a great job at showing us how to build extensions. Maybe, we can achieve the same result by creating extensions instead of new changes in VS all the time. This way you can focus on making VS compile in .net 6 and benefit from all the performance improvements.

    • TSX 0

      Reason for this is that VS is still havily dependend on COM, which is Windows – only feature. While COM work with NET 5/6, but using it exclude any portability for other operating systems, which directly hit into NET 5/6 platform independence. So they decided to stay on “Windows NET”

      • Michael Taylor 0

        @TSX, please cite your sources for this information.

        NET 5/6 apps can use COM. NET 5 even had some focus for it as mentioned [here](

        While NET 5/6 is cross platform you don’t have to use it. There are TFMs for targeting each platform specifically so VS itself can run on NET 6 while still using COM. We do this in at least one place ourselves. The COM server implementations, if necessary, could remain in NF and be hosted out of process or rewritten as managed interfaces. We’ll have to wait for the extension livestream on Friday to see if they are moving away from COM toward managed interfaces in this version.

  • Gavin 0

    Yay! Finally! We have so many issues with IDE performance due to memory limitations on our project that it’s a major time sink. I even choose to live dangerously and resort to setting /LARGEADDRESSAWARE on devenv.exe, which can help a lot. Can’t wait for the preview to go kick the tires!

  • 空 悟 0

    look forward to!!!

  • Neal Culiner 0

    ONE version of the IDE and FREE please, ala XCode.

  • Michael Fouquette 0

    Mostly love it all. But also good to know I am not the only person who always calls my StringBuilders “sb”

    • TSX 0

      do not worry. In VS 2025 AI will learn that you don’t like ‘sb’, and will offer beloved ‘bs’ 🙂

  • Сергей Сергин 0

    Great news!
    I really, really hope that the classic new project window will return to Studio 2022. The version of this one in 2019 is just a disaster: inconvenient, slow, confusing. Return it as it was in 2017 and earlier, please.

  • Zachary Neda 0

    TOO LATE ! But I appreciate that.
    All other IDEs have been x64 for so long time ago.

  • Miroslav Boublík 0

    How about .NET 6 support in VS 2019? Will it be supported? I just convinced my boss to buy VS 2019 because month ago there were no information about VS 2022 (including your VS roadmap).

    • Alexey Leonovich 0

      I have the same question..

    • Michael Taylor 0

      VS 2019 already supports NET 6. It is the only way to do NET 6 development. Currently you have to use 16.9 Preview 4 or later as discussed [here]( however that is because they always start their initial integration in previews. As the tooling becomes more stable it’ll be part of the formal 16.x toolset. You’ll just need to update your VS 2019 instance.

      As for buying VS 2019, yeah been there. Most people, I believe, buy VS via Visual Studio with MSDN and therefore they have software assurance for the life of the (yearly) subscription. Therefore you can upgrade to VS 2022 provided it releases before your subscription ends (unless you renew). So it should not be any cost. If you aren’t currently buying VS with MSDN then you probably want to consider doing so. It gives you the licenses for the OS and SQL Server you generally want to develop against as well including Azure credit if you use Azure. The first purchase is hideously expensive but yearly renewals are cheap (relative).

      In my experience VS versions tend to release in the last quarter before or the first quarter after the year so I would expect VS 2022 to be released anywhere between Nov 2021 and Apr 2022. So I expect a year from now we’ll be using VS 2022. But this is entirely a guess.

      • Miroslav Boublík 0

        Yes I know that there are those .NET 6 previews, but the most important thing is, if the final .NET 6 will be available in VS 2019 or if it will be only available in VS 2022. We came from VS 2010 to VS 2017 and we planned to switch to something newer than 2019, but from MS there were no information about VS newer than 2019 and we need .NET core/.NET 5 development for our backend so we decided to buy VS 2019 month ago. If Visual Studio 2019 will support final version of .NET 6 it will be enough for us, because of LTS 😉

    • Tim HeuerMicrosoft employee 0

      As Michael points out that through some of the previews of .NET 6, we’ve encouraged use of 16.9 preview channel releases for your evaluation/testing. Our plan is that VS 2022 will be the fully supported matching toolset for .NET 6 development with the new tooling features of the SDK, hot reload, web and Azure tools to match. Once we have a preview build of VS 2022 for customers to try we’ll ask that you use that for .NET 6 preview development.

      • Miroslav Boublík 0

        You can directly write that Visual Studio 2019 will stuck with .NET 5.0 final and .NET 6.0 final will only be available in Visual Studio 2022 🙂

      • Alexey Leonovich 0

        Once we have a preview build of VS 2022 for customers to try we’ll ask that you use that for .NET 6 preview development.

        Microsoft will very disappoint software developers if make Visual Studio 2019 stuck on .NET 5.0 final.
        Please make .NET 6.0 final available both for Visual Studio 2019 and 2022 (latter may have more rich tooling)
        Development should be possible in both IDEs because many companies have recently invested in the purchase of Visual Studio 2019 due to the long lack of news about Visual Studio VNext.
        Thank you in advance.

        • Miroslav Boublík 0

          I agree with Alexey, if we know before that there will be a new version of Visual Studio, we would probably buy less licenses of VS 2019 a wait until VS 2022 (and then buy new licenses and upgrades). .NET 6 should definitely be part of VS 2019. And Microsoft should inform developers sooner.

  • Daniel Hughes 0

    According to 48% of software developers use linux.

    Visual Studio’s lack of linux support is massively hurting microsoft.

    • Payton Byrd 0

      Actually, Omnisharp is hurting much more. The devs who are Linux only who try C# for the first time right now will probably give up on it and never come back.

    • Tim HeuerMicrosoft employee 0

      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.

    • MgSam 0

      That’s why they made VS Code.

  • Reelix 0

    Odd question, but will the upgraded Github support keep the Github profile image on commits? The existing one doesn’t for some reason.

    • Pratik NadagoudaMicrosoft employee 0

      That’s great feedback, Reelix. Updating support for GitHub avatars is on our backlog, but we haven’t received any feature requests for it yet. I just created one that you can vote on. That will help us prioritize the work sooner. Thanks!

      • Reelix 0

        Wow – Much appreciated!

        I know that it’s not the most sought-after thing, but it just seems like one of those QoL things that should be there but isn’t.

        I don’t really expect it to be implemented any time soon, but it’s great that you added it to the backlog 🙂

  • jalpesh vadgama 0

    Now that Visual Studio is having a new font. Can we also get support for the Line Height and Line spacing features as we need to adjust font lines and which is supported in visual studio code out of box. This is a feature request for many years and now you guys are doing revamping of visual studio to 64 bit please please do that.

    Also support for Bold and italic fonts are also required. As all modern IDEs are supported that our of box except visual studio

    I hope that my feedback counts.

    • Dante GagneMicrosoft employee 0

      Adjusting Line Spacing should be coming in the next update to Visual Studio 2019 (Update 10 if I’m not mistaken). It will be in Visual Studio 2022 as well. If you have any problems with it, please send us feedback!

      As for Bold and Italic fonts, we’re looking into it. No promises, but it’s certainly something we’re investigating.

      • hitesh davey 0

        This is great. Thanks. I am looking forward to the Line Height & Spacing feature like MS WORD. Option to change the line height & spacing from 1 to 1.5 would improve the readability of the code.

  • Steve 0

    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:

  • Paulo Pinto 0

    Great news.

    Please also take the opportunity to finally add proper VS tooling to C++/WinRT, assuming it still has a future on Windows development.

    Editing IDL files without any kind of VS tooling support, copying and merging by hand the generated files is no fun, just like it isn’t having to wait for ISO C++26 for the VS team to add back the productivity that C++/CX already offered us.

  • Adrian Sims 0

    Since there’s more github support, I’d like to be able to preview both GFM and asciidoc in Visual Studio without needing to install an extension (I know you can do this in VS code, but we “mere” Visual Studio users [ 🙂 ] are left out in the cold!

  • Zaldy Jr Pagaduan 0

    MAUI looks promising 💯

  • Royi Namir 0

    Wow great news. thing will be much faster

  • Anand C 0

    Will VS 2022 be released as part of .NET 6 planned for release this November 2021?

  • Vladislav Antonyuk 0

    Will this update be for the current Visual Studio 2019 or will it require a separate installation?

    • Andy SterlandMicrosoft employee 0

      It will be a separate installation that can be side by side with VS 2019.

  • Mahdi Hosseini 0

    The new icons look very ugly and old
    I also hope that the dark theme will be fully supported in 2022 version

  • ManzoorTheTrainer 0

    Really cool features. MAUI and AI IntelliCode engine 🙂

  • Stefan Diaconu 0

    Will Visual Studio 2022 for Mac support C++?

    • Jordan MatthiesenMicrosoft employee 0

      Thanks for the question – Currently we don’t have plans for C++ support in Visual Studio for Mac while we focus on supporting .NET development. You can add your vote to the Support projects with C++ item on our Developer Community site and we’ll post updates there if plans change.

  • Nima Zare 0

    Popular Visual Studio team, your work was great.
    We are waiting to use this wonderful version.
    Good luck

  • Igor Shigaev 0

    “Exciting news” is “it past almost 20 years(!!!!!!!) for MS to realize that 64 bit is reality”. 🙂
    Will anybody make statement how he regrets to be so …. narrow-minded? Anybody is responsible for stupid decisions like using ‘COM’ in VS? Locked to 32 bit for 20 years? Hey, you stay in the past, keeping us too. Very long time for evolution, very long. You underperform, dear MS – thanks to current CEO.

  • 0

    Will there be a community edition again as it was for 2017 and 2019 ?

    • Mads KristensenMicrosoft employee 0


      • 0

        Thanks for the reply.

  • Johan Visser 0

    How much more disk space do we need for this version? (full install)
    The current version is already out of control.
    And how much bigger are the updates going to be? (the last update was 1.15GB…….)

    • Andy SterlandMicrosoft employee 0

      How much disk space required will vary depending on which workloads are installed. At the moment we don’t have exact details on how big, but it’s likely to be in the same region as VS 2019.

    • simmse 0

      How did you have an update near one GB? The last few updates have been in the range of 1.2 to 2.5 GB. Occasionally, the update size is a few hundred megabytes.

      • Johan Visser 0

        It depends on the stuff that’s installed.
        On my other computer, the same update was 1.8GB

        I hope that they will fix the installer.
        Now I can do only 1 update at a time. And I see the same packages being downloaded for VS and Build tools.
        I want to run the installer, select all updates, and update. (not update, wait, next update, wait, etc)

  • 惠然 杨 0


  • sebastian.rincon 0

    It would be very good to have the same experience when debugging code in mac as in windows

  • Jonathan Dodd 0

    Looks great from the perspective of 64-bit and performance improvements, also looking forward to exploring MAUI in detail via VS2022. However, from reading the comments here , I really hope DevOps integration does not become a thing of the past. It does feel there is a pull to GitHub and that means a big adjustment for us. The integration of the IDE with other services (DevOps, Azure etc) is presently an enabler of developer efficiency.

  • Igor Shigaev 0

    > Visual Studio 2022 will have full support for .NET 6

    Not interested at all. Will VS2022 support FW4.8 same full as it was supported by VS2019??

    • TSX 0