The Spring 2020 Roadmap for Visual Studio published

Mads Kristensen

The Visual Studio roadmap has been updated to provide a peek into the work planned for Visual Studio through June 2020. It captures significant capabilities that we plan to add, but it’s not a comprehensive feature list. Our goal is to clarify what’s coming so you can plan for upgrades and provide feedback on which features would make Visual Studio a more productive development environment for you and your team.

Our roadmap is driven largely by what we learn through ongoing customer research, as well as the feedback we get via our Developer Community portal. These features and time frames represent our current plans but may change based on what we learn. If there are features that are particularly important to you, please be sure to vote and comment on the features in the Developer Community portal.

We often get feedback on the importance of an up-to-date roadmap for Visual Studio. We aim to publish updates more frequently going forward and we’re putting processes in place to make that happen. In that light, we’d highly appreciate if you would take a brief survey to let us know how to best handle the roadmap going forward.

44 comments

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

  • MgSam 0

    It seems to be impossible to browse through the VS feature suggestions on the web now. Someone managed to take a broken, barely usable website and make it totally unusable. The link in your blog post doesn’t actually take you to a page that browses features.

    There used to be a buried link somewhere in the dev community page to navigate over to the features section that you could click after you had first navigated to the problems section- that’s gone now, and this link, https://developercommunity.visualstudio.com/idea/, doesn’t work either because whoever builds your website doesn’t seem to know about standard REST either.

    I just don’t understand why MSDN continues to be such an embarrassment of a website after all of these years of you guys rebuilding it over and over again. My vote is that you outsource development of MSDN to an external company- it’ll probably be cheaper and you’ll get more competent people working on it.

    Also, depressing to see you guys still listing “Improve performance opening and working with large solutions” on your roadmap; a place where its been for eons. You know, I know, and everyone knows what you need to do to properly fix VS performance. Make it a 64 bit application. I can’t even fathom how many man-years of development resources have been spent over the years trying to kludge around this issue rather than addressing the root cause.

    • Mads KristensenMicrosoft employee 0

      We’re currently in the process of re-thinking the entire feedback system, and easy access to browse the ideas is a must-have. I’m glad you found it eventually.

      • Jiří Zídek 0

        Why not leverage GitHub Issues for this ? You don’t need to put code…

        • The Sharp Ninja 0

          +100

          Seriously, you can even do some automation to generate pages for suggestions that act as a dashboard that link to related issues, repositories and code, list responsible parties, take feedback, etc.

      • Dean Jackson 0

        Please don’t use GitHub or it’s style. I don’t think it’s friendly or inviting. The current developercommunity.visualstudio.com site is missing some key things, but overall I think it works well.

    • Kirsan 0

      I agree by 100%. Especially about x64 VS…

      • Mike-E 0

        FWIW @Kirsan Rider is 64-bit. So now we have a race between JetBrains to develop all the extensions that VS has or for VS to make the jump to 64-bit themselves LETS SEE WHO WINS????

    • Mike-E 0

      Feel free to add your vote here, @MgSam:

      https://developercommunity.visualstudio.com/idea/595756/fix-your-blog.html

      Most of these issues have been reported last June and very few have been attended to or fixed. I for one would love a job where I sit around for nine months and get paid for doing nothing. 🤷‍♂️ Good time for MSFT stock.

  • Mike Diack 0

    I hate to say it, but I know I speak for hundreds if not thousands of developers, but the best thing you could to improve VS is:

    1) Greatly improve the support staff dealing with bug reports. Far too often there are examples of one or more of the following:

    – Endless requests for sample code – developers have normally already given sample code.

    – Lack of understanding of urgency – if there is a showstopping bug for a customer in VS 2017, it may well for multitudinous reasons be possible for them to NOT try a fix in the latest VS 2019 issue. I’ve seen this issue countless times, where people say they need a fix in VS 2017 and it gets ignored.

    – Stupid comments about voting on bugfixes. If a bug is a serious bug, it should be prioritised by management, with technical input, votes should not play a part in it, if my app crashes due to a null pointer deref in the CRT, it’s a bug, irrespective of number of votes.

    – Lack of clarity, why can’t you say which version has a fix in. It’s always “In the latest version of” – that’s rubbish (not least because “latest version” is a moving target), be exactm, is it 16.4.x – or _MSC_FULL_VER >= x? You demand your customers be exact in the reporting of the bugs, show them the same courtesy by being much less VAGUE in your answers.

    Fix that, and you’ll have an effective feedback and bug management process, that leads to a better product, not just throwing endless features in the mix to bloat the IDE.

    • Kirsan 0

      10 of 10.

    • Richard Moore 0

      Agreed.

    • Will Green 0

      10/10 would read again.

    • Charles Roddie 0

      3/4. I agree except having to fix older versions of the software is a time-wasting distraction which would slow down the maintenance and progress of VS.

      • Mike Diack 0

        Here’s a text book example of all that’s wrong with the feedback process:

        https://developercommunity.visualstudio.com/content/problem/410508/visual-studio-2017-offline-installation-error-coul.html

        1) Details of how to repro it are given, but then the team ask for another means to repro it.
        2) User points out (as is often the case especially for software in certain highly controlled markets, e.g. medical devices etc), that they can’t use VS 2019 currently as MS suggest.
        3) Bug is arbitrarily closed (presumably because it’s fixed in 2019, even though the user has it the problem in their 2017 system) after a time period.
        4) User is now irritated that the issue has been closed: “Can you not close issues that have not been resolved? How many times do I have to report the same issue? Just re-open the issue, since it clearly has not been resolved. Thank you for your patience.”
        5) MS’s reply to 4) ignores the original problem (bug in VS 2017) by suggesting an update to VS 2019 (albeit a specific version).
        6) A fix finally comes in VS 2017, but with the same stupid, generic, unhelpful, inexact details of which version rather than “install VS 2017 Update 9.21”:
        “A fix for this issue has been released! Install the most recent release from https://visualstudio.microsoft.com/downloads/. Thank you for providing valuable feedback which has helped improve the product.”

        An absolute text book example of why the Visual Studio bug reporting/fixing/feedback process is fundamentally rubbish.

        • Mike-E 0

          That’s nice Mike but yeah, if you could just go ahead and put that in a survey along with your TPS reports, that would be great.

          • Mike Diack 0

            Already done in the survey but will do it again. One day Microsoft will actually take this stuff seriously…. One day….

    • Christian Benner 0

      I fully agree.

  • Mike Diack 0

    No mention of 64 bit Address Sanitizer support in the roadmap. You’ve integrated it for 32 bit target applications – what is the state of the 64 bit one?

    • Yann Duran 0

      Just use my Start Page+extension. They’re never going to give us what we ask for because it doesn’t fit with what they want. Either that or they just don’t want to admit the whole Start Window was a mistake from the beginning.

  • Edison Henrique Andreassy (GOVBR MTZ - DDP Arquitetura) 0

    I would like to see more attention on .NET Core Windows Desktop development. Our company heavily relies on Windows Forms and we would like to migrate do .NET Core, but the designer is not available yet.

    • Daniel Smith 0

      I’d also like to see WinForms plans mentioned in the roadmap. My understanding is that the WinForms team are aiming for the designer to have feature parity with .NET Framework capabilities in the .NET 5 time frame. Surely that’s noteworthy?

    • Olia GavryshMicrosoft employee 0

      Yes, that’s a very good point and we will include information about WinForms in future. We have a blog post coming up in the middle of March with an update on WinForms Core designer. The work on it is in progress, we keep adding support for more features and controls and, as you mentioned, by the .NET 5 time frame we plan to get a mature version of the WinForms Core designer. You can check out a preview version of it already in the Preview of Visual Studio (make sure to check it in Tools->Options->Environment->Preview Features->Use the preview Windows Forms designer for .NET Core apps)

  • Mike-E 0

    Nice to see some efforts towards fixing “async” problems. Are you also going to add “async” to the dictionary and make it more official-sounding?

    (That was a joke, “async” isn’t actually a word.)

    https://developercommunity.visualstudio.com/idea/583945/improve-asynchronous-programming-model.html

    👆 Currently the fourth-rated suggestion in .NET feature requests. Thank you to all who are also feeling the pain and have voted as such!

  • SuperCocoLoco . 0

    To be more productive with Visual Studio, please restore the old new project dialog and the old start page, one of the most voted and most commented suggestion and one of the most ignored by Microsoft.

    Knowing what is Microsoft doing this past years i’m more interested on what good and productive features Microsoft broke or remove in future versions of Visual Studio than new non-demanded features.

  • Max Mustermueller 0

    It’s mostly a “little bit here and a little bit there”. Nothing that makes be being excited or outstanding or something I would say “hell yes!”. And half of the roadmap is very vague. Like

    – “Improve the XAML Designer for .NET Core WPF and for UWP”…. improve, how? What are the improvements? Is there anything specifically planned or do you just “See what people say and work on fixing a bug or two”?
    – “Debugging improvements” … again? What’s planned here? Do we finally can edit code and import namespaces without VS wants us to restart the whole debugging while adding the code by full namespace always and still works?

    Still no word about 64-bit VS. The current 32 bitness of VS causes a lot of issues when targeting a 64bit application (designer breaks a lot, lots of false errors, claims to cannot find code and red underlines words in code for no reason while building and running works). Since Github is now owned by Microsoft, still no native implementation. The current extension is okay for very basic usage, but the navigation is horrible.

    Still no local source control like in VS Code with full history and undo even after VS has been restarted.

    • Dmitry LyalinMicrosoft employee 0

      Max,

      Hi, I am the PM for XAML tools for desktop apps and wanted to give a bit more context as you’re right we’re a bit vague in the roadmap as there is a lot of potential working going on in those two areas but we’ve not locked 100% on all the plans.

      Some areas where we are investigating right now:

      1. For XAML Designer, we’re working on Suggested Actions which is still in development that will make it much easier to modify common properties and take actions against a selected control without having to dig through the properties panel.
      2. For Debugging improvements we’re working on Data Binding Failures implementation and some other related tooling improvements to make it easier to see when bindings fail and eventually we hope navigate to code (which wont be in the first release).

      If you have specific improvements that you’d like to see or anything that feels like a bug or bad design please report them through the VS Feedback feature in the top right of the IDE. Please report one issue at a time that way we can triage and give you some reply, this is the best path. thanks again for your comments

    • Taysser GherfalMicrosoft employee 0

      Thanks for the feedback Max. Regarding Git and GitHub, we are working on a new experience that will replace Team Explorer and take care of the navigation issues we currently have. This new Git experience will be coming as a preview feature very soon!

    • Kirsan 0

      And again no word about 64 bit vs in replays 🙂

    • Will Green 0

      God yes. Please make VS a 64-bit process. You can see improvements being made in this area, such as moving stuff to out of process. But please, please, please keep going in this area. It’s a daily pain point.

    • Dean Jackson 0

      I’m glad there’s not a lot of big things this time. There are a huge amount of bugs that need to be fixed, and I’m hoping this means the leadership will get serious about fixing them. As a programmer for 20 years, every team I’ve ever worked on, would be very cautious about adding new features if there were a lot of bugs to fix. Adding a lot of new things while you are in the middle of diagnosing bugs, just makes fixing them harder because things are changing.

  • Jefferson Motta 0

    For God sake STOP odd VS versions number, restart with 2020 this year, please.

    • Daniel Smith 0

      I was assuming that since there’s going to be the major new .NET 5 release, that Visual Studio would bump up to VS2020 as well. But looking at the roadmap, it doesn’t actually say what the plans are for this.

      There’s previously been discussions about dropping the whole year naming, and moving to an evergreen model like Chrome where it’s constantly updated, and the version number largely becomes irrelevant.

    • Mike-E 0

      +1 … digging seeing “2019” every time I open your product in 2020.

    • Gweltaz . 0

      I’m no one, but I wonder why are the odd numbers bothering you ?
      Your code wouldn’t handle a future “2021” version of VS ? or would “2022” be a better release year ?

    • Dee You 0

      it seem need to change the name of visual studio to visual garage not VS version

  • Richard Moore 0

    Why should I bother completing a survey, when most of the bugs VS I take the time to report get closed as “probably won’t fix”?

    I think I might mark this survey “Probably won’t complete”.

    • Mike-E 0

      Richard Moore wins the nerd internet this day.

      Why does MSFT continue to ask developers to fill out surveys when it already has a feedback apparatus that allows for upvoting, commentary, and integration with existing internal development workflows with developercommunity? We’re already telling you what we want. You are telling us that you simply do not want to listen.

  • Ibrahim Surani 0

    There are so many issues with Visual Studio 2019. Source control sluggishness, edit and continue not working, extremely high CPU usage—even when not compiling, frequent TFVC ‘not authorized’ errors, refactoring not working at times.

    After months of waiting for fixes and butting heads with Microsoft support—nice people but way out of their depth—I have switched to Rider. Once they improve their Dev Ops integration, I plan to use that as my primary IDE.

    Why are these issues not getting the team’s attention?

  • Will Green 0

    I’d love to see more work done for large solutions and the option to *disable* the AI-related features from the last several major releases. For those of us working on large solutions that regularly approach the 32-bit memory limit, I’d ***love*** to see devotion to perf improvements.

  • Ion Sorin Torjo 0

    Improving UWP Compilation times are not in the roadmap.

    That is soooo saad. We’ve been complaining for years. The higher winOS you target, the worse it gets. It’s close to unusable.

    Here’s just the latest thread: https://github.com/microsoft/microsoft-ui-xaml/issues/1517 https://github.com/microsoft/microsoft-ui-xaml/issues/1535

    This won’t go away with WinUI 3.0 – because that’s UWP behind the scenes.

    I do understand that it’s not a top priority, but at least some things should be made faster for those with big RAM and/or fast HDDs – at this time, this does not seem to be the case. I have 64 GB of RAM doing nothing, and a 3 GB/s HDD, not useful.

Feedback usabilla icon