Rearchitecting Visual Studio 2017

Description

In this episode, Robert is joined by Art Leonard, who explains how and why Visual Studio was rearchitected to support faster and more flexible installs. He discusses the Core Editor, breaking up the product into smaller parts, installing workloads, the ability to install multiple versions of Visual Studio (eg Pro and Enterprise) side-by-side, early access to new features with the Visual Studio Preview and more.

@exim: As our developer tools are reaching further and further cross-platform, we wanted a cross-platform UI framework to that would enable us to do a lot more than just install the product. We think of this program as a toe-hold into a world where you "get developer-focused stuff (tools, maybe content) from Microsoft". The ability to install and maintain your environment is a step on that potential path. Some of the factors we considered were the ability to go down to Windows 7, having as little platform-specific dependency as possible to reduce test cost, and have an ecosystem that would support the endeavor. We were also eager to get more involved in OSS (at least in consumption) and we knew that the VS Code team was having success using electron. One of the big trade-offs is size, which is clearly an important a factor.

We're continuously reevaluating how we do this, and we're listening closely to feedback.

@artlms: Thanks for the reply. Tell you honestly, I believe Electron was made for web devs who didn't want to learn "right tools for the right job" for Desktop. I mean, there are many native cross-platform frameworks such as wxWidgets (which actually uses native controls for each platform), Qt, Gtk, etc... If you wanted only for Windows OSes, you could use WPF, WinForms or even MFC. So all in all, Electron seems quite an overhead for such task.

As for VS Code - I think that it would have been a such good product if it were made in pure Win32 API, or at least in above mentioned native cross-platform frameworks.

I care more about being able to generate a script (say a PowerShell script) rather than sync across devices.

One reason is so I can share the script with colleagues. For example, one developer I work with has avoided upgrading his development machine from Windows 2008 R2 because he worries about how much work is involved in reinstalling Visual Studio.

If I can save scripts from the installer to a file on my disk, I can easily share that with my colleagues. Syncing through my MSDN account is useless to me.

@ArneG: Can you tell me your userID on developer community? I will try to see if I can connect what you're seeing with other issues we're tracking. The volume on Developer Community is very high, and it's taking us time to get through all the issues. Setup is especially busy. The best advice I can give is vote up existing items first before logging new ones if you can. I appreciate you reaching out, and understand the frustration - if I can get your ID, I will try to connect the dots, and hopefully your specific issues match ones we're already tracking.

Sharing an installed config is important to teams and individuals. Many of us work on several different PCs and would like a reproducible install set of VS 2017. For teams, even more important that additional devs start out in the 'production' dev tooling environment.Watching Art Leonard on Channel9 he brought up the VS IDE team's decision to not ask for an ID in the VS 2017 Installer. But we are still compelled to use an ID in VS itself?! I vote for an ID in the installer since it will simplify having install configs saved to your account and be reusable as you change machines or VMs.

Already put this into UserVoice for VS

I heard somewhere that you will eventually add Search to the new installer. This could be useful, but the list of individual components is not that overwhelming yet. I'd prefer we get reproducible configs first.

And thanks for a very interesting show on the evolution of VS installation.

@artlms,You answered your question when you mentioned to @ArneG that the volume of bugs you're fixing in VS 2017 is very high. There's no particular error to mention, you already know that the rewrite of the editor introduced a lot of bugs. I've already filed numerous ones during the RC timeframe. Many of the crashes for me are during typing in .cshtml razor files, where what I'm typing is a mixture of razor and HTML, and is usually after cut/paste. Cut/paste is a known problem in VS 2017. For example, in .CSS files, if you paste .css onto a new line AND if the text you're pasting does NOT have a beginning curly brace at the end of your text, then the editor DELETES!!! lines below where you pasted!!

@artlms,I've used every version of VS since 1997, and this is by far the buggiest one. Some people like your new fast-pace updates, but I'd much rather have the older-style big update, because: the small updates are likely only fixing a few of the "major" bugs people are waiting on, and each "update" is a risk at breaking VS. The quality of MS software (SQL server, VS) is lower these days, so I'd rather take a chance only a few times of the year in updating VS.

@Dean: Thanks, Dean. I'll forward your feedback to the editor team. We didn't really rewrite the "editor" this time, but some of the underpinnings moved, like the registry. We've found an especially bad case on Win7 we're working through that can seem like "random" issues to users on Win7 when they often switch from running as Admin to running as a normal user. Please let me know if that may be related to the issue you are seeing.

Posting is fighting me again, so I'll break up my response here... so more to come.

The best way to route issues like this to the folks who work on these issues is to log them in the feedback tool. It posts your issue to the developer community. It will also help us connect your feedback to any crashes that Windows reported from the application. Reporting the feedback using our tool gives us insight into what was happening in Visual Studio right before you experienced an issue. You can even report performance issues and we can get traces.

@Roman: Please make sure to log a feedback item. By logging a feedback item, we can get traces and see what is happening on you machine. Visual Studio 2017 should not be taking long to load. Additionally, we've seen some specific issues on Windows 7, if that is what you are on, we are working aggressively to resolve.

Again, the best way for us to act on what you are seeing is to open a feedback item using the built-in feedback tool that comes with the Installer program and Visual Studio.