 On today's Visual Studio Toolbox, Scott Hunter recaps all of the amazing things the.NET team showed at Build. Hi, welcome to Visual Studio Toolbox. I'm your host and joining me today is Scott Hunter. Hey, Scott. How's it going, man? Great. Thanks for coming on the show. I'm super excited to be here. It's right after Build. I know. I know you've been pretty busy with Build. There are a lot of things that were announced, but I thought we would do in this show is review what you guys said at Build, what you shipped, what you announced, and then we'll spend time talking about what it all means. We'll give people pointers to the videos and the demos. You and Scott Hanselman did a great 30-minute video and a really great hour-long video that we'll have pointers to. Everybody should go watch that. Then what I really want to do is go a little bit more high-level and figure out what it all means, what you guys are thinking, what we as.NET developers can look forward to, coming down the pike, and we'll do that all in a reasonably short period of time. Cool. All right. Let's start off with a recap of Build. Yeah. Let's show a couple of the slides that I had at Build. Sure. We always start off talking about, Robert, when you probably started using.NET, if you probably remember, we used to only have desktop and web. I do. Then over the years, we've had Cloud, mobile, gaming, IoT, AI, .NET's grown a ton. People always ask me when they see me, it's like, well, .NET's been around 18 years. How is .NET doing? We've added a million five .NET Core developers, we shipped .NET Core in March of 2017. That's when the tools showed up in Visual Studio. It's only been about three years, a little more than three years. Stack Overflow just ranked us in their 2020 Developer Survey as the most loved web framework and the most loved other framework. That was both AS.NET Core and .NET Core. For a project that open-sourced in 2014, we are one of the fastest highest velocity projects in GitHub. C-Sharp is the number five language in GitHub. We're seven times faster than Node.js, and it's taken by our benchmark, a public benchmark that we work on. A lot of the people that are using our tools are brand new. We have 40 percent of our .NET new developers are students. Not only is ASP.NET Core seven times faster than Node.js, but it appears to be dramatically faster than ASP.NET based on the full framework. That is true. There's a variety of reasons that come to that. When we built ASP.NET web forms, the version of ASP.NET system web that's in .NET framework, we tried to maintain the most compatibility we could with classic ASP or ASP server pages, what they were called at the time. What we did is we took all the objects from ASP.NET or ASP server pages, and we cloned them into ASP.NET. What this means is every request that comes to system web allocates all of those objects, which ended up being upwards of 20 or 30K per request. If you look at something like .NET Core, it allocates on the order of one or two K per request. There's a 28K difference in the amount of memory used, and what you find as a developer is, the less memory you allocate, the faster you go. Yeah. Let's talk about adoption. Once again, I just said earlier, we're 18 years into this thing. In last year, we added over a million brand new .NET developers. Never used the tool before, and I think that 18 years into the life of a framework, that's a great number. Yeah, it's amazing. Of those, 600,000 of those were .NET Core developers. You see that momentum happening around our open-source cross-platform lightweight version of .NET. Then the crazy thing is, one of the visions of .NET Core was to run on Linux, because we saw the world of servers moving to the Linux platform in containers and stuff like that. We saw over a million developers use our tool chain to actually output a Linux publish from that, which is amazing to think that Windows only tech in 2014. In 2019, we have over a million publishes, not necessarily to the Cloud, but at least to your local machine, which you could copy somewhere. Right. Then Robert, you're so familiar with this. As we shift .NET over the years, whether it was 1.0 or 1.1, 2.0, 3.0, 3.5, 4.4, 5. Most of our developers took years to move from one .NET to the next .NET. When I first joined Microsoft, I struggled with this. It's like, man, it takes forever to get the customer on the new version. With .NET Core 3, 75 percent of all of our customers had at least tried the new version within the first six weeks of shipping it, which has never been done before for us. So it's super exciting. Now, let's talk about some of the new stuff that we announced at build. We had two things that we announced at build. We shipped Visual Studio 16.6, which is the new version that supports some of these new features, and that's the stuff you can try right now. Then after that, we're going to talk about some of the stuff that goes beyond that. First off, we shipped a new product in .NET Core 3.0 in September of last year called Blazor. Blazor is some pretty cool tech. It's like, if you go to modern websites, they all have what we call a spa, single-page application. They feel kind of desktop-y. When you click around on the whole screen, it doesn't redraw, they're very fluid, and every app that you build with Blazor works that way, except normally those spa applications, you're right with the JavaScript framework like Angular or React or View, but now we let you actually write these apps fully in .NET. C-Sharp, they can run on the client, and C-Sharp, they can run on the server. At build, we introduced Blazor WebAssembly, and this is a really cool upgrade to the tech where we actually can run C-Sharp inside of your browser. So why might you want to do that? Well, if you're C-Sharp's running in the browser, it can take advantage of the CPU on the user's computer. It can run offline, meaning that you unplug the network or we did a demo at build where we were showing an app you might check in a car at a rental car facility, and maybe sometimes it can't find the Internet. Well, because the C-Sharp is running in the browser, it can keep running and storing stuff in local storage, and then when the network comes back up, it can re-synchronize to it. When you build one of these Blazor WebAssembly apps, you get a checkbox to make it a progressive web app, and that's when the browser will say, hey, this app can actually run as a desktop app. You want to install it as a desktop. You click that box in your browser, and then suddenly you'll show up on the start menu. It'll run without the browser Chrome on it. It's super cool, and it's now available in the.NET Core 3.1 SDK. We also announced that.NET Core 3 came out with WinForms and WPF support. Even today, we still have millions of developers building desktop apps, because these frameworks are super fast and easy to build. But we've been trying to catch up on the tool side of this, and we shipped 16.6 at build, but with 16.6 also came the previews of 16.7, and preview one of 16.7 available now. These can run side-by-side, is close to having all of the controls in the WinForm designer available for you to use. Once we ship 16.7 preview two, then we'll work on third-party controls. But as a WinForm developer, it's going to be easier to move from.NET Framework to.NET Core, because you get that same designer support that you expected. Then finally, the last big announce it builds is we shipped a framework called ML.NET about a year ago. It's a.NET Framework for building machine learning. Now, machine learning is complicated. Examples of ML.NET you might be using today that you're not aware of, is if you have a device that supports Windows Hello, that's where you can look at the screen or the camera, and it'll sign you in, that's using ML.NET. If you're using PowerPoint and it suggests some styles to you, that's ML.NET. But our job in Visual Studio is to make your life as a developer easier. So what we've done here is we have a tool inside of Visual Studio where you can actually go click the machine learning thing you want to do. We'll walk you through a wizard asking for images or text or whatever, and then we'll actually build a model for you and inject the source code to consume that model directly into your application without you having to know a lot about machine learning. So we think this is a super exciting direction. That's cool. It seems like it has the possibility of hiding a lot of the plumbing that you might eventually want to learn, but to just get started, it'd be nice to not have to figure that out first. Exactly. Then we go off the rails here a little bit and we talk about, this was a dream of mine. I joined Microsoft in 2007, and a bunch of my colleagues Phil Hack, Scott Hanselman, Damian Edwards. We all talked about this notion of .NET at that point in time was kind of fragmented. There was Silverlight, there was Windows Phone, there was Compact Framework, there was Mono for Xamarin, and could we get .NET back to a simple platform? We started with .NET Core, but now that we've shipped .NET Core 3, we want to drop that Core moniker and switch to .NET 5. The idea here is, let's take the best parts of .NET Framework, .NET Core, and Mono, and when I say the best parts, I mean if you were going to build a brand new app today, we don't want to go take the oldest tech from .NET Framework and move it in. We want to take the modern tech you would use building a brand new application. While .NET might have had .NET Remoting, today we think GRPC is a much better solution, so we don't bring it over. We take the best of those three frameworks. We merge them together and that becomes .NET 5, and this will ship this November. It has a single SDK that can build all of those app types. It's got a single BCL. I mentioned before, Mono and .NET Core and .NET, we want to have just one base class library that stands for that's where your strings and date times and a lot of the types you use are, and with .NET Core, we introduced this new ability to say .NET new run. We want all that to actually be for all the app types. We want to have awesome support for cross-platform native UI. If you want to build apps using native controls that run on Windows, Mac, Linux, iOS, Android, we'd love to do that. We want to have awesome cross-platform web UI, and I showed some of that today with the blazer stuff that we talked about. We want to have everybody's heard these terms, and I'm sure you've heard a million times, Robert, containers, Kubernetes, microservices, Docker. We want .NET to be awesome in that space. Then of course, we always want to make it better in size, and speed, and diagnostics, and stuff like that. We really think that the end of this wave of .NET 5 and .NET 6 that we're going to have the best breed solutions for all those current workloads. The one .NET really appeals to me because right now, there are three things as .NET Framework, there's .NET Core, there's Xamarin running on Mono, and there might be something that you want to use in an app, and then you discover that the version of the framework you're using doesn't support that. I wanted to use async main in a Xamarin app and it's possible I couldn't find it, but I think it's because Mono doesn't support it. I'm not going to admit how much time I spent messing around with it until it suddenly occurred to me, oh, this just isn't supported, time to move on. Yeah. One of our goals is, we hope that's going to happen with this transition is, we break those scenes down. You get exactly the same features for every one of those app types, whether it's a desktop app, a Cloud app, a mobile app, an IoT app, a gaming app, the exact same feature set across every single thing, the exact same tool chain. I think it will really help the platform and we're going to do something else cool as part of this too, that I think is exciting. When I say single SDK, one of the things that.NET Framework sometimes gets is it's big. It's got a lot of stuff. We want to make even the SDK modular, which means when I install the.NET 6 SDK, all I'll get by default is going to be class library and console apps. I'm not going to give you desktop or ASP.NET or mobile unless you ask for it. So imagine having a really, really tiny lightweight SDK and you do something like.NET add mobile or.NET add web. I think that's going to be cool too, and we want to open it up to the third parties as well. So third-party libraries can actually do.NET add their library, and they can use the same features that we're using to compose our own framework. Right. This is a big area of stuff that we talked about at a build and Windows has some really cool new features that just came out. A new version of Windows just came out about a week ago as well, and that is the Windows 10 2004, and it supports something called WSL. WSL stands for the Windows Substitution for Linux, and it lets you actually run Linux native on your Windows machine. This is cool for a.NET developer because I can actually build a microservice and maybe my target is actually going to be Linux. I'm going to run it on a Linux server in the Cloud. I can develop locally in Visual Studio and control that five and F5 directly in the Linux, just as fast and natively as I could run it on Windows on that same machine. Always trying to make microservices smaller. So in this case, I showed a demo where I took a microservice that was 45 megs in.NET Core 3, and in.NET 5 it was 17 megs. Then probably the coolest thing on this list of things here is we've all built. I'm sure you've done this, Robert. You need to have a.NET app, and maybe it's got a front-end app, maybe it's a web front-end, and it's got a back-end app that's an ASPnet web API. Maybe it even needs a SQL server. Getting Visual Studio Toolchain to launch all those the right way and swap the ports between them is all complicated, and so we have this new thing called TI. With TI, I can literally do run the app one time, and we'll run all the apps, and those apps can be either.NET apps or they can be containers. But you don't have to write doctor files or anything like that. So if you just say, I want to run this image, and we'll go and do all the heavy-looking for you, and that's our investment in the microservice space. This is something that you and I have talked about before this, Robert, and this is cross-platform native apps. Yes. This is an exciting thing. We're introducing .NET multi-platform app UI. That's a mouthful, and so we're going to abbreviate that down to .NET MAUI. And obviously, .NET MAUI runs on the .NET platform, and what it gives you is it gives you cross-platform native UI. So against all those targets, it'll do Windows, Mac, iOS, and Android. Hopefully, we can do Linux as well. This is one of the coolest aspects. If you've ever used a Xamarin project, they're kind of complicated. They have a project for each of the platforms. So you have an Android project, and an iOS project, and a Windows project, and a shared class library. In this case, it's one single project, one single code base to build all those targets. From that single project, you can just right-click and say, deploy, and from that deploy, you'll get a list of all the devices that you might want to deploy to, and they'll just run. One of the things that I showed Robert a couple of months ago, is one of my favorite features is, it's a feature we've added to Xamarin, where I can basically take a Windows PC, plug an iPhone into the Windows PC, and run my app on the iPhone. Yeah. I don't have to have a Mac or any special things. I can do it all with a free developer account from Apple. And so for the first time ever, you can actually build and deploy for your own testing, apps directly from Windows to your iPhone. Yep. And this tech is actually just an evolution of Xamarin Forms. I like to think that this is the next gen of Xamarin Forms, where you're taking in what was successful, and then made it easier to use with the single SDK, the single projects, the run on multiple devices. Something else I should call out here is because we can run on those multiple devices, I can now build the app locally with no emulators, because I can just run it on Windows, or on my Mac. I can build it locally and run it on the Mac, which means I don't have to wait for that, the slower emulator to actually work to get that app to run. The .NET MAUI is gonna actually be in as, and they're calling the one .NET as a .NET 5 slash .NET 6 wave. We'll have previews of .NET MAUI out with .NET 6 towards the RC of .NET 5 later this year, and this is awesome native UI. One more thing I wanna talk about in this space, Robert is, you might have to ask me, what about UWP? A lot of customers have asked us, what are we doing with UWP? Yeah, because the Windows guys announced, are talking about WinUI 3, and then I've heard about their plans for WinUI 4 and beyond. So WinUI 3, I think targets .NET 5, and then they're talking about WinUI 4 as being the UI that would be native cross-platform. Exactly. A lot of customers have asked us, hey, when with .NET Core 3, where was UWP? And Robert has nailed it. The Windows team was already working on something called WinUI 3, and this is basically an evolution of UWP. It kind of gives the developer more choices. UWP required your app to run in a kind of a contained environment, a container, which gave it security constraints. If you wanted to go to like test the file system, that was hard to do. UWP had different features, depending on the version of Windows 10 you ran on. And WinUI 3 is very similar to .NET Core, where they shift the actual framework with your application, which means it works on all the versions of Windows 10. And then as Robert said, it supports both .NET 5 and C++. And the cool thing is, as you said, Robert, if they get to the point when there's a WinUI 4 that actually works on all those platforms, maybe even .NET MAUI uses WinUI 4 as it's back in. We don't know that yet. We have to wait and see where things should. But that's a- The addition to or instead of Xamarin Form XAML? Well, remember, let me step back a second. So Xamarin Forms today, what Xamarin Forms does today is it actually uses a variety of different tags. So if you're on iOS, it's using the frameworks on iOS. If you're using Android, it's using the frameworks for Android. If you're using Windows today with a Xamarin application, it's using UWP as its implementation. So for all the platforms that Xamarin runs on or .NET MAUI in the future will run on, we use whatever the best native tech is for that platform to render the controls. So when you write a button, it's a Windows button on Windows, it's an iOS button on iOS, it's an Android button on Android. So the .NET MAUI apps can use, that's the rendering platform. I think you're asking a question, what about the XAML that you actually use? Yeah, that's true. There's a distinction. Yeah, separate those two things a little bit. So as the set of native controls, that's what you were saying MAUI would use moving forward. Then there's the question of what do you use to lay out the design time? Is it XAML or does it wind up being something entirely different? So it was a great conversation with Scott. We then went on to talk for another 20 minutes, so we decided to split the episodes in half. Please join us for part two, where we talk about what this all means for developers. Thanks for watching guys. I'll see you guys in the next video.