Since we launched Visual Studio 2017 in March of that year, it has become our most popular Visual Studio release ever. Your feedback has helped our team publish seven updates since our initial GA, which have improved solution load performance, build performance, and unit test discovery performance. We’ve also made Visual Studio 2017 our most accessible releases ever, helping developers with low-vision or no-vision be more productive.
Our team is focused on introducing features that make every developer more productive: better navigation features like “go to all” (Ctrl + ,), features to improve code quality like Live Unit Testing, and most recently, to enable real time collaboration with Live Share. And we have even started to show how we will use artificial intelligence to assist developers with IntelliCode.
Now, it’s time to start to look at what comes next.
The short answer is Visual Studio 2019
Because the Developer Tools teams (especially .NET and Roslyn) do so much work in GitHub, you’ll start to see check-ins that indicate that we’re laying the foundation for Visual Studio 2019, and we’re now in the early planning phase of Visual Studio 2019 and Visual Studio for Mac. We remain committed to making Visual Studio faster, more reliable, more productive for individuals and teams, easier to use, and easier to get started with. Expect more and better refactorings, better navigation, more capabilities in the debugger, faster solution load, and faster builds. But also expect us to continue to explore how connected capabilities like Live Share can enable developers to collaborate in real time from across the world and how we can make cloud scenarios like working with online source repositories more seamless. Expect us to push the boundaries of individual and team productivity with capabilities like IntelliCode, where Visual Studio can use Azure to train and deliver AI-powered assistance into the IDE.
Our goal with this next release is to make it a simple, easy upgrade for everyone – for example, Visual Studio 2019 previews will install side by side with Visual Studio 2017 and won’t require a major operating system upgrade.
As for timing of the next release, we’ll say more in the coming months, but be assured we want to deliver Visual Studio 2019 quickly and iteratively. We’ve learned a lot from the cadence we’ve used with Visual Studio 2017, and one of the biggest things we have learned is that we can do a lot of good work if we focus on continually delivering and listening to your feedback. There are no bits to preview yet, but the best way to ensure you are on the cutting edge will be to watch this blog and to subscribe to the Visual Studio 2017 Preview.
In the meantime, our team will continue to publish a roadmap of what we’re planning online, work in many open source repositories, and take your feedback through our Developer Community website. This blog post is just another example of sharing our plans with you early, so you can plan and work with us to continue to make Visual Studio a great coding environment.
John
 |
John Montgomery, Director of Program Management for Visual Studio @JohnMont John is responsible for product design and customer success for all of Visual Studio, C++, C#, VB, JavaScript, and .NET. John has been at Microsoft for 17 years, working in developer technologies the whole time. |
Please add the option to install Microsoft Reporting to the Visual Studio installer so we have the option to have it installed and have the latest report viewers added to the toolbox instead of having to do it by the project by going to nuget. Annoying to say the least.
This! And I’d go one step further, make sure that SSDT is ready and working with VS2019 before you release 2019. SSDT was not ready at launch for 2017 and didn’t become ready for months afterwards. Not only that but the entry for SQL Server Data Tools in the VS2017 installer caused confusion as it didn’t contain any of the SSDT tools developers needed (SSAS, SSRS, SSIS).
And it seems that people are still struggling to get SSDT to work with VS2017 (going by the comments on the SSDT docs page).
Is there any plan to release visual studio ide for linux ?
user voice : https://visualstudio.uservoice.com/forums/121579-visual-studio-ide/suggestions/10662897-visual-studio-for-linux
awesome, really exited about this!
just a though: why are the versions still named by year?
just asking, i myself dont really like it, specially now that updates are often, seems like hidding the “15”(in 2017’s case) brings more confusion than anything else.
Wow! Awesome news.
I am happy to see the Visual Studio 2019 announcement.
Microsoft: bring the best and merge UWP, WPF, Xamarin, Web, C#, F#, JavaScript (TypeScript) and make ALL THIS work cross-platform.
Create a Ubiquitous .NET Client Application Development Model
https://visualstudio.uservoice.com/forums/121579-visual-studio-ide/suggestions/10027638-create-a-ubiquitous-net-client-application-develo
please fix the XAML designer performance issue especially for WPF .
Agreed – for UWP and WPF. Honestly, I don’t really care about much else. If this doesn’t work, you might as well not have a UX product/story at all.
There are many things wrong with Visual Studio’s XAML designer, performance being just one of them. Ever since the “new” designer was introduced with VS2017 15.4(?) (ref. https://blogs.msdn.microsoft.com/visualstudio/2017/09/11/a-significant-update-to-the-xaml-designer/), it has, for me, essentially been crippled and its value as a productivity tool severely diminished compared to what it was before. So many previously helpful features were either disabled or disappeared altogether. Things like (in the Properties window) the collection editors (e.g. being able to click on the ellipse button next to the ColumnCollection or RowCollection properties in a grid to bring up the collection editor in a modal dialog) and the new object editors (e.g. being able to click on the ellipse button next to the DataContext property in a page to be able to browse to the data source and have all references added automatically). There is other general weirdness like why, when I am looking at the properties for an AppBarButton in the Properties window, is the Icon property nowhere to be seen, but works fine in the code editor and comes up in IntelliSense?
That the “new” (15.4?) XAML designer experience was forced on all developers with projects targeting at least Windows 10 1709 is inexcusable. It should only ever have been an option, to be switched on if desired in Visual Studio’s Options dialog. If VS2019 is to be an improvement over VS2017, the XAML designer needs some serious attention.
Is it 64 bit?
Without breaking extensions?
Extensions required serious update conversion with 2017 anyway and if extension is fully .NET it is usually compiled for both architectures easily.
64-bit VS is really seriously needed.
for what reasons ? Are there some limitations from 32 bits ?
I have been developing professionally with VS for 20 years now. honestly, the experience seems to get worse with each new release. the amount of time wasted in my day working with XAML alone makes me more than frustrated. The feeling is mutual among my peers as well – and it has been for years now. VS Code is such a fresh breath of air because of its speed. VS full has become so bloated, working with UWP/XAML so slow, and build times so slow. Also, imo profiling tools should be turned OFF by default, with a simple button to toggle them back on when needed. As a developer, I don’t want them on all the time – rather, just when I want to profile.
I have heard the VS team talk about ‘performance improvements’ for a very long time. the story here is the same. UWP development should be faster than Win Forms development, and yet it is so much worse. I would really appreciate it if the team would stop bloating the VS full product and instead finally get the core stuff running lightning fast – FASTER than Win Forms! – that’s my expectation and the bar you should set for yourself. Thanks for listening.
I’ve had problems with the WinForms designer for as long as I can remember, going back multiple versions of Visual Studio. In my day job where I work with VS2017 on a legacy product that is a hybrid of C++ and C#, any WinForms dialog that contains a visual component written in C++ almost invariably causes some sort of error when I try to open the dialog in the designer, alternating between allowing me to continue past the error (and “helpfully” deleting the “offending” code — good thing there is version control to restore these unwanted changes), or refusing to allow me to access the designer at all. Modifying WinForms dialogs by editing the .designer.cs files has become the norm.
Will Microsoft, after all these years, finally fix the WinForms designer? One can dare to dream…
I’m glad it’s a real version, and not some rolling as-a-service thing.
2017 has been buggier than all of the bugs 2015 and 2013 had combined. Also, some of the “releases” (not previews, but final release), when they first released, severely broke some things. Please care more about testing what you release than meeting some time-frame. Please don’t consider us your testers (again, the final releases, not the previews).
Please stop this rude closing of a bug report in delopercommunity.visualstudio.com, because “this is a low priority and we don’t have time to look into it now.” That’s just rude. That makes you look like a bunch of college kids. At least have the decency to leave it open.
Seeing that the Visual Studio process memory is most of the time near 2 GB, I think only a 64 bit version could be a real step. to improve performances in the IDE.
It’s not that black and white. https://www.infoq.com/news/2016/01/VS-64-bit
Most of the memory footprint is caused by tons of useless NodeJS processes. I don’t understand why IDE must be written is such terrible language/runtime like JavaScript is while we have mature .NET platform. These processes are there even when you don’t open any web project.
Have Microsoft already heard of multithreading and CLR appdomains? You don’t need 100 isolated processes to run 100 tasks, we already have threads for such purpose last two decaces, remember? Please just remove all the JavaScript junk and it will be fine again.
Please use proper Microsoft technology (.NET and WPF) for the Visual Studio installer. Current Electron thingy is something I don’t want to use, especially in case of paid product. The technology is crap.
Bring back Express line, or remove usage restrictions from VS Community
Second that. The license drove people away from using VS and Microsoft technology for the small plumbing things in enterprise. My manager won’t buy me an enterprise licence just to write a f# tool to experiment wrangle test data. Now it’s mostly the open source stuff. To encourage enterprise to use more MS technogy, have more people understand ms knowledge and skills you need to relax the license to allow individual developer in enterprise to use VS for usage that don’t directly contribute to the product. Hope you guys will give it a thought. Thanks
Please consider equal quality gitlab integration and slimming down memory and GPU usage for visual studio.