 I think most people will be here. Welcome to this presentation about getting started with .NET Core on Linux. I will show you a lot of things. But if you're familiar with some programming language or some IDE, it should be easy to follow. A little bit about myself. I work at Red Hat in the .NET Core team. In our team, we package .NET Core for Red Hat Enterprise and OpenShift Container Platform. And we support our customers with .NET Core issues. I'm also a member of Fedora's .NET Special Interest Group. In that group, we also package .NET Core for Fedora and discuss .NET related stuff. So if you're a Fedora user and you're interested in .NET, you can join our group. I'm a .NET Core contributor. So I contribute to the upstream sources, mainly working on Linux issues. And I maintain a number of .NET libraries with the Linux focus. So one is for working with debus. And the other one is for interacting with system D. Before we talk about .NET Core, let's put it in perspective. So what is .NET? .NET is a development platform with a number of programming languages. And those programming languages are compiled to something called intermediate language. And intermediate language is like Java bytecode. It's a type of assembly language, but not specific for a machine architecture. So then when applications are executed on your machine, this intermediate language will be compiled by a just-in-time compiler to the machine-specific instruction set. So this is the typical team you see in .NET. A number of programming languages compile to intermediate languages, intermediate language, which gets just-in-time compiled by the runtime when you execute your application. So that's .NET. There are a number of .NET implementations. The oldest implementation is .NET framework, which is the implementation we had since 2002 and which only worked on Windows. .NET Core is the implementation that Microsoft open-sourced in 2015, which works cross-platform. So also on Linux Mac and other operating systems. And that one is meant for building web applications, IoT applications, and console applications. Another .NET implementation is Xamarin, which is an implementation that builds on top of Mono and is meant for building mobile applications like iOS and Android applications. Now, of course, with these different .NET implementations, it would be nice if we could write code, compile it, and then run it on these different implementations, the same code. And to do that, you need two things. One is this intermediate language, which is supported by the different .NET implementations. And the other thing you need is a common set of APIs. And this common set of APIs is what .NET standard brings. So, .NET standard is basically a version set of APIs. And in the columns of these slides, you see the successive versions. And each version adds more APIs. And then you have the platforms, which are the rows on the slide. And when a platform implements all of those APIs mandated by a certain version of .NET standard, then it's compatible with that version of .NET standard. So, what does that mean? That means when I write the library, and for my library, I target .NET standard 2.0. That API set, my library will work on the platforms which implement that, which is .NET core 2.0 and higher, and .NET framework 4.6.1 and higher, and the other platforms listed in this table. Let's talk a bit about .NET core versions. So, when you develop your application, you need to pick a version. And there are two release trains you can pick from. One is the LTS release train, the long-term support release train. And these versions are supported for up to three years or even longer. So, at least three years. And when a new LTS release comes out, another year after that new LTS release. So, when a new LTS release comes out, you have one year to migrate to that new LTS release. Then you have the other train, which is the current releases. This is where you get the latest and greatest of .NET. But when a new release comes out, a current release or an LTS release, then you need to migrate to that new release within three months, otherwise you're no longer receiving security fixes. We, since 2015, we've seen about one to two of these releases per year. A little something about the version numbering. So, when you have a .NET core version that consists of two parts. One is the SDK, that's the software development kit. These are the tools you use to develop the application like the compiler is in there. And the other is the runtime, which is what you use to execute your application. This is what your application is using in production. And both of them will have the same major and minor number as the .NET core version. So, suppose I'm using the latest LTS release, which is 2.1, then I'm probably using the latest SDK, which would be 2.1 503, and the latest runtime, which would be 217. So, the SDK and the runtime have an independent patch number. Some things work across those .NET core version boundaries. One thing I want to mention in particular is that SDKs and the runtimes can be installed side by side, so you can install multiple versions at the same time, and you can use those independently. To install .NET core, if you're on Fedora, then you go to fedora-loss.net, and there you find installation instructions. If you're using a Retat Enterprise Linux or CentOS, you can find your installation instructions in the health documentation, and for all the flavors of Linux, Microsoft provides installation instructions at their .NET slash download website. Visualstudio.code, you can go to code.visualstudio.com and download it there, and to do .NET development in Visual Studio Code, you need to install the C-sharp extension. I'll show that in a minute. So, enough talk. Let me show you some stuff. So, on my system, I follow the instructions from fedora-loss.net, and I have the .NET executable available, and I just run that. It gives me some options, like let me make this a little bigger. Like, I can do .NET info, and then I get some information, like you're using the 22100 SDK. You're running on Fedora 29. The SDK you're using is at this location. I actually have two SDKs installed, a 2.1 and a 2.2 SDK, so one for the current and one for the LTS release, and also the matching runtimes for 2.1 and 2.2 are installed on my system. Another option you have is to invoke .NET help, and when you do that, you get a list of commands that the SDK supports. So, for example, one of these commands is .NET new, which you can use to create a new projector file. If you want to have some more info about one of these commands, you just type .NET, the name of the command, and help, and then you get some more info. So, for example, for the .NET new command, I can specify some options, like I can specify the output folder for my project, I can specify the language, because some of the templates are available in multiple programming languages, and then I specify the name of the template. I'd like to have, and as you can see, there are templates here for building console applications, for building class libraries, test projects, and also a bunch of templates for building web applications. Now, let me create a folder here and launch Visual Studio Code. So, I typed code and a dot for the current working directory and Visual Studio Code opened up. So, to add .NET support to Visual Studio Code, you go to the extension tab here on the left. You search for C-Sharp, and then you simply install the C-Sharp extension with the install button you'll get here. You reload your ID and your goods to go. So, let me open a terminal here in Visual Studio Code, and invoke the .NET new command. I want to have a new console application, and I'd like that in a folder named console. So, you see my console project is generated here, and I get two files. One file is the .cs file, this is the C-Sharp code for my program, which contains a main method that simply calls Hello World. The other file is the C-Sproch file, this describes my .NET project. So, my project is using the Microsoft.NET SDK, and I'm building an executable, and I'm targeting .NET Core 2.2. So, that's what those fields mean. Let me close this. Voila. Now, I will move to the console folder, and I'll do .NET run. So, when I invoke .NET run, two things will happen. The first thing that happens is my application is compiled, that's because .NET languages are compiled languages, and the second thing is my application is executed, and we see Hello World pop up here. I can do the compile step separately, and then we get some more information. So, here we see the assembly file that was generated, and that contains our compiled code. I can also do the execution step separately. You do that by doing .NET and specifying the assembly file, and my application runs without it being built in this case. This is how you should execute your applications in production. Don't use .NET run. .NET run is an SDK command. It's meant for being used when you're building your application. In production, you only want to be using the runtime, and not the SDK, so you should execute your applications by just specifying the assembly file, and providing that to the .NET executable. So, let's look at using Visual Studio Code. You might have seen that I get a rich experience already that's thanks to the C-Sharp extension, like I get some information about this write line method. And while I'm typing, you see all sorts of things happening that's because the ID is aware of the programming language, and you get a rich and intelligence experience. Let me refactor this, voila. We've made an edit here. I do .NET run again. Again, my application is compiled, and we see our change show up here. So, that's a basic edit experience in Visual Studio Code. Now, let me also show you the debugger. I'll place a breakpoint here, voila. And I'll move to the debug tab here on the left. So, at the top, you find the drop-down box, and here you can create debug configurations. We'll add a configuration for .NET Core, and we get some defaults here, and as part of the defaults, the plugin has already found the assembly file. We are compiling, so we want to be using that. You can change these, like specify some arguments, the working directory. You can also add environment variables, typical things you know from a debug configuration. So, we have a debug configuration. We're ready to go and launch our application and attach the debugger, and voila, we hit our breakpoint, and you get the typical things you know from an IDE debugger. You get the ability to step in over, out. You get your local's windows, your watches, your call stack, and here at the bottom, you get control on which types of exceptions you want the debugger to break. So, that was a basic demo of debugging .NET Core application in Visual Studio Code. I'll remove my console application. I'll replace it with a more interesting application. So, this application I've written here up front. What it does is it gets me a list of users as an array. I iterate over the list of users, and I print out their name. To get that list of users, I'm using this fake JSON API, and I'm using here .NET Core's HTTP client class. I'm doing a GET request for the URL. I get the string. I parse it, I parse the JSON, and then I go and iterate over the JSON and turn it into strongly typed instances of this user class. So, a basic example. You might have noticed that I get some red squiggly lines here. That's because the project does not know how to use this JSON parsing API. That's because what I'm using here is a library called Newtonsoft.json, which is a popular library for working with JSON in .NET, which is not part of .NET framework. Like with other platforms, you get a lot of basic functionality as part of the platform, but at some point, what you want is not there, and then you go and find a third-party library that gives you that functionality. So, for .NET, the third-party libraries are hosted on a website called nuget.org, so you can go there. Nuget refers to the packaging mechanism that I used by .NET. And if I search here for JSON, I get a number of suggestions, and I'm using this very popular Newtonsoft.json library for parsing the JSON. So, I get a version list here with the version of the package. The website even gives me a command. I can copy and paste, and this will add that package to my project, and now you see the red lines are gone. Adding it to my project means the package got fetched from nuget.org and use is now used in my project. It is also added to this project file here, which means that when other people are now working with me on this application, they will also go and fetch this dependency. When I do .NET run again, you see the application works. We get the JSON, we parse it, and we print out the names with the console. So, now we have this great application and we want to share it with the world. So, how do we do that? We do that by publishing our applications. To do that, we do .NET publish, and this will generate a folder. If we have a look in the folder, there are not many files in there. We see our compiled assembly file, which contains our application code, and also the newtonsoft.json dependency is added here. .NET Core is not in this folder, and this is what is called a framework-dependent application. That means when we give this folder to a user, he will have to install .NET Core on his machine. It depends on the user having the framework. When he has .NET Core installed, he can simply invoke the application by specifying the assembly name, and then it will run on his machine. Another way of publishing an application is by including .NET Core with the application, then the user no longer has to take care of that. That is called self-contained deployment. And to do that, you again use the .NET Publish command, but you need to specify what target platform the user has because an executable .NET Core for Windows is not the same as .NET Core for Linux. So for example, if I publish for Windows X64, I get a folder. When we look in this folder, there are a lot more files in here. That's because .NET Core is included. And one of the files that got generated is native executable for Windows. So when I give this folder to a Windows user, you can simply double click it and the application will run on his Windows machine. Of course, I can do the same thing for Linux. Now I specify Linux X64 as the runtime identifier. And here again, I get a folder that contains .NET Core. And also in this folder, there is a native Linux application which a user can simply invoke. So that's the end of the things I wanted to demonstrate to you. So I've shown you really a lot of different things. We've had a look at the .NET CLI. Then we created a console project and I showed you how you can build and run that project. Then we did a small thing, making edits in Visual Studio Code and also launching the debugger. And then finally, I showed you how you can use third-party libraries that you can get from lookit.org and how you can publish your application in a way that older users can use that, either framework dependent or self-contained. The next slide is a small sheet I made. This has the commands I've used during the demo. I think the slides will be published on the DevCon website. So you can take a picture or you can find it later on the DevCon website. If you want to know more, Microsoft has a really excellent documentation for .NET Core. So this includes .NET Core, but also the main programming languages for .NET Core. And if you want to do web development using .NET Core, the framework is called ASP.NET Core and there's also great documentation for that. So thanks a lot for coming to this presentation. I hope this helps you get started with .NET Core on the next. Are there some questions? We can have a look. So the question is, how big is the self-contained Windows application? We can have a look, but I know it's fairly big upfront because there's currently no technology in the box that trims down the application. So it's really a full .NET runtime. You get there, so it will be like a couple of tens of megabytes, like I would guess maybe 50-ish megabytes. But there is work being done and something in a type of linker that really goes and trims out everything you're not using. So in the future, like .NET Core 3.0 or 3.1, we may get too much smaller executables. Are there, yeah. Yes, so the question is with self-contained, when we did the self-contained published application for Linux, can people just go and run that? Yes, this is like X copy deployment. You copy it somewhere, that folder and it will run on that Linux system. Other questions? Yes, I've actually showed that and Mac as well. So if you do framework dependent, then the user needs to install their runtime. But it's like with all these executables you're downloading nowadays, you need a different executable for Windows, a different one for Mac and a different one for Linux. So you need to go and compile for those platforms separately if you want to install, include .NET Core with that application. Other questions? No, well, thank you.