 Hi, I'm Scott Hunter, and I'm here today with my team to announce .NET Core 3. To start off, let's talk about what .NET is. .NET is this platform we built for building any kind of application you have, whether it's a desktop application, a web application, Cloud, mobile, gaming, IoT, AI. .NET is a general-purpose framework for building all of these types of applications. I'm super excited to talk about .NET Core and how far it's progressed. It's only been out for a few years, and we've already grown to over a million active .NET Core developers. .NET Core is our first fully open-source .NET framework. In the short time, we've actually been open-source. We've already taken 100,000 PRs. So we're building this not just by ourselves, but with the community. Of course, Visual Studio 2019 is the fastest adopted version of Visual Studio ever. Here's a couple of our customers that we have to build on top of .NET. We have an awesome page on the .NET website you can go to to see all of these customers and read the stories behind them. So I highly recommend you go and check that out after the conference. Let's talk about .NET Core 3. You can actually download this right now. You can go to the .NET website and get it right now, the bits are available, and it brings a bunch of awesome enhancements to .NET Core. First off, we brought desktop support for WPF and Windows Forms. Any .NET Core application gets the ability to be fully side-by-side and self-contained, meaning .NET doesn't have to be on the machine. We're going to introduce a brand new way of building web applications where every web application is a spy application. Then of course, we're always making you more productive with Visual Studio, C-Sharp, and we're going to talk about a lot of these things today with my team. To start off as well, Visual Studio 2019 16.3 just shipped as well, along with Visual Studio 2019 for Mac 8.3. Both of these versions of Visual Studio support .NET Core 3, C-Sharp 8. They have a ton of productivity improvements, performance improvements, and if you're a mobile developer, they support iOS 13 and Android 10. So they support all the latest stuff. A bunch of our partners have released brand new tools today for .NET Core 3. If you're a web developer and you're going to use Blazor, our new spy application, there's controls by DevExpress, Tellerik, and more that are available today. So please try these things out as well. So the first thing I want to talk about is microservices. Microservices is a new developer phenomenon that's taken over in the last couple of years. When I first started doing development, we build these what we call monolithic applications where you build your database and your front end, and your back end all together in a combined application. That was great when we had small teams building applications, but as these applications have gotten bigger and crossed into more spaces, it's more important to break them out into smaller pieces. So those individual teams can actually work on those pieces. Not only can you build microservices, but you can also host microservices really well in Kubernetes. What Kubernetes does for you is it's an orchestrator and that orchestrator will basically take your application and manage all the components, whether it's configuration, whether it's scaling, whether it's making sure the application is still running well. We have an awesome one of these called Azure Kubernetes that runs in our Azure Cloud. Now, with.NET Core 3, it's the first version of.NET Core that really, really, really enables you to build microservices. So what we've done is we've added a bunch of new features. One is we have something called GRPC. What GRPC is, it's a form of communication that gives you strongly typed contracts between the application. But what makes it unique is it actually works across all developer technologies. We're going to show it in the context of.NET and C Sharp today. But what's cool is you can actually build a microservice using GRPC and you can call it from Java, you can call it from Node, you can call it from Python. Any of the languages you want will support this. The next thing is worker services. While we built great web frameworks the last couple of years, as you start thinking about microservices, you want these long running applications that handle responses, request and responses. So we now have a first class template inside of Visual Studio in.NET Core 3, that lets you build these worker services. What's cool about this is you get all the same features. You get the configuration, the pins, the injection, all the logging, all those things that.NET Core brings, are available there as well. We're going to show that a little bit later on. Then finally, as you build these APIs, you want to make sure they're super secure. So what we've done is we've actually worked with one of our partners to make sure that you can actually securely secure your endpoints using a DDD server. So with that, what I'm going to do next is we're going to have Glenn Kondron come on stage, and we're going to build a.NET Core 3 microservice, and host it up in Azure. Hello. Hey, Glenn. Hi. How's it going? It's going great. Why don't you switch to your machine, and let's show us the microservice. Yeah. So a bit of context for what we're going to do here, is I am going to build this weather microservice, this service, and then all of my friends after this, they're all going to come in and they're going to consume this thing from an AKS cluster. So I am going to encapsulate the logic of going and grabbing the weather data, I'm going to cache it locally, make sure I honor expires, and it's not complicated but it's not trivial, so we'll make our own service for it. Instead of having everybody talk to the weather API themselves. So what I have here is, I have just a normal file new GRPC service, I have a console app, and I have a not standard class library we're going to use later, but they're all standard, except that in my weather app, I have already set up some config for the URI, and I've put in some user secrets and stuff so that you all don't try and steal all of my tokens. So first thing we need is a worker. So I am going to add this class, we're going to call it weather worker. All right. And this thing's responsibility is going to be to go and grab the weather data and get it in the cache locally. And like this. So I have some snippets for pretty much all of my code. So this inherits from background service, which we had a little while ago, this is how you can add a service that will run forever. You know, I've got to do some logging, some config. I need config to get my URI, and then in Kubernetes it actually uses the Kubernetes config provided to grab all the secrets from Kubernetes secrets, which is kind of cool. I have a hard-coded location ID, because you know, you don't need any other weather than that what's in Redmond's. And then the meaning of this is this execute async method. And all it's going to do is loop for as long as the app is going make a HTTP client, going to go and call the weather API, get some JSON response, use the new system text JSON that we added to deserialize that to a type and then cache it. And then it's going to do that every 10 minutes forever for as long as the app's running. And so I'm missing this forecast data. And this is how does the weather endpoint I'm hitting represent the weather? And so I'm going to add another class to represent that. Call it weathermodel.cs. You know, if I cannot put some extra caps in. So what I did to generate this, I have a snippet here for this now. What I did to generate this and what you can do is I just grabbed an example JSON payload from the API and I just copied and pasted it as C sharp into Visual Studio and just made this whole thing for me. And I'm just going to ignore it. That's a cool feature. Visual Studio can basically take your JSON and convert it to C sharp types. Yeah, absolutely. It's a super cool feature. Then, okay, so now I have a worker. This is done. I'm good now. But except I need to tell the app that it's going to go run that worker service. So now over here, I'm going to start doing some code. I'm going to add.addhostedservice, which is the name of this feature. Add weather worker, right? And then this needed a few things. It needed like HTTP and like caching, right? So services.addHTTPClient. So I can inject the HTTPClient and then I'm going to add the memory cache. Memory cache so that it has a memory cache, right? This now when I boot this app, it's going to go into every 10 minutes and go and get some more weather data. Pretty simple, pretty cool. Now I need an endpoint. So Scott talked earlier about GIPC and some strongly typeness. So this GIPC is a very contract-driven approach to RPC. So I have a snippet here, which gives me this proto file, which is the contracts for a GIPC service. And so I have this proto file that says I'm going to make a weather service. It's going to have a get weather streaming endpoint, which should stream weather constantly. And it has a get weather that just returns you a single whatever the current weather is. And it also defines what the actual response type is. Nice thing about making our own proxy for this weather data is we get to choose the actual surface for our clients and make it relevant and not have too much extraneous data, right? So if we just call this weather.proto. And then in here, the way this actually works is in my CS.proj, I have this proto.buff element, which references that weather.proto. You see the rename worked, good job team. And it says it's going to generate server because the way that GIPC works is you create a contract and then you generate a lot of code and you just implement the bits that matter and you leave all the rest to be generated. Right, I write that contract and I generate either a client or a server using the tools. Yeah, exactly. And so then we're going to go create a weather service now from my snippet. And so what we have here is a service that implements this weather base and that's that generated code that we just talked about. Well, so we just controlled on my way to glory here. I have the base class. I have a memory cache because I need to get the data out of the memory cache. And then GIPC doesn't want you to have empty method calls but because I'm hard coding the weather for Redmond in this case, I've just got this empty type to fill in for the request type. You would probably in most cases have an actual type here that has your data, right? Yeah, past your location or something. Yeah, something, yeah. And then I just have this get current weather response. All it does is left hand, right hand code to say take that pasted code, the pasted model earlier, convert it to the one that we want to actually give to all of our friends later. And then get weather returns one and then forget where the stream, it just loops for as long as the person is connected, it just grabs the data out of whatever's in the cache currently and then loops, right? And then this is every 10 seconds just so that it's easy so you can see something for the sake of the demo. We might actually even make this two seconds. Just so you can see some data constantly changing. We know the data will only actually change every 10 minutes or so, but you want to kind of keep a constant stream happening, right? And then that's it, that's greater service. So if we'll rename this to weather service so that, you know, just because we can't have a class with a different file name, that'd be terrible. And then in our startup CS, the way you register these services is we have a map gRPC service endpoint, right? So now I can change this to weather service. And that's it. At this point, my app can run and it'll go do its job. And so now you want a client to go grab some of this weather data to test it out. So I added this console app earlier conveniently, but I also added this weather client lib. So I could go over here to my client console and then add a ref to the proto file and have it generate the client code straight into my console app or any of the .NET stuff that we're gonna show today. But what I could also do is I can come over here, I have a completely empty NEST standard class library, except for like the default class, which I'm gonna delete, right? And then I can right click on this and say add service reference. And then click add new gRPC service reference, browse to the proto file that I had earlier, that are the same proto file that my weather app is using to generate the server code. And then I can say generate client though, here in this dropdown, right? Instead of, there's some other options for what you can generate. I'm generating a client in this case. And then just going, okay. This is gonna go install the new Getty goodness that you need to make gRPC generate code and generate all the types that you need. So this is pretty cool. So you built a service, we built our first microservice, we installed gRPC into that. And now you want to write a client. So all you had to do is basically reference that same proto file from your service and your client and we'll generate all the code for you. Absolutely, yeah. And you just, then it generates you kind of the basic, yeah, it generates you all the codes for the client's class, yeah, absolutely. Then all you do is new it up and start making calls. Yeah, and so let's look at what that looks like. So I'm just gonna add a normal project reference now to my client class library because everybody can now share this net standard class library that has the client code generated in it or they can choose to reference it directly. And then in my program CS, I have another snippet here where the client, right? And I think it's actually the whole class I did this time. And then what I'm, so yeah, you can see here, like as you just said, this weather client was all generated for me. I just knew it up. I used this channel type to give it the address. And then I have a strongly typed method for get weather async, which was in my contract file. You just start calling the methods and getting the results back and write them out to the console. Absolutely, so now I can like control our five, this weather service, it'll spin up on my local machine. You'll see that we'll see the console output in a sec. It's gonna see the output, go fetch the data and then sit there and be a GRPC endpoint. And then, so here you can see it going and getting the data and then being ready. And then over here, I can then like go debug, start new instance of my client console and my client console will ping up. It's gonna grab a single weather and then just say done in this case because I'm just grabbing, calling a single weather endpoint. Asynchronously, I'm using async like console app that we added a little while ago. And then that's like apparently 53 seems reasonable. So that's pretty awesome. So in just a few minutes, we built a brand new project using the worker service. Long running process, like you would build a microservice. It goes out and fetches weather from an endpoint somewhere. And then we actually added GRPC to that service. So a client can call into that and get that weather data back. Yep, absolutely. Well, let's switch back to the slides for a second. And we'll talk about C-Sharp. So along with on the core three, we're also shipping the next version of C-Sharp, C-Sharp eight. It has a bunch of new stuff and we kind of broke it down into buckets. One of the things we think about is we always want to make your code safer to write. We want to make it easier for you to catch the errors early or prevent the errors from ever occurring. And so there's some new features called Nullable and C-Sharp eight that try to address some of that stuff. Modern as well, as we look at language, we always are looking at other languages and we're looking at the patterns that developers are using today. And so one of the cool features we have in C-Sharp eight is async streams. And we're going to show those in a little bit. And then productive. We always want to make you more productive. So the goal of C-Sharp is to add the right features and stuff to make it easier for you to write code and write code faster with less text in the screen. At the same time, also tooling all that with Visual Studio family so you can actually be more productive. So what I'm going to do next is I'm going to bring Mads on and we're going to take the demo that Glenn had and you know, Glenn didn't really write it the best way you could. We're going to make it use async streams. Well, I think Glenn did a fantastic job. It's just that when he switched back to the laptop. Let's switch back to the laptop and look at the proto file that Glenn put up there. There were actually two endpoints here. There was the get weather that he used, that he called just before from the client and there's a get weather stream which continues to stream weather down. So that's the one we're going to investigate now and find my way back to the program here. So there's, if you look at the client here, it also has a get weather stream method. So that's probably the one we're going for and that can't be awaited. Instead we get something that we're going to explore a little bit. So let's just call it response for now and let's start drilling into it. So if we say response dot, we see that it has a response stream. That sounds streaming. Let's do that. And that one has a read all async. That sounds streaming and async. That sounds pretty good, right? Let's do that one. So if I call that, then what do I get back? That's that we can actually drill into that as well. Let's try to adjust F12 our way through. There's read all async. It returns something called iasing and rumble of T. And iasing and rumble, if people remember i-numble is a core type and i-numble of T is a core type in .NET that you can reach and produce new ones out from the language as well with your return with iterators. And so iasing and rumble is just an async version of that. We can actually take a very quick look down the rabbit hole here. iasing and rumble, just like a rumble has a get enumerator, this has a get async enumerator, and if we drill into that, you can see that it has a current property for the value that we're currently looking at, and it has a move next method, but this one is async. So if you think about it, this is a stream where you can pull elements, but every time you pull a new one, you do it asynchronously. So it might take time and you have to wait it. Okay. So that's how that works under the hood. Now, at the language level, we would like to support for reaching over these. So let's try to reach over there. The thing that we got back from our drilling here, so let's call that four casts with an S, because we hope there are multiple, and then we can let's try to reach over it for each bar four casts in four casts. Now what we get is, oh, this thing can't actually be for each. That's because in C-sharp, we decided you shouldn't just be able to reach over async things, because then you can't look at your code and see and know that you're doing something async. We want every await to be visible in the source code. So you can know that you're getting off the thread, you're doing an async thing, it's a point where context might switch and so on. So what we have instead is an await for each syntax that then you use when you have an iasync enumable, and that you just put the right curlies in there for the beauty contest and we're good. So now we've actually called the streaming endpoint, and now we sat in it a async loop around that endpoint. Yes. The code, honestly to me, Mads, you just took a four each and added a wait in front of it, and it works. Yeah, I tried to make a big deal of it, but it's actually pretty simple. Pretty amazing. I mean it's a complicated feature, but it looks so simple when you actually use it. Right. There's more to it. You can actually yield return in an async method as well now, returning iasync enumable. So we have async yield return, that's pretty useful. Right. Amazing. And also there's cancellation built in that I skipped over here, but that's a little more to it. Well, the idea is it should be simple. Later today you're going to have more talks on C-Sharp 8. We're going to drill into more and more features than just the async stream that we showed you. That's exactly right. Yeah. So just after the little after the keynote, there'll be two talks and I'll be sure to. Perfect. Thank you. Let's go back to the slides and we're going to talk about desktop. So today we have still millions of developers building desktop applications. You might ask why? Well, because desktop applications are simple to write. Web applications are hard. They require knowing HTML, CSS, JavaScript, and a bunch of stuff. Desktop applications in .NET, you can just drag some controls to a form, write some code, they're very quick and simple. We've made them much, much better in .NET Core 3. So in .NET Core 3, we've brought WinForms and WPF to .NET Core. But you get all the benefits of .NET Core. So one of those benefits is side by side deployments. You no longer have to worry about an update of the framework breaking your application. You can even take the app or the framework and compile it directly into a single X before your application. So you just hand that application to any machine. It doesn't even have to have .NET Core on it. That's a cool feature in .NET Core 3. We've made all of the Windows 10 APIs available to these applications as well. So you can call all the things. If you want to get Bluetooth or something like that, you can do that from a WinForm or WPF application. Then finally, because it's .NET Core, we do all of it open-source and so we've open-sourced WinForms and WPF. Now, what I'm going to do next is talk about App Center. This is a new announcement today. I started off as a web developer, and App Center for desktop applications really excites me because for the first time ever, if you're a web developer, you can just add some kind of analytics to your website and you're going to know how many people called it, where they're from, how long they were on the site. Wouldn't you want that same information for your desktop applications? If you're building a desktop application, you likely want to know how many times it's been used or all the features being used. So by adding App Center to your application, you get all those benefits. App Center can also be used to deploy the application including beta versions of the applications to a smaller set of people. So super excited to announce that. What I'm going to do next is I'm going to bring Ali on stage and we're going to go build a.NET Core 3 desktop application, and then we're going to actually hook it up with App Center so we can get telemetry on it as well. Right. So let's switch to the machine here. A theme we're going to have today is as we start building applications, we built that microservice. Now, what you're going to see us do is basically build more applications on top of that thing, showing you can build.NET everywhere and share your code. Right. So I happen to have a weather application myself, and that's application. It's a WinFarms app that sits on your desktop and shows you what is the weather right now. Let me show it to you. It's very simple, but it has one problem. I haven't actually finished development of that app. I put together UI, I put some dummy data that shows the weather on Alderaan planet right now. I was going to say that planet doesn't exist anymore, so I- That is why it is so cold, yes. But I would like to actually show the real data for say Seattle. I just heard that Glenn has amazing service running in Kubernetes, and he also has a client library that I can just use in my WinFarms application. Let's do that. Right. Not only that, we can actually use it from any.NET application, right? Mobile, web, WPF. So let's take a look at the library that Glenn created for us. If I right-click on properties, I can see that this library is targeting.NET Standard 2.1, which is great because that's the latest version of.NET Standard. .NET Standard 2.1 ships with.NET Core 3. So it's the latest version of.NET Standard that supports.NET Core 3, but it also only runs on.NET Core 3. So that probably means- Yes, exactly. Is your application a.NET Core 3 desktop app, or is it a framework? No, it's framework because I developed it a while ago where I did not have a choice between core and framework. So if we go to properties, we can see that my app is targeting.NET Framework 4.8. I cannot reference the library right now, but what I can do, I can port my framework application to.NET Core, and then I will be able to use Glenn's library. To do that, we created a tool called TriConvert that will take your.NET Framework project file and it will try to convert it to new SDK style.NET Core project file. It's a simple command-like tool. I'm going to type triconvert.exe, and as a parameter, I'm going to send the pass to my project file. So people understand for.NET Core, the project files are different than they are for.NET Framework. So what we built is we built a global tool that can be installed on a machine, it's a sample to help people convert their CS Proj from an old style CS Proj to a.NET Core style CS Proj. Yes, exactly. Now when I click on properties in my Visual Studio, I can see that now my application is targeting.NET Core 3.1. So in just a few seconds, I ported my framework application to.NET Core. So now I can reference the library, and to do so, I'm going to right-click on dependencies, add reference, find weather client leap, click okay, and once I did that, let's go ahead and update my code that is pulling dummy data at this moment. So I have this method pull weather that just gets dummy data, and I'm not going to need this code anymore. I will also not need the get dummy data, and here I was using the local weather response class, but I'm going to be using the one from the client library. So I'm going to delete that code as well. Now I will insert a few lines of code, I will add usings, and I will talk to those lines. So first thing that I do here, I'm creating a client from the library. Then based on that client, I'm creating GRPC weather forecast service, and for this forecast service, I'm calling getStreamingWeather. So every time the service on Kubernetes is sending out the weather data every two seconds, I'm getting the data on my app, and let's see how that works. So this code looks almost exactly like the same code that Glynda and Andrew sent us a second ago when they were calling the same await, the same stuff. So we're showing sharing.net code across all my application types. Awesome. That looks like a real data, Seattle 53 degrees, and weather doesn't change that often, but you can see that I'm actually receiving new data every two seconds. So once I build the application now, I probably want to share it with my friends, maybe even community, right? I'd love to have us look at that new feature we talked about, single-legsie. That's a great idea. Let's publish it as a single-legsie file. To do that, I'm going to go to Project File, and let me move everything down so it doesn't distract us, and I'm going to insert three lines of code. The first line published single file will make package my application and .net core in a single exe file. All .net core, all your application into one single exe. Yeah. So nothing has to be on the machine that you give the version. Exactly. Yes, it's completely independent from the environment it's going to be running on. Super cool. The second one, runtime identifier, specifies which platform my exe should target. By default, .net core can run on any platform, but if we're publishing it as a single exe file, we need to specify runtime identifier. The third one is published trim. That is a new feature that will trim out all assemblies from your .net core that are not used by your application. So that way, you don't get the entire .net core, you get only assemblies that you need for your app, which makes the size much smaller. Right. Once I added that to my Project File, I'm going to right click and go publish and publish one more time. And while it's publishing, we can see that here you can specify the path where that single exe will be put. You can also specify configuration, target framework, target runtime. All those settings can be set from this page as well. And it takes a while because right now trimmer feature is working. So it's actually analyzing what we can throw away. It basically goes and looks at your app, figures out what the dependencies are as best as can. It's not perfect, we call it experimental at this point. So you might find that it actually trims too much stuff out and you have to go back to your CS Proj and manually add a reference to whatever it trimmed out too hard. That is true, but... We'll build better tech around this in the future and we'll build better tooling, but it is a first step that we wanted to ship in .net core 3. Yes, and as you said, if it trims something out, it's very easy to add it back to your Project File. Okay, so we've published our single AXE and here it is, just one AXE file that I can send to my friends that I can put out for the community and they will be just able to run it and use the app. On any computer that has, does it even require .net core? Yes, yes. So the last thing that I would like to show today is integration with App Center. Yes. Because as you mentioned, web developers have been spoiled for a few years where they could see analytics for their websites, they could see how many users they got, which devices that was accessed from, and so on. And we would like to enable our desktop developers with the same features. So for that, you can use App Center. Let me go to my App Center portal. It's appcenter.ms. I created an account and here you can create a new application, you can configure it, but I already did it for my app. It's Weather WinForms app. Once you do it, you will get very detailed instructions on how to add integration with App Center in your program. And it's super simple, you just add a few new get packages and then you add a few lines in your project, program.cs file. So I will do exactly that. I'm gonna first go and add new get packages that are required, which are Microsoft App Center analytics. And the second one is Microsoft App Center crashes. Once I edit it, I'm gonna go to program.cs file and I will add some usings. This is how I enable App Center in my app. Two lines of code, that's all you're gonna do. Yeah, it's basically just one line App Center.start and I send the key that I get from the console and I specify what I want for my App Center. It's analytics and crashes. Now you'll get detailed crash analytics and you're gonna get monitoring as well, letting you know that people actually tried the project. Exactly, and I'm gonna run it, but it will take the portal a few seconds. So if we go here and we go to analytics, you can see some analytics. So you can see that I was testing that demo September 20 and September 23, just today. And you can see a few spikes. We will have another demo later today with Daniel and Matt that will go deeper and dive into all details of all the great features that App Center can offer. And was that? Awesome, so to recap, what you can do now is you can basically build desktop applications with .NET Core 3, WinForms and WPF. You can make them into single Xs. They can easily be distributed. You can add rich analytics with Azure App Center. Awesome, I'm so excited about this. So let's move back to slides. Next I wanna talk about mobile apps at Xamarin. So Xamarin is awesome technology that lets you take all the goodness of .NET and make it available to all the mobile devices. So the idea here is you can build any iOS and Android app with C-Sharp. And why would you wanna do this? Well you wanna do this because .NET's got all this rich libraries that you can share across all these applications. So for example, that microservice that we showed before, we probably can share that across Android and iOS. That's one of the tenants of .NET and C-Sharp and Xamarin is being able to actually share the same logic across all your app types, Android or iOS. Another cool part of it is we have a library for building apps called Xamarin Forms. Basically you build it once and it runs on all the devices. And of course also all the Xamarin tech is open source like the rest of .NET. Today we have two awesome announcements. The first one is Xamarin hot reload. Imagine you're in your application and you're gonna change some of the Xamarin files. Well you don't really wanna recompile and republish and wait for all that kind of stuff to happen. What you wanna do is you wanna basically save your Xamarin file and have your device refresh immediately. Even better than that, Xamarin hot restart, which is the ability to also change the source code. Normally when you change the source code that's a full recompile, copy back to the device. I wanna be able to change that code and refresh very fast as well. And so this one's in private preview today. You can go to the URL and sign up and you might get access. The hot reload is actually available to download today. And so next what I'm gonna do is I'm gonna bring up James and he's gonna show us how to build some Xamarin apps. Oh, awesome. Thank you, Scott, so much. Now you're in my way, because you know I need to get to my Mac. Get to your Mac. Okay, awesome. Well, like Scott said, I love .NET development with Xamarin inside of Visual Studio. What I love is that, like Scott said, you can share all of your C-Sharp and .NET knowledge across all of your applications. And that's what we've done. I decided that I wanted to take that weather app, import it to iOS and Android and at the same time, leverage that same exact GRPC logic that Olia used and that we're gonna use throughout the rest of the day. Now two important things to remember, like Scott said, we have all sorts of different pieces of technology for cross-platform development. But with Xamarin, you have access to 100% of the APIs in iOS and Android and always up to date. We just shipped iOS 13 and Android 10 support. So on top of that, we have Xamarin forms for cross-platform UI and Xamarin Essentials for cross-platform native API access. So let's go ahead and import that exact same weather application to iOS and Android, taking advantage of mobile features. So here I am on my Mac. Let's switch to the Mac, yes. This is my Mac, boom. And of course, I need to get started with a great design. I'm not a designer, Scott, sorry. But Guzman Barquin was nice enough to have this amazing weather application on Uplabs, which is one of my favorite websites to use for mobile design and reached out to him, super happy that we're able to use it and I'm super happy that he's an amazing designer. So that's what we're gonna do. And I'm over inside of Visual Studio for Mac. We just launched a brand new version with all sorts of new tech, so I wanna show that off too. But where you get started is File New Project. You have cross-platform apps, you have iOS, Android, .NET Core Apps, Azure Functions, Mac, TBOS, WatchOS, everything is possible with Xamarin and .NET. So what I've done over here is I've added an Android and an iOS project and I also have this mobile core. It's a .NET standard library, just like we can use to share across all things of .NET, but it has Xamarin forms in there and this is my mobile specific code. So this is things like my user interface with Xamarin forms, my models, my view models, my app state. But notice that I have that weather client lib that Olia used that Glenn had created. So it's inside of Visual Studio for Mac and I can reuse it right here inside the weather app. So that mobile core, that's the differentiator for Xamarin, right? That mobile core is the code that is shared across the iOS and the Android app. So you write it once and it gets to be used in all the devices. You can think of it, most of my apps have two different .NET standard libraries, one that can be shared with anything. So RESTful service calls, models, things that are just, hey, this is .NET code. Then I have my platform specific code or mobile specific code and this UI runs on iOS and Android. Right. So for instance here, if we take a look at how I built this app, is I have a weather page and a weather view model. So here up top, I have a view model, I have a weather client and this GRPC weather forecast service, the same exact code that Olia was showing earlier. And since I'm going to be using XAML and data binding, I have some backing fields. So for instance, I have a use Celsius, a temperature, condition, timestamp. These are things that my user interface is going to display and I can tell it to update via set property. But here, if we look at this, message weather service get streaming weather. Same code. The only difference here is that I'm telling it how to render the user interface. So here's a bunch of items I want to display in a list. And then when I want to update the UI, I use XAML and Essentials to say begin invoking this logic on the UI thread because that GRPC could be coming in from anywhere. Right. So let me just go ahead and run this really quick. So I'm just going to hit debug. This is going to take my application logic, compile up my Android application and then deploy it to an Android emulator right here running on my Mac. So there we go. My application is starting up. And what we should see hopefully is a beautiful weather application that I built inside of XAML. All right. It's doing some stuff. But let's go ahead and fill this in a little bit more. So I have my user interface code down here. And let's see here. I have a pancake view, which is a beautiful third party control that will allow me to do the gradients in the background. But I think I'm missing some stuff. Okay. So I have a label with nothing in it. So let's just put in Seattle. Now I'm going to use that XAML hot reload. So I'm going to hit command save. It's going to save that and push the changes over into my device. So Seattle right there. Now what we can also note down here is I'm missing some other things in my UI. So for instance here, we can go ahead and maybe put in a new column and then I'm going to say binding and the brand new XAML IntelliSense will kick in and I can say temperature. There we go. Now it does look like for some reason my internet has stopped. So that's good. And I'm getting no updates. So things are working exactly as planned because we're doing it all live. Just super great. But I have zero degrees. So it did show up. So that's really good. Very cold in here. It's very cold in here. Yeah. So other things that we can do inside of here for instance is like this Monday here. So that's just showing a blank. So if I look here on the date, what we can see is that I have current weather conditions, I have this date property here and maybe I want to change this to a capital casing. So I can say use a case converter, say true, hit a save and now that Monday is completely updated 100%. Now what I'll do here because I did change internet right before, we're going to go ahead and stop and redeploy again and bring up a new emulator and see if we can get our internet back on our machine. Which would be very helpful if so. You can see actually how fast the emulator rebooted here. So let's go ahead and see if this is going to spice up for me because having real data would be useful. Always fun to show the real microservice. But you can see how rapidly iterating I was on that user interface using XAML hot reload inside my application. So there we go. We have weather. Oh, hey, cool. So one last thing I want to do down here, actually two things, is I like this collection view which is like all the different humidity UV down here. That's a brand new feature inside of Xamarin form. So here I can say horizontal or vertical, but I'm using a pancake view. So I'm going to add a fancy corner radius here and hit save again. Again, XAML hot reload kicks right in. Boom, I got beautiful rounded. So fast. So fast. But I like teardrops which are new hotness. I think everyone's going to pick up. Boom, look at that. That's great. And I can prove that this is running in real time because down here if I wanted to, I could go ahead and say timestamp large. And now we can see the timestamp from that GRPC client updating in real time right there which is super awesome. And that's XAML hot reload right there inside of Visual Studio for Mac with all that GRPC client, beautiful user interface, boom right there. Now, what I need to do though is also deploy this to iOS. So normally I would just say, set that as my startup project, go into my iOS simulator, boom, good to go. But I want to show off some brand new features of hot restart. So I'm going to actually head to my Windows machine right now and do iOS development. So let's swap places over here. I love this. Here we go. Android on the Mac and iOS on the Windows machine. That's correct. So I'm right over here. Now what I want to talk about though is that it is the same projects, same solutions that I just had open in Visual Studio for Mac. So no matter where you're working, you're good to go. I know your Mac guy, I'm a Windows guy, so ideal setup right here. So it's going to make it really easy to go back and forth. And again, I have my shared code and I also have that iOS project and that shared code and everything else that I have in here. Now, what we wanted to do with hot restart is that every once in a while you're changing C-sharp code. For XAML hot reload, user interface code. You need to be able to rapidly iterate on your app. But what happens when you want to get it on your device? And that's some of the cool tech built into hot restart. So what you're able to do, and what I have here is my iPhone, right here, my iPhone 7, that's plugged in to my Windows machine, okay? And what I have up top is my iPhone right there. It's connected, it's good to go. And what's nice here is that all I have to do is hit debug. If you've ever done this before, you got to worry about configurations and connections and profiles and circuits and all this stuff. But what we're able to do with this technology is restart your application directly onto your device. So here, for instance, I have my device that should be screen mirroring. Let's go ahead and see if it's gonna cooperate with me. Let's go ahead and maybe shut it down and reopen it. Let's do this really quick here. There we go. And perfect. So there's my device. I'll put it right over here. So there's my device right there on the screen. Now what's great about this is that I can come into my UI. Let's go ahead and just make this sticky on top. Cool, that looks good. And what I can do is add some new technology into here. So for instance, maybe I want to convert this into Celsius. So again, I'll just uncomment some code. I have a checkbox, I have a label. This is data bound to that use Celsius. I'm gonna hit save. Now XAML Hot Reload will kick in. And notice that it's reloaded. I hit a breakpoint. I'm debugging my app right here on my device. So I can go ahead and continue on. Good to go. All right, that's good. I must have made some changes to my code that weren't compatible. But no worries. I can just literally use hot restart here to redeploy again. So let's go ahead and deploy. There we go. And you just saw like I stopped, took that, took some changes, good to go. I see it back on the phone already. And now it's back on the phone, yeah. So this is initializing that debug session and XAML Hot Reload. So here's our app, here's everything is good. And now we have this little back and forth. But as you can see, Scott, we have some issues because our hot reloaded that UI but the temperature is not changing. Now the background is, so my converters, my code is running. So let's fix this. If I go into my view model here, we have that temperature property. Now it's returning temp, so that's not good. So what I'll do is I'm gonna say use Celsius. I have full intelligence, everything here. We're gonna use Xamarin Essentials. What's cool about this is it has a bunch of unit converters built in. So you can do like Hertz to degrees, Calvin to Celsius. Here I'm gonna say Fahrenheit to Celsius. And I'll pass it the temp, else just temp. There we go. Make that temp, there we go. Now what we can see is that the UI is telling me that, hey, I've made C sharp code changes to my application. You need to restart your app. And what we can do right here is hit the restart button. And this will take all of my code changes that I made, redeploy it to my device without having to compile it at all. And what's great is that this is literally right to my device in just mere seconds. Those squiggles go away. The application is now back into a debug session that I would expect earlier. And what we should hopefully see here once hot reload initialized. I can hit Celsius. Now we're in Celsius. And I can use my app, MyRealData, use XAML hot reload for my UI, and hot restart when I'm making code changes and deploy directly to my device in seconds with nothing in between. That is amazing. I have never seen mobile development on either platform, on the Mac or Windows, deploy to devices and restart as fast as I've seen with the hot reload and the hot restart. This is a game changer. We want to focus on developer productivity. Make sure that our developers, building mobile apps with .NET have the most enjoyable time without anything in between. No big setup and boom. Between those two technologies, you're going to be hyper productive and share all of your .NET logic like you've seen before. Across all the devices. All your apps. Thanks James. Let's go back to the slides. And what we're going to talk about next is building web applications with Blazor. So, the way I like to think of this is if you're building web applications, we've had awesome web frameworks in .NET for many, many years. But the web has transitioned to this new place where all apps are spa. And so, what if we could just take the technology we already have today and say, you build any brand new ASP.NET core Blazor application. That's an, it looks like razor, Blazor razor. And those applications just becomes sparse by default. That's what Blazor is all about. It's full stack web development. You build an application in .NET, it's a spy app. Using the same frameworks and the same technologies you're used to already. You don't have to relearn a bunch of new stuff. The cool thing about this tech is it also runs in all the browsers. So it's compatible with all the browsers that are out there, whether it's mobile or desktop. And even cooler, there's one final piece which is we have a prototype or in preview thing called WebAssembly. And WebAssembly lets you take your web application and run it directly on the device. That means you don't have to actually, it can be completely disconnected. It can be running on a desktop, it can be running on a mobile device and running as a real desktop application. We do that because we can compile your C-Sharp directly into WebAssembly that can run natively in all the browsers. So what I'm gonna have do next is I'm gonna have Dan Roth come on stage and he's gonna show us how to build Blazor app. Hi, Scott. With .NET Core 3. Yeah, great. Shall we build a single page web app for our weather application using only .NET and C-Sharp? No JavaScript. No JavaScript required? All right, cool. So I'm gonna get close on some of this stuff so I can see my app. There we go. Okay, so to get started with Blazor, all you need is .NET Core 3.0 because support for Blazor server apps is now in the box. So I'm gonna stop the changes app and I'm gonna open up a new Visual Studio instance. And we'll just go ahead and create our first Blazor app so we can just get a feel for how it's done. So I'm gonna create a new project and let's create a Blazor app. There it is right there in the box. Blazor app one sounds like a great name. And then for this app, I'm gonna pick the Blazor server version. We'll talk more about the WebAssembly version in just a second. All right, and then we'll go ahead and get this running. All right, so we can take a quick look at this application in the project and see that there's no JavaScript here, right? It's just razor files and C-Sharp. Let's go ahead and control F5 so we can see what the application does. These razor files are the same razor files our developers have been using for the last nine years. Yeah, so these are a combination of HTML and C-Sharp and it's used to dynamically render your application. So I want to start, oops, sorry. Start without the debugger and we'll just go in and then we'll see what this app does. Now, this will be a simple spa style app like it'll have some interactivity, some tabs, you can tab around, there we go. So we have a homepage, a counter, fetch data page. I can use the back and forward buttons in the browser so I can do client side routing. All of those navigations are actually being intercepted in the browser by Blazor and then handled in the browser without the requests ever coming to the server. The homepage just has a little bit of static HTML, nothing too exciting there. The counter has this button that if I click the count goes up and there's no page refresh happening there. It's all happening that like a client side app would normally work. And then we have fetch data and fetch data is conveniently enough showing a table of weather forecast data. Now, how is this working? How is this possible? There's no JavaScript in my project. Well, let's F12 and look at what is going on in the browser dev tool. So I'm gonna refresh so we can see the network traffic and if you look here, we can see that there's not much being downloaded, it's only about 400 kilobytes of stuff. But if we look a little more carefully, we see there's a web socket connection being set up between the browser and the server. That web socket connection is being used to send all the UI events to our components that are running server side, which then executes the components, figures out how the UI should be updated and sends the updates back down to the browser to be applied to the actual DOM. So that's how it's working. And we can see that in action. Let's look at the web socket connection a little more closely. We'll clear all the messages that have been sent so far and I'm just gonna click and you see that? See the binary messages flying, that's UI events being sent and UI updates being processed. That's how that's all happening. Now let's go look at how the code is actually implemented for that counter component. Here it is, it's a razor syntax, a combination of HTML and C sharp. We can see it's routable because it has this app page directive at the top to say that the route for this component is slash counter. We have some normal HTML markup and then we're using razor syntax to render the value of the current count. We also have a button which has an on click handler. Normally this would have to be JavaScript but here it's C sharp. We're pointing to a C sharp method that whenever time the button is clicked the count gets updated, the component re-renders and that's how you see those updates on the screen. Now each of these razor files is actually compiled into a just a normal.net class that captures the rendering logic from the dot razor file and those component classes can be compiled into dot net assemblies. They can be then shared on Nougat as Nougat packages. You can build reusable component libraries. That's how those component vendors we showed earlier can actually have these components and we can actually just drop into our apps. That's right, that makes your life so much more productive. We could just grab existing components and go. Let me show you how that's done, how you can build your own component class libraries. I'm gonna add a new project to this solution and this time instead of a blazer app I'm gonna pick a razor class library. Now what is that? Well a razor class library is actually just a normal.net standard class library but it's been set up to also be able to compile dot razor files to compile razor components. Here we have a razor component that's in the new class library. It's pretty simple, it's just a div but it does have some styling and this is interesting. The project has this www root folder with a couple of static files. It's got a styles.css, it's got a background image that's also used. This is a new feature in ASP.net core in .net core 3.0 where your class libraries can carry static files that then are made available to the application when the project is referenced or when the NuGet package is referenced. So I'm gonna add a reference to that class library like so, so I can use that component. Now to make these files available in my app I do have to add a link to the styles that I want and we use a simple convention to do that. I'm gonna copy this existing link and I'm just gonna update it. So the convention is it's underscore content is the prefix and then the name of the class library. So razor class library one and then the path to the file that you want. So styles.css and that's all you gotta do. Now we can use our component in our app. So let's just start typing here component one. I think it's the name, yep, there's IntelliSense. Let's close that out. We save, let's go back to the browser. You can see that the browser already knows that the app has been changed. We just refresh and so we can hopefully see the changes on the homepage. Ah, there is our styled component that came from that component class library. So easy, so simple. So that gives us hopefully the basics. Let's now go build that weather app. I've already started it over here in this solution. If we go into the blazer folder I'm gonna set the blazer server version of this app as the startup project. There we go. Now this blazer app is a little bit interesting in that there's not much in it. Like it actually doesn't have hardly any razor files in the app project, like hardly at all. That's because it references this blazer weather core project down below, that's a razor class library that contains all the components that's used by the app. And I'll explain why we did that in just a bit. But you can look in here and see there's the forecast.razer page and there's all the razor syntax that renders the app. Let's go ahead and run this and see what the app looks like. This app borrows the same beautiful design that James used for the mobile application. There it is. So it looks pretty good. We got the current temperature. That's all working. Now let's look at the code and see how that is done. At the top of this page it's got a route just like before. It also is injecting an iWeather forecast service. That's the same GRPC based service that James used in his mobile app, same code. Like same line. How are we done that? All the code runs everywhere. Browser, mobile, desktop. Anywhere you want. And then we've got the razor markup that's just rendering out the DOM elements for the page. Down below in this code block, here's a component lifecycle event that fires when the component has rendered. And this is kicking off this get weather updates async process which is in this method down here. Here you see that async for each loop that we saw before. Same loop we've seen before. So it's getting the live updates from the server. We should be able to see that in the app. If I, let's zoom in here. So 43, 45, yeah. So the ticks are coming in from the server. Yeah, I can see it updating. All right, great. Now we're missing an ability to actually change the temperature units. Let's go ahead and fix that. I already wrote a little temperature unit picker component. It's another dot razor file in the class library. It's just a div, let's expand it again. It's just a div that has an on click handler that when it's clicked, it will toggle the units from Fahrenheit to Celsius. And then it has this parameter, temperature unit changed, so it can let the parent component know. So now we just need to use that. So let's go back to our weather forecast page. After the temperature, let's add the temperature unit picker. And we're going to at bind the temperature unit from that component to the temperature unit field in my page. And that's all we should need to do. I'm gonna control F5 again, not control F4. I don't even know what control F4 does. Maybe search or something. All right, there we go. So we're up and running. And now we've got this little widget down here by the temperature. I can click on it and you can see the temperature automatically updates between Celsius and Fahrenheit. Now that's a Blazor server version of the app, but one of the cool things about Blazor. I'm gonna stop you and say, we're gonna stop on the Blazor stuff. And we can quickly talk about the WebAssembly thing. So basically WebAssembly allows you to take these same applications and actually build them where all the code runs on the browser, not on the server. This is the same app, same components. It's just instead of running in a Blazor server app on the server, this is all executing. Client side in the browser, there's the WebAssembly file coming down with the app so you can host your app on the server or on the client and take advantage of both sides of the wire. Cool. I am super excited with this Blazor stuff. This is like, all my ASP.NET knowledge now let's be built by applications without using any JavaScript at all if I want. So super cool, Dan. Full stack web development with .NET. Okay, let's switch back to the slides real quick. We're talking about one more big thing, machine learning. We introduced ML.NET at build, that's May of this year, 1.0 that just shipped. And I'm just gonna quickly talk about it and we're gonna bring Bree up and show a couple of demos. The whole idea behind ML.NET is if you're a C-Sharp developer, you don't wanna have to go out and use some other technology or some other language to go and build machine learning into your applications. And so you can build ML models and stuff directly in C-Sharp or F-Sharp without having to go anywhere else. We also know that it's hard to actually build, you know, machine learning models. And so we have an awesome preview tool called Model Builder that you can use to actually just point at some of your data, tell it what you wanna predict and it'll actually go and write all the code and models for you. Bree's gonna show that. And then finally we wanna make sure that anything that we do in ML.NET, it can be extended with all the ML buzzwords you've heard like TensorFlow and stuff. So what I'm gonna do next is bring Bree up on stage and what we're gonna do is we're gonna build a, yeah, come on. We're gonna build a machine learning application that does weather as well. Yes, we are. So if we take a look, we still have Dan's Blazor app up on here, but what we're gonna do is actually make this app smarter using ML.NET. All it does is it right now is it pulls weather data from Glenn's microservice that's hosted in Azure Kubernetes. But we're gonna use machine learning to take images from around the city and actually predict if it's sunny, cloudy, or rainy. So it's gonna predict the weather. Because we all know that the weather's not always accurate. You're better off going and looking yourself to see if it's actually doing something. Right, exactly. So we'll close out of all these over here. All right, so if we go back to, let's see, the forecast.razor that we saw before. All right, so Dan talked a little bit about components which are just UI elements that you can have in your Blazor applications. And I created one of those for the machine learning. And I just called it ML weather cam. That's just gonna go right below the weather data that we saw before. And then what this does is it, if we look at this mlweathercam.razor right here, there's gonna be three buttons that are gonna link to three separate photos, which are then going to be put into this classify weather method. And if we go here. So I'm gonna go to the app. It's gonna show me a couple of pictures that we got from cams around the area. And then it's gonna tell us kind of what it thinks those cams are showing us, whether it's rainy or sunny or whatnot. Exactly, so here you can see there's nothing really implemented right now. We just have it returning a string. So if we go ahead and run this real quick, give it a second. And we'll see that new component added on there. It's just when you click on it. Oh, you know what? Actually, we're gonna try it on the server version instead because that's where it's implemented. So let's retry that. Dan caught you up there. Yeah, he really did. He really did. Let me try this again. So we're gonna rebuild our solution. And it will take just a second. Just I wanna show you that it's implemented without the machine learning. So we're gonna add that machine learning. Right, we'll start with that machine learning. Yeah, exactly. Run the application, we'll show the pictures. And then we'll run model builder to go and create the actual model for us. Right, exactly. And so we shouldn't have rebuilt the full solution, but give it a second. It's a big solution actually. It is, it's a big solution. Yeah, so one thing I should talk about is while we have the solution, we're actually gonna make this entire, all the demos we have today, I'll be available on GitHub later today. Right, exactly. Anybody that watched the keynote can actually do this themselves. Ah, I see pictures. And so here are the three pictures that I was talking about. Here's that new component. And of course it's just returning the same text every time. So to add machine learning, we're just gonna use model builder, which is a UI tool in Visual Studio. It's just an extension that you can download. Once you download that extension, you add machine learning. And there's a variety of scenarios here that you can see like sentiment analysis, price prediction, but we're gonna do image classification because we wanna predict the weather in images. So then we'll choose our training data, which is how you create the machine learning model. In this case, I've already put it in the format that it needs to be with three different labels here. And we can actually see once we choose that that I have my images here, a preview of my images for cloudy, rainy and sunny. So you gave it a bunch of images to learn from. Right. Right. And I'm gonna have it trained for about 90 seconds because it's a small data set. With larger data sets, you want it to train for a little bit longer. So this whole tool kind of makes me laugh. I remember a year or two ago, we were building a demo in the team it was called GitHub Classifier. And what GitHub Classifier did is it basically looked at the issues that were being filed in our GitHub repos and would automatically classify them to the right places. It's kind of a bot. I remember sitting with my team and I was looking at the code and I'm like, I don't know if I'd ever be able to write that code. And this is kind of the genesis of the model builder thing. I couldn't figure out how to write the code. And then the next thing was, I remember asking the team, well, how did you choose the algorithm? And the answer kind of was, well, we tried this one and it seemed to work. And to me, model builder is like taking that to the next step further where you basically, instead of doing that, give me a data file of existing data, run this tool on it. It will try, I think it's doing it right now, it's trying all the different algorithms we have in ML.NET and will write the code for me. So you're making ML where I can use the code. Right, yeah, so building and fine tuning the performance of a machine learning algorithm can be really difficult, especially if you don't have that machine learning knowledge. So what model builder does is use automated machine learning or AutoML for short to explore different algorithms and settings to give you the best model based on your scenario and your data. So it's really, really cool because you don't have to have that machine learning knowledge. And as well, you're showing the graphical version of this inside of Visual Studio, but if I am on a Mac or on a Linux machine, I can also drop to command line and run the same tool that you're running with inside of Visual Studio on all those platforms as well. Right, exactly. So if you don't use Visual Studio, you can actually use this ML.NET CLI in any command prompt, which is really nice. So it's done training. We're gonna head over to the evaluate screen. It actually found this one model here, which uses a ResNet neural network architecture for that image classification. And we'll move on here. And so what's really nice is once you have your trained model, you can add your projects. And if we zoom in here, give it a second. You can see that there's this console app here which is actually where the model training code is and you have your model consumption code and your actual serialized zip file, which is the model. So if we come back out here, and now if we go back to model builder, you can see it gave you the code for consumption right here. All you have to do is copy this code and go back to our weather classifier. We'll uncomment the namespace. Model builder actually adds the reference to the model for you and right here. So we've created our input. We're gonna set the file path here. To full path. And then we're going to actually load this into here and return result.prediction. And so actually we're gonna add the reference here because I think it was added to the wrong. Nope, it's there. Let's see what it's giving us here. Oh, here we go. So we've got our weather service and all dot model. Oh, what we have to do is actually, I think I called it on the wrong one. The wrong project? Yeah, the wrong project. It actually needs to be called on this project. So whichever project you add machine learning to, it'll add that reference to automatically, but since I did it on the wrong one, we're just gonna add the model here. Someone's gonna go away. Yeah, so then, sorry, it's a mouse I'm not really used to here. So we're gonna do input.image source equals full path. And then we'll be able to debug that. Awesome. All right, so now we can see that it detects this image. Ooh, I saw it say cloudy when you clicked that one. So we've got century link field is cloudy, Paramount Theater is looking a little bit rainy, and Golden Gardens Park is looking sunny. So in less than five minutes, we were able to use ML.net and Modabiller to add machine learning to this Blazor application, which is really, really cool. That's amazing. Let's go back to the slides and we'll talk about IoT. So IoT is kind of a new space in .net. .net core kind of enabled this by being able to run on different platforms and architectures. And so the big thing here is you can run .net core on all these small devices, Raspberry Pis, including all of .net. You can run ASP.net on these things. We have a GPIO library for reading and writing data to some cool hardware that Richard's gonna show us. And you can actually deploy these applications to IoT either directly on the device or using a container on the device. So let's switch over here and bring Rich on. And let's talk about IoT and .net. Hey, Scott. So this is more of a show and tell type of setup today. So we have a Raspberry Pi right here. So this is a Raspberry Pi 3, actually. And it's got this hat on it. Sometimes they're called shields, but this is a hat or a bonnet. And this is controlling this set of LED matrices. So actually there's four of them here. It's really hard to tell because I did such a good job making this setup, but there's actually four of these. And it's all C-sharp code that is running this from top to bottom. And so the libraries that we built actually are able to figure out the address translation to deal with the fact that there's four of these and they're kind of like in this setup. And so it's kind of cool. We've got a message here about DonutConf. That's kind of one row. Then we have this other one with a time. Then we built an analog clock. An analog clock. And you can see this isn't an image. This is actually a code-driven... I'm watching the second hand go around in real time. It's amazing. Yeah. So this is how you're staying on track, right? Yes. So this is actually kind of a canvas. And then it's actually raining in Seattle. This won't be much of a surprise to you. You're calling the same service that we showed everywhere else, right? Yeah, exactly. And so the Raspberry Pi. Exactly. And then so it's showing it's raining. So really what this is demonstrating is this device is like really low-powered compared to the Intel X64, blah, blah, blah machines that we've been used to. And it's showing that, yep, you can write C-Sharp, run it on here, and it's capable of doing a lot of things at once. That's the cool part about C-Sharp in .NET is you can actually run it on what? ARM32, ARM64, but if you want, you can also run it on the big Intel CPUs as well. Yeah, and it's all the same. The other thing is because it's all C-Sharp, it means that you can actually use the C-Sharp debugger that you're used to using. A lot of the other solutions out there depend on native libraries. And some of those are GPL, ours is MIT. So it's super attractive to people that work in this kind of ecosystem. Cool, I'm still super excited about this because we never could have done this five years ago. Oh yeah, totally, this is definitely new. So I'm really happy with it too. Awesome, let's go back to the slides real quick. And I want to talk about something really cool. .NET Core is all open source. And even though it's open source, we actually want to consume some of the open source libraries. So there's a couple of references you've heard today, like GRPC. GRPC is an open source project and we, Microsoft, have been contributing to that project. Our engineers are working on that project to make sure that the C-Sharp support there is first class. At the same time I mentioned earlier, Identity Server. Identity Server is an open source project that helps you add authentication to your APIs in .NET Core. We are actually contributing to Identity Server. We actually are helping fund them as a sponsor of their project, giving them money. GRPC, we're giving them code. Identity Server, we're giving them money via GitHub. And then also Swashbuckle, which is a common library for building Swagger for .NET Core projects. If you want to use any of our REST stuff, we can generate REST endpoints the same way we generated those GRPC endpoints. To do that, you have to have a library like Swashbuckle. And so I'm happy to announce that we're also helping fund them as well. .NET 5, so we just shipped .NET Core 3 and of course the team is super excited. We're working on .NET Core 3.1 right now, but I want to briefly talk about .NET 5 too. So after .NET Core 3, the next big thing is, we talked about Xamarin and we talked about .NET Core. What if we put all that together into a single framework? And so .NET 5 is the genesis of this. The next iteration of .NET will be .NET 5. And the idea here is all the runtimes collapse so we have one common set of runtimes. We have one BCL that sits on top of that and then we have all the app models on top of it. And so in the .NET 5 wave, there'll just be one .NET, not multiple .NETs. Let's talk about our schedule. So we just shipped .NET Core 3 today. .NET Core 3.1 is going to ship in late November, early December. That'll be our LTS. That's our one if you want long-term support. But we're gonna go way beyond that. We want to make .NET predictable. So you can see here now .NET 5 will ship next November. .NET 6 will ship to November afterwards. So on and so on and so on. Each of these .NETs every other year will be an LTS. So it's very clear which ones are long-term supported and which ones are faster, but we're trying to make it easier for you to consume .NET and understand the schedule. I do want to do one quick thing. I'm gonna grab my laptop, slide it over here. I thought I would do one demo of some of the tech that we have coming in .NET 5. And so Dan showed the Blazor app. Ali showed the desktop app. James showed the Xamarin app. And Bree showed the ML app. Well, we want to take this stuff even further. So we're gonna switch to my laptop here. Jump out of presenter mode, get my laptop back. And I want to show a preview of one of the things we're thinking about in .NET 5. So I'm gonna run that same Blazor app that Dan showed. But now what I've done is I've actually wrapped it in an electron shell. Electron is the technology we use to make things like Visual Studio Code run on the desktop. And so now you see that same exact weather application running, it's a Blazor application. So it's web, but it's now running in a desktop window. It's got file menus. I can do file and exit. This is one of the examples of the technology we'll bring in the .NET 5 wave. So I want to close with one thing here, which is we have an awesome unified platform. You can build every type of application on .NET Core. My advice to customers today with the shipping of .NET Core 3, if you're building new applications, build them on top of .NET Core 3. It now has all the capabilities that should be important for modern applications. If you have existing applications, you're likely should keep them on .NET Framework. There's no reason to move them off of .NET Framework. .NET Framework's gonna be supported forever. So new applications on .NET Core 3, leave your existing applications where they are. Everything that I'm showing here is downloadable today. And I want to thank you everybody very much. Go get the bits and build some new applications on .NET Core. Thank you very much.