 So I should have, there's the mic. Fantastic. All right. My name is Jeff Fritz. I'm a senior program manager for Microsoft on the .NET teams. I specifically work with our ASP.NET web development frameworks, and I wanna talk to you about three million requests per second. The new ASP.NET core on Linux. And it's kind of funny to have a Microsoft guy speaking at a Linux show. I hope you're not, you know, on the phone. Why the heck is there a Microsoft guy here at this event, right? I mean, we're actually doing things to embrace the Linux environment. And I wanna thank you for having us because this isn't something that we've stepped into lightly. We haven't started engaging Linux as some sort of a, some sort of a lark or a joke. This is something that we're very serious about. We wanna make sure that there's a very good experience for Linux users and developers with Microsoft tools. So one of the things that we've done to really break out from the typical Microsoft mold is we started our own foundation, a third-party foundation specific to managing our .NET resources. Those tools, those frameworks that we wanna make sure are available to everybody. And our open source partners, those projects that people are out there building and collaborating on that people use that aren't Microsoft built, right? These are things that people can add in to their .NET projects and receive a lot of, a lot of very good value, right? For what those folks are building out there. And of course, most people think that when we went to the Microsoft lawyers and started talking to them and saying, hey, this open source thing, we think it's a good idea for .NET. Their reaction wasn't this, okay? They actually thought this was a really good idea and they agreed with us. In fact, we started engaging the environment and we saw a 61% year over growth among .NET and we started integrating and making things open source. 40% of our .NET core downloads are new developers, brand new to the .NET ecosystem. And the community is very active in submitting pull requests to all of our .NET core projects out there on GitHub. More than 1800 packages on NuGet, that's our .NET package manager system, are all supporting our new .NET standard capabilities. We'll talk about .NET standard in a little bit. Folks from all over the world are engaged in working with the .NET core source. In fact, we took all the profile locations that people fill out in their GitHub profiles and we mapped them. And for 2016, we see that the entire world is covered with people who are engaged in working with .NET source. Whether that's submitting issues, pull requests, watching our repositories, getting engaged with us. And actually, the largest concentration of active users is right here in Europe. So we're really excited to see this amount of enthusiasm with our repositories and with our source code for .NET. In fact, our engagement for our source code on GitHub is so high that Microsoft tops the number of active open source contributors on GitHub. In fact, hell is frozen over. Microsoft is the top open source contributor on GitHub. And other folks say Microsoft is GitHub's biggest open source contributor. What a time to be alive. We're serious about this. We have teams of engineers in Seattle that are actively working every day on GitHub, building source code, and it's openly available for everybody to download, recompile, and use on whatever platform they're working on. And even the CEO of GitHub acknowledges that the shift to open source is now Microsoft's best friend. Very cool. So our foundation sponsors many, many different projects. And this is just a quick word cloud of a bunch of them. Different things like our compiler, our web frameworks, Mono, NuGet, our package manager, the Xamarin SDK, that allows you to build .NET applications that run on iOS and Android. Of course, you can also compile for PlayStation, Mac OS, Nintendo Wii. Very cool stuff. We've even got an open source CMS called Orchard available. But our foundation does things to help protect these open source projects, right? Folks like to come after open source projects around licensing and copyrights. We wanna make sure that those folks are protected. We wanna provide good practices for those folks. Mentor them so that they aren't out there violating codes of conduct and they're behaving properly inside of our community. Now, the foundation not only supports these projects, but we also have a technical steering group that helps to set the future for the .NET framework capabilities. And the members of our technical steering group include Red Hat, JetBrains, Unity, Samsung is on board with us and Google. These are companies that are out there actively working to make sure that .NET Core has a great experience everywhere. Whether it's Google Cloud, Microsoft's Cloud, or RHEL, you can use .NET Core and have a great experience. But we didn't just get into the Linux experience without talking to some folks first and deciding how much can we impact these folks? What can we do to help them do their jobs better? So I'm gonna show a quick video of some folks that we talked to about their Linux experience. My name is Alex and I live in Moscow. I live in Krona. I'm from Melbourne, Australia. And I'm from Houston, Texas. I live in Tokyo. I use Linux systems at home. I use Linux systems at work. I code and test in Linux. I use some of the test frameworks. I do a lot of work with Linux for my internal customers. I assist customers in ensuring that their Linux systems are up, accessible, and performing well. I think it's collaborating with the global community of people. Apparently, the community is greater than the sum of all its individual members. I'm doing all of this at Microsoft in the Azure Linux support team. I am working as a technical evangelist in Moscow. And I'm open source software specialist. So we have a lot of folks at Microsoft that are actually engaged in doing day-to-day Linux administration development. We really do love Linux. This guy, Satya, wasn't just making that up. We're doing a lot to really enhance our Linux journey. We've been through a lot for making our first contributions to the Linux kernel way back in July 2009 through supporting Linux on Azure. We released PowerShell, our enhanced shell for .NET capabilities. We released that open source, and we made it available for Linux at Ignite in 2015. We announced our partnership with Red Hat back in November 2015. And now today, we continue our growth with Linux. We've got some impressive numbers that are happening. PowerShell, open source, and available. Our container customers on Azure, all with Docker on Linux, four times growth. .NET Core available on Linux. We're going to talk and see demos on that. One in three VMs on Azure run Linux. In fact, it even came to a head in November when we joined the Linux Foundation as a platinum member. Folks in the media couldn't believe it. 15 years after Balmer called it a cancer, we joined the Foundation. This was on Hacker News, and it blew some people's minds. They couldn't believe it. And Red Hat really does love .NET. They started this website, Red Hat loves .NET. And you can go there and learn about just how easy it is to use .NET on RHEL and how Red Hat is a member of our .NET Foundation Steering Group. Very cool stuff. Full customer enterprise-grade support using .NET Core on RHEL. And Fedora, actually. So let me just talk a little bit about the structure of .NET. Because I'm sure you know, we had a .NET framework that ran just on Windows for a very long time. 15 years it's been running on Windows. And then our folks at Xamarin, they came along and they started building Mono based on our specifications. And now you can use that to build mobile applications. Well, we came along and we wanted to build this .NET Core framework that kind of meets in the middle where we want to be able to offer cross-platform services that are available across the board with a .NET standard library, one base class library that works with all three different frameworks. And a rich set of tools that you can use, including Visual Studio, both for Mac and Windows. Visual Studio Code, a great text editor that we're going to use in a little bit here, that allows us to get the rich productivity features inside of Linux, Mac, and Windows operating systems. And we've got a common infrastructure of compilers, languages, and runtime components that are all open source and available to just work everywhere with every framework. So I'm gonna focus today on the .NET Core cross-platform services, okay? They are cross-platform very fast. We have benchmarks that are published out there by a third party that show we are eight times faster than Node.js, three times faster than Go. And it's very lightweight. No impact deployment, modular development model, which means you don't need to have a machine pre-built with a .NET framework running on it. We can actually package up just the components you need to run .NET and deploy them wherever you need them. And of course, everything is open source. All of the source code for this is available on GitHub. If you go to github.com slash .NET, that's D-O-T-N-E-T, or github.com slash ASP.NET, you'll be able to see all of our source code for .NET Core and ASP.NET Core, our web framework. So I mentioned that there's a third party that's been out there validating web frameworks. They're called Tech Empower. And we took some of their benchmarks and we started running them in our lab. And we came up with these numbers running Node.js. And this is in millions of requests per second. So we had Node.js coming in at 600,000 requests per second. Go at 1.8, grisly at 2.8, and ASP.NET Core on Windows with some extra tunings that we had put in there came in at 5.2 million requests per second. Even higher than the 3 million, we initially thought we were gonna be able to pull. But this was in our lab. This wasn't Tech Empower's official review. In November, they published their results. And this is what they said. ASP.NET Core is now a top performer in their plain text test. So this is a test just to return text from a web server. A real test of the web server's performance, not so much the framework. So our web server went to 1.82 million requests per second in their tests. That's in the top 10 behind these other benchmarks, these other frameworks that are available for you to check out out there if you look at Tech Empower's website, okay? This is not a Microsoft test. This is a third party that's out there reviewing and inspecting frameworks. So that's pretty cool. We're excited about that because we really have doubled down on performance investment inside of our web frameworks and our .NET Core framework. And our community is actively engaged. This isn't something that we're saying, well, we're open source, but we're not actually taking pull requests. We're actively seeing folks engage and build things with our frameworks and contribute to our frameworks. This is Ben Adams, and he tweeted over the holiday, what do you do to unwind after a hard day at work? Well, he went out to the ASP.NET Core web source code and he vectorized the headers that our web server transmits. Well, what does that mean? That means that when you look at the benchmarks, he improved the performance of the web server by double to three and a half times. This is just something that a contributor put together and pushed out with these benchmarks. So on Ben's machine, he was seeing these header values compressed and transferred requests per second, went from, let's take a look at the Mozilla benchmarks, went from 8.6 million requests per second to 27 million requests per second. More than a triple increase in performance. That's huge, and this is not a Microsoft engineer. This is someone who's out in the community helping improve our product. That's great, right? That's the spirit of open source, community in a rising tide lifts all boats. So our community is active out there. What can you do if you wanna build with .NET Core? Well, right now we support two different types of workloads. You can build either a web application or a console application. Of course, if you have a console application, you can set that up to run as a server process and then you can deploy your web or console application either in a shared deployment model or self-contained. Shared being there's already a .NET Core framework installed and shared on the machine or self-contained. You're gonna package up all the references for your project and deploy that into one folder that'll be used by just your application. And of course, we have different isolation models. You can deploy bare metal or you can deploy on containers and we support Docker containers. We also support OpenShift containers. It's up to you. This is all about choice. We don't wanna force you to use something that you're not comfortable with. So let's take a look at some demos and let me get into .NET Core with Linux. All right, excuse me while I sit on my microphone wire. So I have Fedora running here in a VM. Come on. Now, when you install the .NET framework, let me actually go back and show you the install process. Let's open a brand new browser tab here. You can go to .NET. That's kind of convenient, but also sounds a little redundant, .NET. But you can go to .NET and you can download and install this very easily. So download and I'll choose .NET Core. And I've got either long-term support releases or the fast track current releases that are released a little bit more frequently, about once every two or three months. So I can choose to install with Linux and then it'll actually let me choose from a couple of different distros here. And you can see we have a very simple YUM install after you set up the .NET repository. And we also have for Fedora instructions so that you can bring down the .NET framework and get that installed as well. Very easy to do. Simple instructions to start this up and get your .NET command line tools running. That's important to us that we built everything on the command line. We've taken this approach of command line first so that whatever editor you're using, they all have the same APIs to get into and use the .NET compiler, the .NET package manager. Everybody has the same level of access. There isn't anything special that we've made available for Visual Studio that you can't use if you're a developer who prefers Sublime or Brackets or even Vi, right? Who likes Vi? Emacs. We support both with a great add-in called OmniSharp. Check this out. So those IntelliSense features that we often have, well that you've probably seen inside of Visual Studio, we offer OmniSharp that allows you to add on to those editors that same IntelliSense capabilities. Now, my father's a long time Unix administrator since way back in the 80s. And when I showed him that you can get IntelliSense in Vi, it was like, are you kidding? This is ridiculous, right? This isn't something that he was expecting. But we do support this and it's easy to add in. There's instructions for each one of these that you can click into and add to your favorite editor. So I have the .NET command line tool here. You can see I'm running version 1.1. Yes, there's a question in the front. Is OmniSharp implemented on top of the language server protocol? I believe it is. We've done a lot of work to make sure that OmniSharp is pretty standard and can plug into all the different editors. So this is the .NET command line. There's a bunch of different commands that you can pass into this to start running your application or building an application. I'm gonna go down into a dev environment here, a dev folder. I'm going to make a folder and let's go into that. And I could start a new application very easily with the .NET new command. Let me increase the font size there a little so it's easier to see. So if I issue a .NET new command, it's gonna just template out a very simple basic .NET application for me where I really only got two files. Project JSON that contains all the metadata about what I need to build my application and then an initial C-Sharp file that has really just a simple hello world demo. My Project JSON file, it contains this information about what's necessary to run my application. I'm debugging with a portable mode here. It's just the pieces inside of my application that I want to be able to debug. I'm referencing the .NET Core platform version 1.1 and that's it. This import statement here is telling the .NET compiler, if you see things that have this older name for our framework, DNX Core 50, you can treat those as compatible with this version of .NET Core. So, come on. There we go. So, I've got my little application sitting here. Let's actually restore the packages necessary to run this. Very quickly, it creates this Project Lock JSON file. Now that's a file that's machine readable that just defines here's where these packages are on disk that you can reference to build your project. And then I can build by either saying .NET build and it'll actually go and compile or I can execute .NET run directly. And if it's not built, it'll build it first and then execute the application. And there's hello world. Simple, right? I mean, who cares? It's hello world. Show me something that's actually a little bit more interesting. So let's do that. Clean up this folder. I can create a web project by specifying .NET new dash T. Give me a different template and I'm gonna ask for the web template. And I now have files necessary to build a web application using the ASP.NET Core web framework inside of this folder. Now, who's familiar with using ASP.NET MVC, our older web framework that we built for Windows? Okay, a number of you. So this is using that same ASP.NET MVC approach where we have a folder of controllers. Those are C-sharp files that instruct how to interact with the C-sharp code. A folder of views that have templates, formatting that can be applied using our razor templating language. And we have some other files here that help to bootstrap and load the application. So I will run .NET restore on this project. And it'll take a second here to go and remap everything inside of project JSON and reconcile all of the packages appropriately for this project. And if I've got a good net connection here, it should come back very quickly or not. There we go. So what it does when you say .NET restore is it actually reaches out to newget.org and it takes a look at the packages that are available there and it looks at the packages on disk and it grabs the appropriate versions if you don't already have them on disk. So my restore is completed. I can say .NET, let me, let's do this. Let me set an environment variable here. Okay. And I can now execute .NET run and it'll think that I'm in the development environment and now my web server is running and listening on localhost 5000. So let me open Firefox. Right, we like Firefox. Chrome. Okay, Chrome. All right. Edge. Did somebody say edge? Edge is okay. I.e., okay. So there's my templated web application, okay. This is using the Bootstrap CSS framework by default along with some jQuery to give me a simple application that contains some information about where to get more information if you're interested in using ASP.NET Core to build your application. So this isn't bad. I can click through and I can see an about page. I've got a contact page that contains basic information. So it looks like it's behaving well and responding properly to me. But if I wanna get in here and start editing with it, let me roll back over to my console. You can see by default it logs all this information to the console about every request that comes in. You can control those logging levels inside of our configuration files. It's actually inside of app settings JSON. So by default, we're logging debug level information and for anything that's in the system or Microsoft categories, we're logging all the information log level to the console for you. So that's nice. Let me show you what that project JSON looks like. When we start talking about a web application, there's a lot more that we need to bring in package-wise in order to get the application up and running. And there's a lot going on here. We've got authentication with cookies that have been configured. We have our data framework called entity framework core that's being brought in with identity information for that. So this is to allow us to do authentication and authorization and store all of our authentication information inside of a database that's managed by our ORM entity framework core framework. That's kind of repetitive. Our MVC web framework. And by default, we bring in our IIS integration. But I don't have the Microsoft IIS internet information server running on Linux. This package is actually intelligent in that it'll see what operating system it's running on. And if it's not on Windows, it just does a no-op. It just bails out silently and fails. We support SQLite with entity framework core. And if I scroll down here, you can see we also bring in all of our logging frameworks. We bring in something called browser link that helps you do some very fast debugging and automation from your editor. And then a bunch of tools to help build our application. This is what you might see in dev dependencies in a npm package.json file. There's our frameworks again, defining that we're running on the net core app framework. Some information about how we build and then how we're gonna publish our application. What are the things when we actually want this running out on a production web server that we need to package up and ship with that? So everything in our www root folder, right? Those are all the static files that we don't want the web server to actually interpret and compile. So a couple of other files there and then some scripts for pre-publishing and post-publishing. You can see we hook directly in to calls to npm and bower and gulp, right? And folks have asked us, well, you're Microsoft, why don't you have your own JavaScript framework? Why? There's such great frameworks out there and tools from the Node.js community to build and manage all of these awesome JavaScript frameworks and bower, right? The Twitter folks that built bower, it's a nice tool to manage some of those client-side frameworks, whether it's CSS or JavaScript. And the Gulp team, they've done a great job with building their task runners. So let's make that available and be able to call that directly from our templated applications. We shouldn't invent everything because we know there's great things out there that we can integrate with and enable so that you can be comfortable using your favorite tools with our framework. So there's a lot going on inside of this ASP.NET application and I'm a text editor guy. I look at this and okay, I could use VI and navigate around here and I'm comfortable with that. But when I've got multiple concerns that I need to manage back and forth between these files, it's a little much for me. So I like to use Visual Studio Code. You like that? That was a nice segue. So here's Visual Studio Code. This is built on top of the, yes, that's fine. This is built on top of the electron shell framework that the folks at GitHub have been building. So this is all HTML, TypeScript, JavaScript to present an editor that we think is pretty nice. It doesn't just work with .NET. There's a rich extensibility model here that you can go and search for your favorite languages and tools and we support them inside of Visual Studio Code. So there's Python interpreters out here. This network connection is gonna bite me, isn't it? There's tools for C-sharp, of course. There's tools for F-sharp. There's an integrated git shell that you can take a look and work with. This is gonna run really slow for me, isn't it? I'm plugged into the wire. All right, who's running a BitTorrent server out there? Come on, fess up. I could cheat and I'm going to do that. I'm gonna tether just so I can get a little bit more performance out of this. Hey, maybe I can use Vikram's iPhone 6. That'd be nice. I just turned mine on. There it is. Because if I can't get to the net very quickly, we're gonna have some lame demos. There we go. So there's Python for VS Code, some Python extensions. A lot of folks like to use Angular. So we've got all kinds of Angular capabilities that folks have built in to access the Angular CLI and other snippets and things so you can get some cool tooling around Angular. It's a very rich marketplace and ecosystem that folks have built out there around Visual Studio Code. And Visual Studio Code is actually open source and available on GitHub. This is the source code for Visual Studio Code. If you wanna recompile and run this on some different platform, you wanna run it on your PlayStation, I don't know, maybe people wanna do that. But it's possible. Everything is here with instructions for how to recompile it and get it running. Instructions for how to contribute and give feedback. I mean, Microsoft has open sourced a Visual Studio product. That's pretty unique. You wouldn't have heard us do that 10 years ago. We have easy instructions for how to install this, whether it's Windows, Linux, or Mac, okay? Including RPM packages. That took me back to the day, installing RPM packages again. Let me tell you. So, very cool stuff. Let me go back and show you a little bit about what I can do with Visual Studio Code now. So if I take a look at my controllers here, I've got these C-sharp files. If I go into my home controller, this is normal C-sharp, and I've got syntax highlighting coming through for me here. And it's not just text lookup and type ahead. This is real intelligence that we have here where it actually knows that things are what they say they are. So if I declare this as a var, and then I do a dot here, Visual Studio Code knows this is an integer and gives me integer-like things that I can do with it. Similarly, if I make that text, it still knows that this is text, and it gives me text-like things that I can do with it. So full intelligence, it's really out there actually recompiling your code and giving you suggestions and a little bit of documentation that you can actually click into and see more about directly in the editor. So if you're not an all-star elite developer who can do everything in the text editor and knows all the cases and all the programming model by heart, and you need a little bit of help, this is very handy. It helps to make people a little bit more productive who don't know all the APIs by heart. So we think that that is a very cool thing for folks to be able to use. With Visual Studio Code. And of course, I can do things in here like set breakpoints and I can kick off a debugger and launch my application inside of, I'm sorry, inside of Visual Studio Code and run my Firefox browser attached to it and stop exactly where the things are occurring inside of my application. So it's compiling, launching Firefox and it's gonna come up and show me that home page if I click through to the about page where I set breakpoint, it stops right there. I can see all the local variables right here, all the information about what's going on in this exact request and I can drill down into them. It's a full debugger that's sitting here that you can interact with, right? I can take a look at that HTTP context. What exactly happened in exchange with my browser? I can look at the request information, okay? Very cool, easy stuff to use that we've made available for those folks that are developing on Linux, Mac and on Windows if you don't wanna get the full Visual Studio. So I'm at a breakpoint, I can continue at this point. And it'll finish. I can go back over to Firefox and it finished and shows me the results of my browser, okay? So it's a full IDE experience that's masquerading as a text editor but it gives you all of these cool capabilities to work with your favorite languages, our frameworks that we think is very convenient for folks to use. So let me go back to the slides here. I wanna finish up and give you guys a chance to ask some questions. Come on, there we go. So I talked about this thing called the .NET Standard Library. When these other frameworks, the .NET framework, .NET Core and Xamarin, when they were built, they were built by three different, three very different groups of people that weren't really talking to each other. They were building off of what were perceived as standards and folks implemented things in different ways. Consequently, we had base class libraries, those foundational things that you need to reference and use, things like IO access, network access, right? Data access to your favorite database. Those were implemented differently and had different quirks, different features that lit up or didn't work appropriately on these different frameworks. So we've set forth to build a standard library, a standard reference that you can learn and target all three, whether it's a Windows framework, an iOS or Android framework, or the cross-platform .NET Core framework with one set of APIs and it just works when you deploy to each one of those environments. And when you build for one of those environments, you have these choices for UI frameworks. On Windows, you can use WPF, Windows Forms, or ASP.NET, our full .NET framework that we've been using on the web for the past 15 years. iOS, OSX, or is it macOS now? I think it's macOS now, right? Okay, macOS and Android with Xamarin. And then .NET Core, our UWP, our Windows Store apps, actually compiles to .NET Core when you submit them into the store. But of course, ASP.NET Core web applications were headless console applications you can build with .NET Core and we'll get those three core base-class libraries unified in this .NET standard library. We call it the one library to rule them all. So this means that you can learn one API when you start programming towards our .NET standard library. Reuse your code across .NET platforms. And this is something that we've tried to do in the past with things like Silverlight. And you know what? We kind of missed a little bit there with Silverlight. So we've backed off, we've reevaluated, and we think that this is a much better approach. Because we have all these different flavors of .NET frameworks, we've set a, we call it the Russian doll model around our .NET standard versions. So we have between versions 1.0 to 1.6 that specify different levels of compatibility and API levels that work between the different .NET frameworks. So when you have .NET standard 1.0, it has a very small API surface, but it's compatible across everything. Whether it's Windows phone, whether it's Xamarin or .NET Core, it'll work on all of those frameworks. But if you go to 1.6, the highest .NET standard library we have available today, it has a very wide API, covers a lot of different things, but it only works right now on .NET framework on Windows and .NET Core cross-platform. So we started working on something that we call .NET standard 2.0. We're gonna be releasing this in the spring. This has a much larger API surface. So it'll extend and cover all the capabilities that are in Xamarin frameworks, .NET framework and .NET Core, and our new .NET Core framework that we're going to release in the spring will support all of these new APIs. And I've got a slide to show you some of the APIs in just a second. But the big thing that we're doing as part of this, and this might make some of you folks happy, is we're introducing some interop with our existing .NET framework libraries. So folks that have built stuff with .NET Core going back into 2005, 2006, that run on .NET framework 2.0, way back and only works on Windows, binaries that are sitting out there that nobody's touched, maybe you don't have the source code for anymore. You're gonna be able to repackage those with a .NET standard shim and deploy those with no recompile, no changes to that existing binary, be able to deploy those to a Linux box and they will just work with your .NET Core applications. So Windows DLLs deploy to Linux and they work just fine, just the same way. That's pretty cool. That's a big shift for us to bring that feature over to Linux. So some of these APIs that we're bringing, we're gonna bring some things around our core primitives, collections, reflection capabilities, link. You guys use link, you know what link is? Okay, cool. It's a natural query language that's embedded inside of our .NET language. We've got some great IO capabilities, networking. Folks have complained that we didn't include a mail API. We're gonna bring that into our next version of .NET standard and XML capabilities because everybody loves angle brackets. See, they're angle brackets or curly braces with JSON but we know a lot of folks like to use XML so we're gonna bring all of our XML APIs over to our .NET standard and .NET Core frameworks. So right now, if you build with our tools that are available out there on GitHub and .NET, you can build a .NET standard library that contains all your business logic and interactions that you might need with different services and reference other .NET standard libraries or what we used to call portable class libraries. In that .NET standard library, we'll work with .NET framework, .NET Core and Xamarin. When we finish .NET standard two, you'll be able to build your library and also reference those older .NET framework libraries. Consequently, you end up with this model with the .NET frameworks where whatever application you're building will be able to reference a standard library that references all kinds of other class libraries. We think this is a tremendous change that we're making to enable more developers to interact with our frameworks and be productive. Our .NET frameworks support all kinds of operating systems, whether it's the different versions of Windows, the different versions of Mac OS and all kinds of Linux distributions, REL, Fedora, Debian, Ubuntu, even Tizen. Anybody programming for Tizen? Tizen's Samsung's distribution that they use on their devices. So they have watches and phones that run their Tizen operating system. And also, they're gonna be making this available with .NET Core on their big screen TVs. So when you have a smart TV that has the apps that run on it, you're gonna be able to use .NET to program for that environment starting this year. Finally, I just wanna show you our roadmap. Right now, we have a fully supported RTM runtime that includes the .NET Core SDK with a tools preview. We're doing more to enhance those things. You saw a little bit with how Visual Studio Code is working. Our next, our version that we released just about a month ago, 1.1 includes support for some better tooling, better command line interface. And this spring, that .NET standard 2.0 version is coming out. We have enhancements to C-Sharp called C-Sharp 7 and some other features that are gonna be coming out, including more availability on other Linux distros. That's it for me. I've got some time for questions. Thank you so much for coming out. I really appreciate it. Any questions? I went through a lot. Yes, sir. So to repeat the question, the question is how much sense, what kind of an experience do we have if we build with Visual Studio on your Windows machine and then deploy to a Red Hat Linux environment? It makes a lot of sense. We've done some great things with our publishing experience so that you can bundle up the output from Visual Studio, send it over to your favorite Linux distro, and it just works. This afternoon, we have a session that I'm co-presenting with some of the folks from Red Hat where we're actually gonna go through and show that demo so that folks can collaborate on their source code whether they're using Mac, Windows, or Linux, collaborate and then deploy from whatever one of those operating systems to their favorite deployment server, whether it's Windows or a Linux server. So, very good question. And we've got a great demo later. Yes, in the back. So the question is, we're hearing this as the message for the Linux developers to get involved and start using .NET Core. What's the message for the Windows developers? You know what? We're supporting the Windows developers with the same features, the same capabilities. They have great services available to them inside of Visual Studio 2015. We've got even better services available to them in Visual Studio 2017 as we finish off that version of our the premiere IDE editor. But we're also continuing to deliver great project models that folks can use .NET for if they wanna build Windows applications and continue to use those shared libraries, that .NET standard library that they build, they can use that with their UWP, their Windows 10 applications, or Windows Forms applications, and they'll be able to get that great compatibility with an iOS application or a Linux application that they're gonna be deploying. I had a customer actually ask me last week, hey, I've got this old Windows Forms application that some folks in my organization built 10 years ago and we still have the source code for, but I wanna migrate it and get it running on an iPad. How do I do that with .NET standard? And they have to go through a refactoring process where they can put their base capabilities into a shared library. And then they can reference that using .NET standard, the .NET standard frameworks inside of .NET Core and deploy to Xamarin or to a Linux machine. Very cool stuff. Does that answer your question? Cool. Yes, in the back here. Very good question. The question is, how was the runtime developed? Is the runtime a shared code base or is it separate for Linux and Windows? The runtime itself is separate. There are separate runtimes for the different environments. And in our demo later today, we'll talk about and we'll show you the different runtimes, how we can recompile for the different runtimes which is included and delivered with the framework. So we have a runtime that the framework sits on top of and that runtime we're actually collaborating with Red Hat engineers to make sure it runs great on RHEL or Fedora. We have some other folks in the community helping us with Debian and Ubuntu. And we have some Microsoft engineers who have experience with that that are chipping in and helping as well. So, and Samsung folks that are helping with the Tizen experience. Does that answer your question? Okay, I have one last question I can take. Yes? Yeah, so starting new project to use to start using ASP.NET Core or it's better to wait for next version because like for real enterprise solutions. So the question is, should folks start using ASP.NET Core today for an enterprise solution or should they wait for that next version that's coming out? I would be doing my engineers a disservice if I didn't tell you that they're gonna have a great upgrade experience between the current version and the next version of ASP.NET Core that's coming out later this spring. They're really working hard and that's one of their exit criteria to deploy that new version. So I would suggest if you are going to build new enterprise applications, give it a try, get started today with .NET Core, with ASP.NET Core and you should be able as that new version comes out, you should be able to migrate very easily and have a great experience no matter what editor you're using, no matter what runtime or framework you're deciding to use. And how many nugget packages do? So the question is, how many new get packages are out there for .NET Core today? We have more than 2000 out that are compatible with .NET Core today and it just continues to grow. There's more than 40,000 packages out on newget.org and they're adding more and more compatibility to those projects as folks get in and get more comfortable with .NET Core. And as we add more APIs, that number's just gonna grow. That's all the time I have. Thank you so much. I really appreciate you guys coming out to see me. Like I said, this is my first presentation outside the States at a conference. I really appreciate your patience and your, gosh, cooperation. Thank you so much. I'll be outside if you wanna talk further.