 Hi, welcome to Visual Studio Toolbox. I'm your host, Robert Green, and joining me today is Art Leonard. Hey, Art. Hi, how are you doing? Welcome to the show. Thank you for having me. Art is a principal engineer in Visual Studio LAN, and so we're here today to talk about Visual Studio. Yeah. We're going to talk about some of the crazy things that we've done to make it work differently this time around so that folks can get access to things that they couldn't do with it before. So, hey, have you tried out the Visual Studio preview yet? I've not tried out the Visual Studio preview. You know what, now is a good time. Okay. Time. Now, before we look at the preview, I just wanted to do a little bragging. Okay. We were checking out on Stack Overflow recently. They had their most recent survey of what languages people like, what things people don't like, et cetera. And if you check this out, if you look at development environments, most popular development environments, what do you think is number one in the web space? Please tell me it's Visual Studio. Visual Studio, and Visual Studio code is right up there under desktop developer. Guess what? Visual Studio. Awesome. Visual Studio code number three, sysadmin devops, Visual Studio two, trailing only Vim. And for data scientists and engineer, Visual Studio. Awesome. I'm telling you, man, it's winning. Awesome. You want to check out the preview now? I'd love to check out the preview. So what you're going to see here is you're going to get access to an early version of the next thing that's going to come out from Visual Studio. So it's still all Visual Studio 2017. Cool thing is that you're going to be able to install this right next to the one that's already gone in your box. You're going to be able to use it right now. So in the past, what would happen is that you would get Visual Studio 2015, you would get Visual Studio 2017, and you'd only get one copy of each. Right. And you'd be limited to that. And yeah, that was OK. But we really want to get folks access to early bits. And it might be the stuff that's going out in the next update. Well, we've got to have a way to get that to you on the box. But the problem is if the old one is still there, we don't want to mess up your current device. Exactly. The rest of your team is probably at the release version, hopefully of 2017. Yes. So if you want to check out the newest version, you can do this without actually going and disrupting your flow with everything else you're doing. Cool. So I see you're already up on the website. Yep. OK. Which is visualstudio.com forward slash vs forward slash preview. OK. Now, quick question. Yes. Do you have enterprise on your box or community? Yes. So we're going to go click on that link that says Download Visual Studio. You're going to pick the same edition that you have. That'd be enterprise. That'd be enterprise. OK. It should download a little program. We call the Bootstrapper. I'm going to trust you. I can't see your screen from where I am. There it is. There you go. Just go ahead and run that. And now I'm on Wi-Fi. So this will take a tiny bit longer than it otherwise might. It shouldn't take too long. So go ahead and click Continue. This is going to update. We have an installer program that's actually built differently from how we've done other programs in the past. It's built on Electron. Are you familiar with Electron? Electron is Visual Studio code based on the Electron ID. Exactly. Exactly. HTML, JavaScript. OK. So what this has done right now is it's told the installer, hey, you want to start listening for other programs, specifically go listen to what's available out on the preview channel. OK. And so it went out in fashion. The owners said just enough of what was out on the preview channel to say, oh, in order to understand this channel, I need to go and get, we don't usually use the word channel, but to go and understand the preview, I need to update myself. So right now it's going through its self-update process. And so it's basically downloading a new copy of itself. OK. And hopefully Wi-Fi is merciful to us. Hopefully. And it's already downloaded. It will restart itself. And it will get you started with actually getting the preview of the next version of Visual Studio. OK. Give it a minute. It's reading the status from your machine and reading the status from the web. And it will start you up. There you go. So that says preview. Now does it so it doesn't necessarily remember what I have installed? No. OK. Which is fine because I might not want to install all of the same things. Yeah. So I'm going to have you install what we call just the core editor. Super basic install super quick. Like you can demo this, it's that quick. Right. So I'm going to draw your attention to one cool little field that we added for this. So it's called the nickname field. Yes. And what I learned early on is that if you don't change the nickname field, then it just says two. Yeah. It doesn't tell you what it actually is. So I'm going to call this, oops. My keyboard is not working for some reason. There you go. Now folks can see what you're typing. And, well, nothing. I'm going to type int preview. Sure. Int preview, good enough. Install. Yeah, we limited to 10 characters. So what's going to happen now is that's going to do the installation. The reason why we give you a nickname is because in places like the Start menu, in places like File Explorer and stuff like that, you need a way to understand which one you're going to go talk to, which one you're launching. And so we use the nickname as a way of giving you some control to say, hey, this is the one that I intend. And you can rename the Start menu. Item, if for some reason you left it at two, right? It doesn't affect the installation. It's not like you have to uninstall and reinstall. You haven't messed up anything other than the shortcut names. Yeah. OK, good. Yeah, that's all things is controlling. And, yeah, a better default would be awesome in the future. We're giving you the control. Right. So we've already downloaded it. I don't know if you've noticed that. Yep, it's installing. It's already 29% done. It's finished acquiring packages. It's 29% done. The team is for it. So it's installing it into a separate folder on your box. And you'll be able to run this side by side with the first copy of ES that you put on and be able to get to look at some cool new features. So I guess a question I have, I kind of understand sort of the pros and cons of separate folders. A pro of separate folders is that each instance is in isolation. So it makes it easier not only to install new ones but to uninstall. But on the other hand, you're duplicating pretty much everything, right? So it takes up a huge amount of disk space. So how did you decide it's done, by the way? Yeah, pretty cool. So one of the cool things that we did when really analyzing what is Visual Studio, the stuff that's in that Visual Studio folder is really when you think of how we break up the application. It's really three, four, five core things, one of which is the thing you think of, which is Visual Studio itself, the application. The second thing that it includes is a bunch of SDKs and runtimes. That's the stuff that you use to build your application, not the stuff that Visual Studio needs to run on itself. Right, so here's my enterprise. This is the public release version. And there it is. And then I also in here have preview. And there's enterprise. Yeah. Cool. All right. So you have now two copies of the application on your box. Now, we've done analyses of what it is that we're shipping, because we pull things from all kinds of locations. There's a certain amount of it that is Visual Studio application, certain amount of its SDKs and runtimes, and a certain amount of stuff that's like configuration that we do to the box to make it more debuggable, better for development. So when we looked at what we did in Visual Studio, what we call version 14, so 2015, we found roughly six gigabytes is what we would max out at the core application. That's like all the project systems, all the stuff that's in the VC folders, that stuff only comes up to about six gigabytes. So where's the rest of everything else come from? Well, it's all those runtimes. Roughly back then, we estimated somewhere around 24 gigabytes of runtimes. And then there's some caching folders that we have. And then there's some diagnostics and stuff that we do on the system. And that's actually fairly small. So a lot of the disk space that you're talking about is in the SDKs and runtimes. Those things we call, those are singletons on the box. There's only one copy of those. So when you talk about, well, when I'm installing Visual Studio side by side, how much of it am I copying? Am I copying 40 gigabytes of stuff? No, we're maxing out at about six gigabytes. But in your case, you probably only have about 350 megabytes of copied stuff. OK. OK. Yeah, so what you've got on your box now. So what we've done to get the installation speed up is make sure that we get you down to just what you need to get your job done. So that's where we built the new UI that basically has a way for you to select these are the things I'm really, really interested in. In the past, we didn't have a good way for the customer to basically say, you know what I'm installing Visual Studio, I want just the web stuff. And when you have just the web stuff, well, you actually get 99.9% of the desktop, like what we used to call WinForms. And some of that has these odd dependencies on some of the things that comes from the C++ tools. So when you install the web stuff, you would, this was early on in like the Dev 12, Dev 14, what we called it, those are the internal names we call them. 2013, there was no Dev 13, Dev 14 was 2015, Dev 15 was 2017. Correct, just to keep it perfectly clear. So there wasn't, so you ended up having to like draw the transit of closure of all those things together. And so you ended up with a minimum installation size that was six gigabytes, not a good day. And then you would have to update the run times for each one of those things that went down on the box. So you'd end up in this state where like, I updated this one thing, now I have to reboot. And it was a painful experience. So what we did when we were analyzing Visual Studio, to figure out what we, just to get the customers what they needed, was we tried to identify commonalities like as a customer, like try to install Python. What did I need from the stuff that came from the web tools? The answer is, well, nothing. So we came up with some ideas and there was a team that actually went and figured out, well, if I just wanted to get an editor, how much would that take? And it was only, it was under a hundred megabytes, it just got you an editor. Not a lot you can do with just an editor, but it was under a hundred megabytes. So based on that, we said, well, let's instead of, you know, just throwing everything in to get everything done. Let's try to throw a few things in to get a few things done. And it turns out that would make our installation time go down and take our dependencies on updating the operating system way down. And we figured out that we could get a lot more flexible for the customer, get a lot more speed to get bits out for the customer, and it also identified some opportunities where, you know, what happens if we don't ship project system? What if you don't need a project system to get you worked on? Like you're working on Node.js. I don't necessarily need a project system. We do have a project system for Node.js. But if I'm going to build a Node.js application, let's say I'm going to go build an electron application. What do I need? And the answer is, well, you don't need a lot, but you need something. So there was another team, one of my sister teams, what built this feature called Open Folder. And so now you can navigate projects free form without the use of projects, without use of solutions. You can add, well, this is my build command, this is my debug command, and you can get a lot done. Now with that 350 megabytes, that's what you just installed on your box. So you're going to get syntax-based intelligence. You're going to get the ability to navigate your folders and you're going to get work item tracking from Team Explorer, you're going to get integration. That's a pretty full IDE. Now when you start to think about it, yeah, you got to do a little bit of customization, but there's a lot of commonalities before like you end up with large enterprise customers that you're even on C-Sharp, say, well, I don't use projects to get my stuff done, I just build projects to get in the VS. There's so much know you can get done now with such a smaller footprint with VS. And so we took that as our base layer and said, okay, now let's start building everything else on top of that, like building blocks. So, and if you go back to the installer, that's where we get, can I see it hiding there? That's where you get, if you go into modify for what you just added. That's for the preview. So that's where we get these things we call workloads. That show up and those are the, think of those as the macro level large building blocks that you can add things on. And okay, here's a cool pro tip. If you want to go and manage a native debugging, you built him. If you go into the individual components tab, just add, it's under the coding and I forgot what we called it. Yeah, the coding tools, if you just add the just in time debugger. What is that? I can't see from where. We're gonna add it this down, right? Yeah, debugging, debugging, just in time debugger and in a future version, we'll be searching in here. Oh gosh, we're trying to get there. Well, future, okay. There it is, just in time debugger. So that'll add a bit to your footprint, but you get just in time debugging and managed in native debugging. Forget whether script debugging. The other one I always come in here for is the GitHub extension, if it's not already checked. So we'll just do the just in time debugger. Yep. Modify. And I'll be down and it should be less than a minute. And so now you've got, actually, if you're just browsing a code base or if you're just debugging an application, so you want to go and attach to Notepad, catch all the places it calls X text out or call something on DirectWrite, you could totally do that now. Right. Cool. And if you've got symbol server support turned on and source server support turned on, you're set, you're done. I used to work on the office team and there's a lot of times we're dealing with a very large code base. That would be the way that we would go and just try to figure out what was going on in other people's code so we didn't have to go and build their sources. Done. Yeah. I love the fade. That's new here in this brand new version of the Studio B, the ability to fade in and out. So any of you, anybody who was watching who was wondering, is that real? Is that new? Yes. All right. Should we launch? Oh, sure. Let's launch the preview. It'll go ahead and synchronize your settings with your, because you're already logged into your account on the other instance. Yep. And we'll go get your settings from that. Okay. Cool. Yeah. Cool. Now, how would I know what's new in the preview compared to the previous version? All right, it's got his head down. We're finding ways to. Okay. We're looking for opportunities. Best ways to get you to, right now, the first way. There should be release notes or something, right? They're absolutely releasing. Thank you. If you go back to the installer. Back to the installer program. Installer, would that go installer? Yep. Release notes. There we go. I could have just noticed that it said release notes and clicked right there. Yeah. Well, one of the things we're. Okay. There we go. One of the things we're trying to look for ways is like how to tell you, hey, this is something cool. You want to update to this. The cool thing is that the way we do the release notes, they're actually always up to date. So if you click on the release notes for this version, you see this roll up, kind of like you see on a lot of Git projects where it's actually one steady stream of all the releases across the versions. Okay. Awesome. Yeah. So you want to know how we made this work? Yes. Because there's only one registry on the system. Yes. There's also only one GAC on the system. Yes. We stopped using both of those for the most part. So Visual Studio in the past has had tons and tons of assemblies that live in the GAC. There's a bunch of stuff that lives in its own folder. The first thing we did when we were exploring what could we do with Visual Studio that would make us more agile, ship more often, have less impact on the system? Well, we wanted to have less impact on the system for starters. So we did this experiment where we tried to pull everything that we could out of the GAC. And we just didn't stop it. We actually made an effort. Once we figured out that, okay, we can make the world kind of work by getting out of the GAC, we figured we could get 99% of everything that we needed just totally out of the global assembly cache. So I would imagine that helps to speed up install and uninstall time because you're not writing to the GAC for Lord knows how many assemblies. I think you do know. It's a big impact though for basic things like servicing. Like, okay, if I've got assembly version 15 from you got the release channel, you got the preview on there at the same time. When you've got those both in there, you don't want to have them sharing resources for anything. And in particular, we're loading types and stuff out of the global assembly cache if it weren't for that. You don't want to have those two of them. We would have to make sure that the compatibility is there at a binary level to make sure that the contracts are the same and that is an exhausting and most likely error fraught. We still hire humans the last time I checked. And rather than trying to ensure compatibility across all versions, across all time, what would happen if we just stopped doing that? And the first thing that we were worried about was performance. Well, we actually still do all the same performance tricks that we used to do in the past. When we install, we natively generate the assemblies correctly with all the correct type resolutions and stuff like that. So they're all correctly bound and they are the same performance, performance neutral. That was one of our goals. Could not be any slower than the previous version. And we've had a lot of praise if we did not regress the performance at least from that perspective. We've had some praise about performance in general this time which has been very welcome. They've been a lot of effort. So that was the first thing we did was get everything out of this shared location. The next thing is we started to worry about the user data. One of the pieces of feedback that we got from Windows was that, hey, you guys use a lot of registry space. And it's really optimized to be very small. Well, how much are we using? Megabytes, let's say. We're using megabytes of space in the registry. And that has an impact on startup performance. So now, let's say you had 14 megabytes of just user customization data that we were to store inside that registry. Now, duplicate that multiple times. And we've been told we use more than a typical application does for this type of data. So we decided, well, if we're gonna multiply that stuff, we should probably get it out of the startup path. Make it so that the machine performance isn't any worse. So we actually use a private registry file. There's a cool API that we, a friend of ours turned us on to somebody we worked with for years called RegLoadAppKey. I think it was what it was called. And basically, you can use this yourself to basically say, I want to treat this particular file. And I want to use that for as a RegKey. And we basically said, okay, we're gonna use that file for all of our user settings. And it turns out it works on Windows 7, Windows 8. Started off in Windows 7. We didn't know about it before then. And it works from then on. And it's really allowed us to minimize the impact on the system registry. Cool tip is that if you delete that file, you reset the settings back to nothing. So let's say you start having an errant extension in Visual Studio. Or you somehow you clobber your environment. What do I do? Well, we put all that information under an app data folder. And you can reset the entire environment by just deleting that one app folder when you're done. Cool? Yeah. So does that postpone startup time from beginning to when you launch Visual Studio? I mean, you still have to read that registry, right? Does it take less time to find that same information in the private registry than it did in the main registry? Or is it the same amount of time? We actually measured it. There's about a 50 millisecond startup performance to go to that. All right. The thing is, we really think we're moving that from the start of the operating system to now. It's just when you want to run Visual Studio. Right, OK. Yeah, we measured it. Cool. But it makes Windows startup faster, which is always a good thing. Cool. Considering you're going to be running Windows, we hope. So give us a sense of how much work this all was. And when did you start? When did you first have the idea? And when did you start? How long did it take? We started having these ideas back in spring of 2015. OK. We started the exercise of pulling things out of the GAC. Spring of 2015 was about the time we had just finished Visual Studio 2015. So you finished 2015 first, and then you said, OK. Yeah, and so we asked ourselves, I have been talking about some of these ideas that we've had for years. And some folks said, you haven't been complaining about this long enough. Why don't you go try it? All right. And me and my team set out, and we started pulling things out of the GAC. Pulling things out of the GAC took months, because there's a lot of, the bad news about the GAC is that it lets you take dependencies fairly freely. And so you start pulling one out, and you've got to pull the next one. You've got to pull the next one. It's like a sweater. And that took months to get done. But we got done with the core of what Visual Studio was in a few weeks. And then we started playing with the registry. And I think it was about August, we started getting to critical math. So we said, OK, we can actually start doing something interesting with this. What can we do? And we took that amount of work. We got the core out of the GAC. We got the registry out of the GAC. We got other registry. And somebody put forward the idea, well, what if you were to just X copy this thing? We don't use MSIs for the core of the application anymore. The MSI assumes there's only one per system. So that got us thinking, OK, well, what can we do if we were to just X copy this from a folder right down to the operating system? When we figured out we had some problem with licensing, we had to figure that out. Well, let's just cut off that code and see what happens. We got the installation time. I can't tell you the exact number that we got it down to. But we ended up demonstrating this to a bunch of managers and to my director. And let's just say the installation time was even more impressive than what you're seeing on the box. So we got it down to about 80 megabytes. We were able to show the prototype of opening a folder with it. It was we only had a command line install at the time. But let's say I was able to talk over it. And I was able to stop after, let's say, it was seconds. And that was a nice proof of the technology. And we could start up the IDE. It was working. You could show some of these other technologies. And it was lickety-split. And so it was right about that August moment that we had that the watershed that says, well, we think we got something here. We got something that's going to be impactful. It's going to change the way we dog food our own product. It's where we use it internally to get our stuff done. It's been a big thing. We want to get more people using the product to help us find issues before the customers do. So having the access to Visual Studio makes it big to get those daily builds out, get them updated fast. So it had a big impact. It was going to impact the way that we think about how we pushed the bits out. So it was at that point that we said, OK, we got something here. Let's run this through and see how far we can get. And so our next milestone was to get there was this in 2015, there was this event called Connect Event where we showed, we just showed the UI and we showed kind of that same demo, but then we had it actually a bit more baked and we were actually starting to get other people interested in getting it to do something meaningful by that point. And so it was at that point that we finally said, OK, we're going to show that we're able to demonstrate getting Visual Studio on your box faster. We couldn't show customers how fast it was because we didn't want to set unrealistic expectations. But it went from that moment that it was OK, we're committing. We're going to do something in this space. The next event was the build event where Amanda Silver got on stage and demonstrated installing VS in front of a room of 1,000 plus people online. And that was the watershed moment that said, OK, this is a real thing. We're done. This is really going to be the way we ship the product Visual Studio takes, I think we estimate it on average, customers are seeing 88-minute installs. And the fact that you could demonstrate it on stage in under three minutes was a big deal. But what we didn't talk about at that time was the fact that it's actually side-by-side. We talked about it not impacting the system. But the fact that you can actually start to use the previews like we have now, it was a big change in the way you thought about it. Does the concept of the workloads depend upon that work? Or could it have been done independently? Could have been done independently. So we had our irons in many fires, one of which was, OK, let's resegment the way we thought of these pieces. One of the things that we couldn't have done, though, that would have been a lot harder. So in order to do previews side-by-side, you had to do something to get off of MSIs. And you also, it was a good forcing function to make you understand, OK, this depends on that. OK, this impacts the system. This doesn't impact the system. This really belongs to this group of things and to actually understand those architectural boundaries and then get the engineering teams to care about those problems and go solve them. Took a lot of motivation. And then having this impact their day-to-day work, every build we put out internally is an update. And it takes seconds to apply. And this is impacting everybody who uses Visual Studio every day. And the fact that they can, they start to care about how their install impacts the customer. Oh, you made this change, and now you're going to force the user to reboot. Suddenly, when every other install takes 30 seconds, when your one thing comes along and forces the customer to reboot, they start to get into the rhythm of making these things more painless for our customers to install. So how far do you see taking the workloads? I mean, could you get to the point where I might say, look, I want to do MVC, but I don't ever want to have to do, or I don't not have to. I'm never going to do web forms. I don't do web forms, I do MVC. Or could you see getting to the point where, like I go to the new project dialogue, and I see a bunch of templates. And I say, yeah, I want to do that, I want to do that. But no, I don't ever want to have to do iOS. I keep saying have to do. I can't see myself doing iOS watch, so I don't want that. Is that gaining you anything? Is that? So the classic one that we get is the ones that we hear. I'm a Python developer. I don't want to see Csharp. I'm a Csharp developer. I don't want to see VB. Yeah, that was the other one that came up over. I mean, is there a lot of savings to be gained from that? Is it worth the effort? Well, that's the trade-offs that we make. And we have to make those on the fly. And it's not one size fits all. One of the things that we figured out, we can go very far with this technology. But the problem comes in, you saw those two views as we were going through this, the individual components and the workload components, the workload list. Getting the customer to what they want quickly is kind of the job of the workloads. And so there's some strategy and the things that we pick and how we give you selections to solve the problems. Like, OK, I want MVC4 versus the current version. But there's a trade-off, and we try to put the rest of that on the individual components tab, is that there actually are architectural boundaries that we could have picked that were lower in the stack. Like, actually, the VB versus Csharp one is a great one, because really the only difference in most of the technology that we choose, with one or two exceptions, the project systems are for the large part the same. The delta is in a few megabytes. It's the templates. It's the information overload. So in some cases, yeah, we might make it a decision to go and say, let's give the customer what they want. And then there's the other flip side of, you know what? There's a cost benefit. There's a cost to that that may not be worth it to that particular group of customers. You could potentially also do it as just a UI thing. Hide VB, right? It's there. It's installed, but you just hide the templates. So it's not in your face, right? Architecturally, the tagging isn't quite that robust. I imagine we could, if motivated, there are obviously creative things that we can do. OK? I had a question in mind, but it's not slipped. This is fun. This is fun stuff that we've got to go do. So talk a little bit more about some of the other changes that have been made, some of the decisions as to what versions of things. So the individual components. Some things are checked. Some things are not checked. Like I noticed that on the basic install.net framework, 4.6.1 is checked. But then 6.2 is not. And 4.7 may or may not be, depending on when you install Visual Studio, right? Because 4.7 shipped with the creator's update. So I think if you already have the creator's update installed and then you install Visual Studio, I think 4.7 is checked by default. But there's something along those lines. How are those types of decisions made? Some of it is practical. Some of it is a matter of, some of it's strategic. Some of it's practical. Some of it is, we didn't really think about that yet. So some good examples. We do try to get you what you have on your system. So we have this ability to, OK, does this machine have Hyper-V available to us? OK, we'll give you access to the emulators and stuff like that. There is also one of the things that we've gotten feedback on this. But there was an important trade-off that we made. Selection doesn't work the same as unselection. So the selection is not the reverse of unselection when you're going through the UI. So the idea of the UI is it's well designed to bring you to the things you want quickly. So it's designed well to do that. So if you start from a workload, you pick the extra things that you want. You unpick the other things you want. It works really well for that. It is not a complete mathematical, like unpicking things does not have the complete mathematical opposite effect. And the idea is really trying to get the user to what they really want at the end of the day. So let's take the .NET frameworks. I know, for example, by the way, we don't install the .NET framework other than a minimum framework that VS uses, which is, I think, 4.6 today. We ensure that that is on the machine, which is really important for folks on Windows 7. But by reducing our dependencies on things that are on the system, you get a faster install. So we don't require it. Now this brings me back to what's in the UI. What you're seeing there is dependencies on things like targeting packs. So that's the minimum. So if you're gonna go build an application, that's the thing that you use to go ensure that you take in the right dependencies on the minimum version that your customer is gonna go use for the application. So there are certain groupings that we try to give you. And we're trying to optimize the UI when we do that. So in the desktop, for example, we don't need to list off, we're trying to optimize for how much visual information you have to process to understand, this is what I'm gonna get. So for example, the targeting packs, we really only give you one line item to begin with, which is I'm gonna give you this range of targeting packs. Back over in the individual components tab, though you can micromanage that to your heart's content. Right. So that was one that actually we kind of weighed pretty heavily because each one of those targeting packs can bring in 90 additional mechs. So if you're hard pressed on your main SSD, you might wanna micromanage those experiences. Have you thought about the ability to save your install choices as a script? Yes. Because I know, I hope I am nowhere near like the normal customer, but I install Visual Studio probably 20 times a year across various machines, whether it's a home machine or I got a new home machine or I got this machine, this machine needed to be repaved, this machine needed to be repaved again. I installed Visual Studio from an internal release and then I uninstalled that and installed it from the public release. And then I decided to install the preview and I always choose the exact same things. And at this point, I know where they are, so it was pretty quick. Oh yeah, we weighed this pretty heavily. We've thought about this from the first prototype, this is one of the things that we thought, oh, customers could totally get some advantage on this. One of the things that we would need you to do those to sign in. And what we didn't want to give customers that makes impression, this is the first time looking at a whole new user experience for installation. And what we didn't wanna do was give them the impression that you have to sign in to get Visual Studio. We know that there are other customers and others- Why would you have to sign in to save these things to a file? Gotta have a place to store them. You gotta have a place to store this information. You could store it on the local drive but you were talking about the experiences where they go, most of our customers that are installing multiple times a year are installing on VMs or they're installing on a new box that they pay. So, it's certainly, it's on our backlog and it's something that we've, we haven't had a lot of customers ask for but man, it's one of those things like, gosh, as soon as we have another reason to go and do sign in, maybe that's the next thing we go through. Yeah, I guess, and then if you wanted to sign in, the installer would give you, install your default as a choice, right? That would be a choice, my usual thing. And then you could name various combinations of workloads, something as a profile. You're describing my backlog now. Well, I love doing that on the show. It gives me the opportunity to toss out ideas. Sometimes they're already been thought of and sometimes they're like, oh yeah, that would be cool. Why don't you go write it? Hey, I've got a great program where you can go write a lot of stuff. Cool. See, what's, what's, oh, I remember the question that I was going to ask. So, back in the, if you remember the days when Office had the adaptive UI, right? Where the menu choices would change based on things that you did over and over again. I worked in Office in that area. Yes, which was, at the time, it was thought would be helpful to the users and it might've been, but it was kind of a support nightmare because people wouldn't necessarily have the same menu items as the person and support was having and it could lead to a lot of confusion. So, the more you give people the ability to choose what gets installed and what doesn't get installed, is there a trade-off between that type of flexibility and that type of specificity and the burden on support? So, we're learning as we go. And we do reach out with the, we do talk to the support guys often, actually. We have an ongoing set of discussions that happen on a routine basis with them. I don't know, I haven't heard that particular one coming through support. Most of the issues that we're seeing are things like getting folks to, not necessarily on the selection, but just dealing with issues that we've had in certain components, having trouble getting on boxes and stuff like that. All stuff that we know, we get the customers through it. And another cool pro tip, there are certain conditions that we've found that you can actually mess up your boxes. This has been great from a support perspective. You can find us online, there's a KB article on it, but if you need to reset your box to say, okay, forget about what I have installed, I just need to start over. We have a program for that. So that's the kind of thing that we hear about from support most often, is because Visual Studio brings all these SDKs and runtimes down that I was talking about earlier, the application, we're not having a problem with the application, that's practically X copied on there. We actually have a package that we are signed and we're able to secure from that perspective and that's how we get the core application onto the box. But these other things were the things that we were having trouble with and that's the stuff that customers were having issues with. And a little bit of our own, making sure that we understand what things are on the box. Those are places where we're having a little bit of trouble. There's a cool program underneath there, I forget the name of it, it's Install Insulation Clean. Oh, cool. That's included that just reset your box and you can start over and that unblocks most everybody. So that's more than just the regular uninstall? Yeah, so let's go back a little bit on how this thing works. My team, I work on the IDE team. So our job is kind of the core of what Visual Studio is and the way it runs. We, in the past, we've done a lot of the UI. My team did the solution navigator. We used to participate in some of the ways that commands work, the tools, menus and stuff and that's all moved around through other teams over the years. But so I'm responsible for the main way a bunch of the way the IDE runs. My sister team actually does a bunch of the setup work and so we've been partnering closely with them. Having this integrated experience actually gets the bits onto the customer's machines faster because we can do this in a much more integrated way. The cool thing about the way we deliver bits onto the system is like I was going through, like I was talking about with the registry and getting out of the GAC is that by having less impact on the system, the application gets on the box very robustly. You're copying bits from one spot to the other. All of our registration information is packaged into files called PKGDEF files, packaged def. It's what we've been using for years for extensions. We don't use the registry for our COM. We use a technology called Reg Free Com built into the operating system and we do that and then we have our own private registry for settings. So we don't need to go and put a bunch of information on the system to be able to run VS. There are a couple of things where we do have to put information on the system but those are a handful. So by doing that, our VS stuff is very robust and all the other stuff we're working to improve those but now we can focus on making those things a lot better. I don't think I answered your question at all. Does a lot of this work, will a lot of this work extend to Visual Studio for Mac? We've looked into that a bit. We're talking with them about what can be done there. Okay, so don't know yet. Okay, so another question about the previews. Is the previews where I would find previews just to Visual Studio? Would I also find previews to other things? For example, Xamarin, which gave you the ability from inside Visual Studio to install their preview bits, their alpha, beta channel, or you could stick to the stable channel. Now when Xamarin has a new alpha channel or beta channel, will that show up in Visual Studio or do I have to have the preview installed? Do you know? I'd have to talk to those guys about what's exactly their strategy. Right now, the Willow, sorry, that's what we've called this thing internally, you know, somebody on Twitter figured that out. The installer itself is tuned for Visual Studio, the build tools, all the windows-based stuff right now. We've thought about what it could mean for the future, but in the future we haven't made up our minds yet. But the stuff that's in Visual Studio, so Xamarin has a presence in Visual Studio, so we'll make sure we're talking about the same thing. So anything that's in the Xamarin stack for Visual Studio will be available in the preview along with the rest of Visual Studio. Okay, okay, cool. Yeah, totally, yeah, it's different from the Xamarin and the Visual Studio for Mac, sets of things that are going on, but all the stuff on windows will appear in that preview channel. All right, very good. Yeah. Cool, that's awesome. Yeah. Thanks for coming on the show. Absolutely, thank you for having me. Thank you. Hope you enjoyed that look behind the scenes at Visual Studio. Thanks again. Thank you very much. And we'll see you next time on Visual Studio Toolbox.