 Excited, because right over here in the back, we have Scott Hunter and Mike Harsh with Beth Massey. I want you to grill them all about .NET. Let's go to that right now. Hey guys, this is Beth, and I'm the Product Marketing Manager for .NET. And I'm here with Mike and Scott. You guys wanna introduce yourselves? Sure, I'm Mike Harsh. I'm at GPM on the Windows platform team. Scott Hunter, the director of PM on the .NET team. All right, so we had some amazing .NET announcements today, didn't we? Okay, so I think the number one on Hacker News all day has been the open sourcing of WPF WinForms and WinUI XAML Library. What the heck is that thing? Okay, so yes, it's been trending on the number one spot on Hacker News all day, which has been awesome. That's fantastic. I think there's like 225 comments already, so it's been awesome to see. So there's been some comments on Twitter too. So folks have talked about what is the story with UWP? Why is that not being open sourced? So there's a little bit of naming confusion, so I just wanna straighten that out a little bit. So Windows UI XAML is the official name that we're calling the UI SAC that's in UWP. So the UI that is built into Windows for the UWP program model, we're calling Windows UI XAML. That name is actually reused. That is the name of the NuGet control package that we released to build. And that is what was the first part of Windows UI XAML that was open sourced today. That will be the project on GitHub that we eventually put all of the Windows UI controls and the rest of the Windows UI XAML framework into. And so timing-wise, that will kind of happen throughout 2019. Okay, gotcha. So not everything is open right away, but as we make more code available in the coming months. Is it primarily the controls? Today, what's available is a set of the controls and the things that are in the Windows UI library to get packaged today. Those are all open sourced. And then we're gonna be rapidly adding more controls to that and then a little more slowly, but still hopefully in the next year, all of the rest of the framework. So the app layout itself will actually be there as well. Yeah, and the layout engines, all of the data binding, all of the things that make a UI framework, a UI framework, not just controls. Awesome. And I know this was like one really big ask from the community. So it's really nice to see that's happened today. So really exciting. Do we already have pull requests and everything actually? There's been some really interesting discussion. I've been paying a lot of attention to the WinForms repo. So I kind of, I should admit, I started my first job at Microsoft in 2000 was as a PM on the WinForms team. So I worked there for about six years. So I have a lot of passion for the WinForm space. And so I've been really paying attention very close to that repo today. And there was, I think, two really interesting discussions. I mean, Orin had the first pull request that Scott did on stage. That was really cool to see. One kind of spontaneous thing that happened with the community today was some of the icons. So the WinForms had to work all the way down to Windows 98. And Windows 98 didn't have a built-in hand icon. And so there was a hard-coded resource. And that meant that you always got the hard-coded resources. And if they changed the system, you didn't get the new ones. And so there was a pull request to say, why don't we update this and not use the hard-coded one anymore because .NET Core 3 works down to Windows 7. Obviously, Windows 98 hasn't been supported for a minute. And so that was a pretty cool thing to see. And then there's this other thing called the Task Dialog, which is a Windows feature. It's like a super message box. And there was basically a discussion around adding a new class for that to both WinForms and WPF so you can get kind of a super message box. So it's already like the community's kicking in. Good things are happening. That's awesome. Well, okay, so let's talk a little bit about .NET Core 3. And it's supporting WPF and WinForms. It's pretty cool, too, right? Yes. What's the big benefit of that, Scott? What do we get? When .NET Core was created, it was meant to solve some of the problems we've learned over the years building .NET Framework. The primary one being, sorry for my voice. I know you're sick as a dog. The primary one being, how many .NET Frameworks can you have on a machine? So we technically support two today, .NET Core 2, I mean, .NET Framework 2 and .NET 4X. 3.5 is actually a variant of two. So there's always been only two versions on a Windows machine at a time. So one of the benefits you get with Core is obviously you can have as many cores side by side by side as you want. No longer do you have to worry about risking and application breaking because the framework changes. I see. And we don't try to break anybody's applications, but the reality is fixing a bug, maybe you depend on a bug and you don't know you depend on a bug, that happens. I mean, stuff just happens. We wouldn't give customers more control. Another cool thing you get with .NET Core is you don't even have to depend on a framework being on the machine. You'll be able to actually take your WinForm WPF application, compile it down to a single lexie that is self-contained, contains the framework, your application, all of those things. And I think what it really means is, as a developer, you can decide to be on the latest version of a framework and not worry about IT having to go and update all the boxes. So it's like X copy deploy for WinForm. It is. It's awesome. NWPF? NWPF, right. And then there's one final other big advantage, I think, and that is Core is where we will try new APIs. And so the latest, greatest APIs are in Core today. Some of the new C-sharp features will only be in Core. So if you want to be on the bleeding edge of APIs, the bleeding edge of language features, Core is the place to be. That said, .NET Framework's not going away. It will never go away. I said this is my talk today. I'm like, it's part of Windows. We have a lot of applications on Microsoft that rely on products. I have this app on my laptop called Visual Studio. Visual Studio, exactly. Built on .NET Framework. Who's ever heard of that, Scott? Right. It will be supported as long as Windows is supported. So the idea is that .NET Framework itself is going to be safe and reliable and always supported on Windows. And that .NET Core will have more of the bleeding edge features. If you want to take something, you can. You can deploy it with the app, so you don't risk breaking other applications. And so that's why we can move faster with .NET Core. Is that what you're saying? And you can be on there. There's two .NET Core. There's the LTS train, which is the long-term supported train, which about one of those comes out a year. And there's the, I want the every other month bits. Got it. Faster track. So you can choose which track of core you want. What LTS are we on now? 2.1? 2.1. 2.1. OK. And so the next LTS will be 3.1. OK, gotcha. So we'll ship a 3.0 sometime in the July-August timeframe, I would hope, of 2019. And that means that the LTS build would show up somewhere in the October-November timeframe if we hit those dates. So what about on the server side? I mean, we've got to have some improvements in .NET Core 3 for ASP.Net developers, too, right? That's the biggest misconception, I think, that people had. We were so heavily focused on talking about desktop at build this year. Yeah. We were so excited about bringing WinForms at WPF to core that we didn't talk a lot about the server. The server is just as exciting as, to me, is the client side. One of the coolest features of all is the client side. One of the coolest features we're going to have is something that we've been, it was called, it was code named Blazor. And this was letting you actually write C-sharp code in the browser. And this is not like fake C-sharp code. This was actually the assemblies download and run in a sandbox. Is it the WebAssembly? In the browser using WebAssembly. And we've been showing that for the last year or so. The first flavor of that will ship as part of Core 3 as well. It'll be part of ASP.Net Core 3. Your code will actually run on the server, but the programming model is still the programming model where it appears that you're writing C-sharp in the browser inside of the HTML inside of that. So you write, they're called razor components, right? Razor components. Great UI, all in C-sharp. And so you have a full stack web development with C-sharp. Full stack. You don't have to write JavaScript at all. You don't have to rely on Angular, React, View. You don't have to write JavaScript. I mean, we're not trying to, this is not a war against JavaScript. Use the skills that you have. If you have a lot of C-sharp skills and you want to use those in the browser, bang, you know, use those in the browser. It's, you know, a context switching sometimes, too. You know, I mean, I think that's why the appeal of Node, you know, Node.js because you're just using JavaScript on both sides, right? So these C-sharp developers can enjoy that as well. I think that's fantastic. Actually, there's a question here that kind of relates to ASP.Net. Are there any modification and requirements for ASP.Net? So the best way to answer that question would be we just shipped ASP.Net Core 2.2 today as well. So not only do we have the 3.0 announcement, we just had the 2.2 announcement. What I would tell the customer is they should move to 2.2. All we did for 3.0, the 3.0 build that came out today basically has the exact same ASP.Net Core 2.2 bits that shipped as part of 2.2. So there's no benefit to move to 3.0 yet. Wow, preview one comes out. Sometimes next year we'll start having the next innovations beyond the 2.2 stuff. They'll start showing up in the 3.0 bits. But today, your best bet is to stay on 2.2. But we aren't anticipating any major changes that you would have to make. Our goal is to make it as easy as possible to move. There'll always be some breaking changes. 2.0 to 3.0 is there's some breaking changes. We assemble the product differently than we did before. I mean, if you're an ASP.Net customer, you're going to have a lot of changes. And so there was .Net Core and then there was ASP.Net Core which is kind of separate. Now we're shipping the whole thing as a monolith again. And that's to enable a bunch of cool scenarios. We have partners like Red Hat that have a version of .Net Core they ship. We want ASP.Net Core to be part of that. So it all has to be built from source. Cool. So how will we acquire the WinForms and WPF? New get packages or how is that going to work? You just go download the 3.0 SDK and type .Net new WinForms and you're good to go. So I'm going to show a little demo of this. I can do a little demo. I'm kind of intrigued. So you're going to take a WinForms app on framework and you're going to port it to Core. So I've got a and first off and he'd also preface Preview 1 is pretty rough. We knew it was going to be pretty rough. We primarily focused on the actual runtime. So most of the work has been done in the Core 3 runtime. The tooling is a little bit behind us. Meaning that File New in VS 2019 does not have WinForm for Core or WPF for Core. We'll have more previews. We don't have visual designers yet. But I'm going to show you how you can actually build a core project and actually use the designers from the full framework application. So if you look at my laptop I've got Visual Studio 2019 here and I've got three apps. And if I run it, this is a memory matching game. You know, you keep clicking these things until you find the the ones that match and you click through and so we thought, hey, let's just port this to Core. So it's going to be a little crazy. What I'm going to do is I'm going to go here and my command prompt and I'll do .NET new WinForms and I'll say output will do matching game core. So that basically builds me a skeleton of a WinForm application on Core. So let's go back to our solution and we'll go add that existing project. So now we have a core WinForm app in here and if I say it in a starter project it runs and builds Hello.NET Core. But really what I want to do is I want to get that game to cheat a little bit. So one of the features we've had in core for a long time is our project system is pretty cool that if you look on the screen here I've got the forums, the program CS and what not. If I look at my project file they're not in the project file. It points at the folder. It points at the folder and we glob in all the C-sharp files. I can also add it glob in from somewhere else. So what I'm going to do is I'm going to cheat a little bit here. I'm going to go take all the code and let's just erase it. I'm going to run that CS project again and I've just for screw this up on stage and paste some code over here and what I'm going to do is paste in an item group that tells the system to basically include files from a particular folder. So in our case we'll just erase this. There you go. So as I say that notice that all the files from the full framework app and the core app. So I'm cheating. I'm aliasing into the existing project. I see. So any code changes that make to these files happen in both the full framework and the core application. Scott, good engineers don't cheat. They're efficient. Now the next thing is if I build this I'm going to see a couple of errors. So let's do a build and first off I get a duplicate type assembly company attribute attribute and that's because in the .NET framework application we typically have a properties app with an assembly info. In core we said why have a file that was basically a place to put metadata. We said in core let's put the metadata in the project file. And so what's happening is in this particular case .NET core is trying to dynamically generate one from the project file and so there's two of these things. So we'll tell it to generate assembly info false better. Now my matching game uses this game logic and I need to reference that as well. So I'll just come over here and we'll add a reference. So you're basically switching project systems and so you're kind of doing some manual changes around the project system itself but not the source code. So the source code is all the same now that reference is there and now I've got the exact same app and it works just the same as it did before. Okay so that's a little manual because we don't have all the tooling yet but as you can see guys you can take some of your apps that you have today and you can see if they're running on core and how they perform and that kind of thing. The repos have instructions on how to do this for both one form and WPF and also if you hit more than just project system issues you can use the API port tool to find out which APIs aren't supported currently and you know the set of APIs that's going to be in three isn't fully baked yet too so if you open an issue with the API we can take a look at that and add that back. If you look at my gaming logic DLL or assembly if you look I actually had a porting problem and because I had a porting problem you can see that I installed the Microsoft Windows Compatibility pack. That's a NuGet package so .NET Core by itself it was designed to be cross platform which means we can't ever put Windows specific things into .NET Core so we have a NuGet package we put out a while ago in the 2-1 time frame I think and what it does is it basically brings a lot of Windows things back it brings registry back it brings directory services back management back and so if you try to find APIs missing the first thing to look at is go and grab this NuGet package stick it in. In my case the game actually saved your high score in the registry. I see. Got it. That's cool. There's another interesting announcement and feature about .NET Core 3 that I wanted to ask you about these things called XAML islands. XAML islands is a Windows feature first shipped in the release that I think it's just starting to roll out now internally we called it Redstone 5 I forget what the actual official name is because the marketing team picks forgettable names on purpose. It's just Windows 10 and there will be some additional improvements on that feature that are coming out in spring release for Windows but basically the idea is you can take a piece of Windows UI XAML control and you can embed it in a WinForms or WPF or anything like that. And then you can start to use new UI features that's what Scott Hanselman showed on stage today with the signature control that's the main canvas and the tool bar from the Windows UI XAML library and just plop that into an existing app. So that's what that feature is all about and that works in both .NET Core three apps as well as .NET framework apps. Cool. So basically you're saying I could take my app and slowly take a onesie-toosie approach to moving it forward. But our goal here is to really bring all these platforms together so you can use any feature in any app type regardless of where you started from. You shouldn't think of it as different platforms. It's just one set of APIs you can choose from based on what you want to do. So I can get a modern browser in my WinForms app now. That's right. That's very similar to that concept that's very similar to what we did in ASP.NET years ago. Well, now we don't care if you start with the WinForm app a WPF application. You want to go ahead and add a XAML UI control. Boom. Just to go to that, right? Just choose the UI tech that you're comfortable with. That's fantastic. And get all the features. Or have a giant codebase that you obviously don't want to start from scratch or write large things if you don't want. WinForms is like 2002, right? I mean it started from the beginning. And then WPF was like 2007-08. So these apps are not that old. They've got some good vintage to them. Yeah, but they're probably business critical. They have to be modified and they have to be updated. But there's still a lot of people actively doing WinForms and WPF development. There's over one million monthly active WinForms developers. I think it's two minutes. I think it's more than that. So do we get performance benefits as well as part of being on the core runtime? So you will get some performance benefits. We've, you know, obviously ASP.NET Core has been performance has been a big push with us. You've seen us take the web stack and be in the tech and power benchmarks. And as a result of that, there's been features added to language span. There's been modifications to some of the BCL to make some of those results happen. You might ask, well, why did you make those same changes into .NET Framework? Well, the reality is like we changed from the file APIs to the .NET Framework. I can never put it in .NET Framework because it would break stuff. And so there are API improvements that also .NET Core is open source, so anybody can contribute. And so maybe something that's too small that we would not look at, but somebody makes a performance fix from the community and we accept it. So you will find that, you know, core is going to be a little faster than .NET Framework. Yes, so kind of a discussion between the two of us. You kind of started to say before what the XAML library is, how does this whole thing kind of fit together with UWP? So you should really think about basically if you have a WinForms review application and you're happy with that and you want to add some new Windows 10 features to a desktop app and you have an existing desktop app, you can start adding those features. I mean, there's many of the WinRT APIs that you can't use in an existing application. If you want to build an application that, you know, is fully topped the bottom brand new and modern, you can start with UWP application. There are, there's a lot of investment we're doing in the UI stack there to kind of address some of the gaps that, you know, customers have told us about for building line of business applications. You know, like shore up some of the data story and form validation that we're actively working on. But the real reason that you would pick especially if you don't, if you're building a new application is you can target other Microsoft devices. If you want to build an app on Xbox or Surface Hub, that's your, that's your route for that. Got it. Okay. So XAML Islands are really desktop related only. Got it. Okay, that's very cool. Cool. Alright, so want to talk about a couple more announcements, Scott? I want to show one more demo real quick. Give me one second. Wow. Two demos from Mr. Hunter. Well, we showed making that game Yeah. using WinForms. Uh-oh. Is this going to be in a browser? Let me shrink this so it fits in the screen for everybody. We also took that same game. It just happened to be that game was written in a great way where all the logic of the app was written inside of that game logic assembly or class library. So it was very easy to go take the same UI and build it in the web. And so I shared that same project. It's a standard two class library. I shared it across a blazer app. And here I have the same game running in the browser. Oh, that's so hot. That's cool. That's so hot. So Wow. I thought I would just show that. That is the goal is, you know, whatever UI you want to build, whether it's desktop UI or web UI, you know, core is going to be a great place to be for that. That's cool. And we keep innovating and innovating and bringing in more workloads there. Like we have ML.net as well from machine learning and AI. We've been doing a lot of work for IoT. Azure IoT runs on some .NET Core stuff. And so in the blog post on .NET Core 3 today, we talked about getting serial port access and IoT for Linux. We're going to do some fun IoT stuff today too. So there's crazy stuff all across .NET. That's very cool. So actually, let's ask, here's a question from no content, a really cute handle. I like that. Well, .NET Native will become for WPF and WinForms now since it's on .NET Core. So you want to talk a little bit about what .NET Native actually even is? Sure. Yeah, so .NET Native is the ahead of time compilation story that UWP apps use today. And so if you're super familiar with it from developing there's definitely some quirks around it because it basically looks over all your code and basically ahead of time compiles it to x86 or ARM. There's some features in .NET like reflection. If you don't have a type there that's already been generated, you basically will kind of get a missing method exception. There's some bad things can happen there. On the flip side, you do get a bunch of great performance out of it. So it is a very interesting story. But I believe that Scott can talk about the the AOT story for .NET Core is going to go in a slightly different direction, I believe. Yeah, we haven't really announced that direction, but you said which is a great point. As we started building the WebAssembly work that's the Blazor stuff. You need an AOT solution. Do we use .NET Native or do we use something else? Currently the Blazor work uses mono actually. Okay. Because that runtime had more support for WebAssembly types of things. The one thing we want to be very good when we're very clear about is when we do a new native implementation we'll do it where .NET can be .NET all the time. Like Mike said .NET Native made some sacrifices for security and performance by removing parts of .NET. Whatever we do in the future we'll give you an AOT that actually runs all of your .NET code. So it might mean that we have to use an interpreter along with some of the native code. But I want to make sure that whatever .NET we give you is the full .NET. And then if you want to go dial some of it down, if you want to go turn reflection off for security reasons or size of device or whatever because you made this decision to do that you understand that there's less compatibility there than there was before. No surprises basically. But I don't think the AOT wave will be after the .NET Core 3 wave. So we'll ship .NET Core 3 with Blazor running on the server side and hopefully we'll start previewing some of the AOT stuff after that. Cool. And I think to close the question a little bit for no content there. Basically I want to make sure that the AOT story that we developed for Core also applies to UDP. So you have again one can, you know, all this is about having consistent .NET story everywhere and we want to make sure that we kind of close that gap. We've slowly been trying to get to what we call one .NET which is one set of compilers, one set of garbage collectors, one set of jitters, one set of APIs. I see. And you'll continue to see us shrink and share stuff more and more across the various runtimes. Today the runtimes would be mono .NET Core and native. Gotcha. And because open source has really kind of like changed that culture so now we can actually kind of do this now right? I mean before it wasn't possible. Certainly easier. But it takes, AOT is hard so it'll take some time. It'll take some time. Cool. All right. By the way Skullcrusher for Life, you are awesome. Did he just build that demo while in the middle of the session? Nice. So that's, shout out to Scott. Nice job dude. One more question here. Can I now use WPF and or WinForms from PowerShell Core and or on Linux or Mac? So I don't actually know how to answer the PowerShell Core question. The Linux or Mac is so basically WinForms and WPF still rely on a bunch of Windows APIs for input, output, for drawing and so those are still Windows desktop only components so we have nothing more to share there as far as announcements. I'd like to add to that though, people ask this question all the time. So we've been talking about .NET Core 3 and desktop for a while and it's like hey, you're going to make WPF cross platform or you're going to make WinForms cross platform. I don't really think you want a WinForms app looking like a WinForms app on a Mac or a Linux machine. So I think we haven't decided or even the industry has not decided yet what the best cross platform UI story is. And so while it sounds great to say WinForms could run on a Mac, a Mac user would go, why do I have this weird X in the window? I don't have the dots over on the left side that doesn't feel like they match. Why did you make my Mac look like Windows 95? It would make a Mac look like Windows 95. So I don't think these are the right technologies for that. I don't think Microsoft today has a story on what cross platform UI is. That's something Mike and I would love to work on in the future but we're not there yet and so I but yeah, these are Windows tech. I think for the PowerShell one that PowerShell core runs on Windows Mac and Linux. So yeah, you could probably call some I mean, there's probably a bunch of types. Like if you wanted to go use a system dot drawing rex, you could, you know, like there's a bunch of types that don't actually have UI backing. I'm sure you could use inside but if it's going to you know, basically if it's WinForms, it's going to do anything H-Win related or you know, draw something. Yeah, it's not going to work. Yeah, it's not going to work. Okay, make sense. Windows is .NET core to build self-contained executables. Is it similar to Go-Ling? That's a good question. Yeah, so that's kind of a long roadmap discussion again. So what we'll do in the 3.0 timeframe is we will give you a, we'll have some technology we have that will basically take the assemblies that make up your application and compact them into a single Exy. It still is all those individual components. They're just package better into a single Exy for you. Okay. The Go question is more of are we going to provide native Exys on those platforms? And that comes back to the AOT store we talked about earlier for WebAssembly and for .NET Native. Right. And what ahead-of-time compile AOT is something we are definitely looking at post the 3.0 wave. Okay, great. Exciting. Alright, so one more question here. Are you going to enable enable application domains and DLL unloading? So app domains is a good one. That is, that is something that obviously as we've been working with partners to support their WPF and WinForms apps, it's come up in it. No. It's pretty rare that people actually need this kind of process level isolation like features, but there are some APIs on AppDomain that are useful. And so we're working to create an AppDomain class that has a lot of API functionality that, you know, more or less but doesn't actually have the kind of code isolation of an AppDomain, but it has some of the additional features that people, we found people using from that perspective. Yeah, a lot of customers use AppDomains today to load extensions and, like, even Visual Studio. I'm sure you're using AppDomains when you install some other extension to Visual Studio. It lets them load some third-party DLLs into the application and you can unload them. We're going to build a new library on top of Core for doing that. Very cool. It won't be AppDomains. AppDomains actually combined a whole bunch of random stuff together. Yeah. And some of it didn't work very well. I see. And so we don't want to bring the stuff that didn't work very well forward to the core. But, like, just to suggest these things together that, you know, and we could make an AppDomain API shell, basically, or shim that would use the, you know, do the loading and unloading, but, you know, so it would be API compatible with the existing code but then could call the new better functioning, actually APIs under the covers. But we'll give you the same functionality that most people want to use it for, which is loading extensions. We're building a new API right now for that. Cool. Awesome. And as a general shout out to any API questions, the best thing to do is to use API port on your code and, you know, either send us a report or share that via a GitHub issue so we can keep track of these things. Because now that we have a public base to keep track, it really helps us steer the roadmap. And we had a blog post about, unfortunately I don't know it off my head, the URL, but we had a blog post in August that we had a lot of people on the team put up. And we actually had a tool you could actually run and just point it at your exe, and it would basically look at the APIs and all this, so you felt safe. It would show you the output of what it was going to send. And then you would press send, it sends us the APIs. That information helps us a lot to know what, what APIs to port. Okay, so that we can take a look and say, hey, we know a lot of people use APIX, we're going to support APIX. And this is not on my stupid, it basically just says, these APIs as many times, not necessarily what you use them for, it's not terrible news or anything like that. That's awesome. Let me throw a question in and just myself off. It's a common question. Would you like to host the next session? No. Another one that comes up a lot is, what is our story for WCF? I thought before I wait for it to show up on the screen, I thought we'd just talk about it a little bit. Let's talk about WCF. A lot of .NET framework applications are using WCF or they're using .NET Remoting. They're using .NET Core at this point. But we are looking at alternatives. There is GRPC, which is an RPC model, which is very similar to a Remoting or a WCF model. Okay. And so the ASP.NET Core team is working with the GRPC project themselves to make that thing have first class .NET support and actually make it, like it feels very similar to like an ASP.NET or something else would, so we're looking at that. Okay. And we're also potentially looking at parts of service model, which is the guts, the low level bits of WCF that we could bring forward without bringing all of WCF. So we're looking at various angles of how do we solve the RPC problem. Because that is a valid concern and we need to have one on .NET. That's a good point. Do you guys want to talk a little bit about the .NET Foundation announcement today before we have a little bit of time here? Well, of anybody that should talk about the .NET Foundation announcement, so yeah, today, I just thought we were talking about .NET. Let's talk a little bit about the .NET Foundation and I think, who better to talk about it than us because we're on .NET. So one of the announcements was about the governance model changes. So basically expanding the board from three to seven people and six of them being able to run anybody that has contributed anything to any .NET Foundation project can run or can vote. I think that's going to let the Foundation really scale its efforts more, right? So why does this like, really why do I care as a developer? Well, you care about your platform, you care about the longevity of your platform and the size and the health of your ecosystem, right? So that's kind of what the Foundation is about in general, right? It's that center of gravity for open source around .NET and if we have more people that have a stake in that and help move that forward, we're only going to have more growth and more success with the platform. So that's how I took it and yes, I am the appointed member on the board from Microsoft. So I have huge passion in this area. So I think that's going to be like a fantastic new era for .NET. Well, I think another big point in the .NET Foundation is historically, if you look at the last couple of years, the .NET Foundation feels more like the Microsoft .NET Foundation. And what the governance model really is about is about making it equal for everybody. There's only a single Microsoft representative that has to be in the foundation. The rest of it is community elected. So it is not heavily tilted towards Microsoft. The Foundation historically has also been funded by Microsoft and it's going to go to a self-fund cycle as well. So it's going to become more of an independent foundation that's run by the community and not something that you could interpret the older version of the foundation as more of a Microsoft run thing. Right. And I think there's even rules in there like where only two Macs, I think, board members can be from the same company. So you can stack. Yeah. So that makes it even more open, more fair and get better. The idea is to get more ideas as well from other companies as well. And to be more open, to be more less Microsoft. We're writing this open source wave and we want the .NET and the .NET Foundation to be as open as possible. So we have a lot of things that we can do, right? When we have that extra money, we have those extra bodies, we can scale more, we can have different types of events. We can help our community do the things they really want to do. So I think that's pretty cool. I'm excited. Hey, it's been saying on the front page of Hacker News all day as well. So the community must be excited too. Yeah, I'm actually pretty excited about that. So are we worried about voter fraud for any of the positions? We only use .NET for that. So there is a question here. So there looks like they're having a discussion of what are the benefits of joining the board? So that's actually a really good question. When Scott asked me, I was like, first of all, why me? And then I was thinking about it really though. It's a volunteer position and you really are about directing the platform, directing the ecosystem. It's really about making choices that are going to benefit .NET. And when I say .NET, I mean the platform itself as well as the community around the platform. So that's kind of why you would join the board. You have some passion around .NET open source and you want to help the community. And that's how I see it joining the board. I am excited. I have some ideas and I can't wait to see who else is going to be on that board. So elections will start in January. Yeah, if you guys want to run, we'll have all the information on .NETfoundation.org websites about that. So that's very cool. Are you going to run? I guess we have one more slot for Microsoft. You have one more slot for Microsoft. I'll have to see the competition. Awesome. Cool. So we got a couple more questions here. Let's go ahead and say any plans for UI automation for core or UWP? So we do have UI testing for UWP and for Windows apps with one app driver. I'm assuming you're actually talking about the UI automation class though. I'm assuming that's what the question is. I'm not sure there's a bunch of different scenarios that UI automation, you know, it can be used for accessibility tools, it can be used for testing, it can be used for actually doing some other scripting of scenarios. So I think I don't think there's any plans right now for any of the frameworks to have UI automation at least in UWP but it would be really interesting to know what the scenarios they're looking for because that's the thing that we probably have a good answer for based, you know. Cool. Is there anything else you guys want to say to the .NET community out there on Twitch before we wrap it up? Big thing is download .NET Core 3, try the bits out, give us feedback. I mean the reality is, this is preview one, I said it was really early, really raw but we have like 10,000 people that ran that tool showing us what APIs they needed. What we need is more people to try it and give us feedback. And definitely go download .NET Core 2, which is released today so make sure you get on those new bits. Thank you so much, Mike. Thanks, Scott. Thank you, Beth.