 I'm hearing some display issues, oh, I didn't set the resolution, sorry, sorry, okay, okay. So I guess we can start now, okay? So welcome, this is the last talk for today, I know you're tired, especially considering, you know, but I hope to keep it short and talk about .NET Core on Fedora. First a short introduction, if you don't know who I am. My name is Nemanya, it's a bit hard to pronounce, but I'm from Serbia, that's the reason, yes. I'm Fedora Ambassador from Serbia. I'm also a teaching assistant and a PhD student at Faculty of Sciences, Department of Mathematics and Informatics, which is in Novi Sad. And I'm also a .NET and Android developer at a small company called AlphaSoft. And I'm here today to talk about .NET Core on Fedora. So this is the short plan, what we're going to do. I'm briefly going to go over, the others have mentioned already, what is .NET Core. I'm going to tell you why you should consider using .NET Core. I will also tell you why you should be against .NET Core and when you shouldn't use it. And then I'm going to focus on the topic here, which is the packaging of .NET Core for Fedora. And lastly, I'll tell you how to get started today. And I'll tell you how to get needed packages in Fedora and there will be a short demo. Okay. So .NET Core, you've heard about it already today a lot. But let's just repeat over some main talking points. It's an open source, MIT license subset of the original .NET framework. Not everything is there yet. It's the future of .NET. All the development is shifting towards it. So it's the next thing in .NET lifetime. In the end, it's a modern, modular, another modern, modular, powerful framework, which is suitable for all kinds of applications. It is also cross-platform. The asterisk there is, it's not yet fully cross-platform. You can't actually run it on quite a few platforms, let's say. There's no official support for Fedora 25. That's something we are trying to change. There's also limited ARM support. You can run it on Raspberry Pi if you install Windows 10 IoT version or whatever it's called. So you can't run it on Linux on ARM as far as I know. So yeah, that star is going to stay there until they fix that, which is supposed to happen somewhere this year, I think in version 2.0. So why you should consider using .NET Core for your applications? Well, in my opinion, the main reason why you should consider .NET Core is because of the languages, because of C-sharp and F-sharp, which are really feature-rich and powerful languages. If you are coming from a Java background, C-sharp is like, it has a much broader set of features. It has stuff like asynchronous operations by default. It has integrated query language, things like that. So for me, that's the reason I'm developing in .NET Core, not something else, it's because of the language. Also, the ecosystem is pretty good. You can get a lot of good open-source libraries for .NET Core. Of course, a lot of the right libraries are still being ported to .NET Core and only support the big old .NET framework. So that's something you should be aware of. Also, the reason why you should consider using .NET Core is if you have an old .NET code base, which you need to maintain, it's now much easier to transition to .NET Core than to completely rewrite your application in another language, obviously, because it's the same language. Also, their support has demonstrated for OpenShift very easily. You can deploy your applications to OpenShift. And as others have mentioned, ASP.NET Core, which is the web framework around .NET Core, is pretty fast. There's a link on GitHub where they keep their benchmark results. There was a talk today about 3 million requests per second, even more than that in the new ASP.NET Core. So, why not .NET Core? The tooling is, let's be kind, it's incomplete. If you're on Linux, if you're developing for .NET Core, you're going to run into some issues. The tooling is actually still in preview version, release candidate version. And 1.0 version is coming soon. We're being said it's days, weeks, maybe before the next big version, 1.0, the final version. Also, when you use .NET Core, you're pretty much locked into using it to develop only two types of applications, either console applications or web applications. You can develop desktop applications. You can use Electron, that's the most sane thing to do. There are some frameworks which are open source, Avalonia, I don't know, maybe you heard of it, is one of them which can, it uses GTK bindings to display on Linux. So you can use that, but mostly you're locked into developing web applications and console applications. Also, one of the things that are annoying is there are still breaking changes in the framework, so if you listen to any other .NET Core talk today, all of them showed a nice project JSON file, which isn't going to be in the next version. It's replaced with an XML file. Why? We don't know. It's easier to read maybe for some people. It's still going to be human readable, but that's just one example of a breaking change. I'll get to the breaking changes later. Also, you should be aware, obviously there are other frameworks. No one is saying you should use it. This is the best framework in the world. At least I am not. So, yeah, you should consider wisely why you should and why you shouldn't use .NET Core, and we hope to provide you with a package for Fedora. So, package in .NET Core for Fedora. The .NET special interest group in Fedora, this is our wikipage, and this is our pager where we keep all the things we do. Our main goal is to package .NET Core in Fedora. Our other goals are to send patches to the upstream and help provide support for .NET Core developers on Fedora. We have IRC meetings every Tuesday at 7 p.m. So, you can join us. We talk about .NET Core. The interesting thing about the .NET special interest group is that around 50% of the members are in this room, in that room actually. So, join us. We discuss packaging. We discuss .NET Core on Fedora. And that's it about .NET 6. So, some of the issues with the packaging. First of all, we had an issue with the internalization library, LibIcu. Why? Well, it was up until recently hard-coded in major .NET Core releases. So, .NET Core comes out, and it's locked to, I don't know, Libisu 54. So, that was pretty hard to fix. But in the upstream, it's fixed. So, when we are building from source, as we are now, not fully, but we are, we can fix that and it's okay. Another issue is obviously Fedora OS has major Fedora releases, get the new version. So, timing is an issue. So, .NET Core comes out. It expects one version. Fedora comes out after it. Has another version. It doesn't work anymore. So, yeah. For example, I think that's the main reason why you don't have Fedora 25 support still in official support for Microsoft because .NET Core 1.1, which is the latest version, came, I think, two weeks after Fedora, or before Fedora 25. So, it was only Fedora 24 supported. Another issue is obviously all packages in Fedora have to be built completely from source. And with .NET Core, it is at the moment impossible to build the entire stack without using some sort of pre-built binaries. Or in some cases, you can't even build it without Windows. In the upstream, and very soon with .NET Core 2.0, we're going to have a simpler build system and we'll be able to build it fully from source. Obviously, to build .NET Core, you need .NET Core, a working version, because Roslin, the C-sharp compiler, is written in C-sharp, as luck has it. So, we can use a bootstrapping tool, and there is such tool. It's called the rover tool and we are using it, but it only partially rebuilds the main package. It doesn't change everything. I'll show it later. So, it's not a fully, you know, I'm pulling this repository, building everything, and I get the binaries. It's not like that. It's just for modifications. Another issue was licensing. So, you go to the GitHub repository, where everything is, and there is an MIT license there. You go to download the binaries, and there is a weird Microsoft and user license agreement in the package, which says you can't distribute this package or anything like that. So, that was very weird. It's also fixed in the upstream. With 2.0, it's going to be fine. We fix it manually for now. And we can't build for... That's the issue five. We can't build for Fedora 26 for now, because there was a wrong header version specified somewhere. It's in upstream. It's fixed. So, we are just waiting. It may be merged already. I don't know, but we're waiting for it to go, and then we'll be able to build for Fedora 26. So, if you want to start developing with .NET Core on Fedora, today, if you're using Fedora 24, which is still supported, obviously, you can use the pre-built binaries from Microsoft, where LibICU version is hard-coded correctly. If you're using Fedora 24, if you don't want to use the Microsoft binaries, or if you are using Fedora 25, there are two cool other copper repositories, which you can use. So, the first one is called .NET 1.1. It's basically the same binaries you get from Microsoft, but with the correct LibICU bundled. It's not built from source, obviously. And it's also known as the worst RPM in the world, because if you go to packaging guidelines, it breaks pretty much everything there, because it's not built from source. It's a wrong license inside, but it works. It works, yeah, so you can use that. Or, a couple of weeks before this conference, we built the other repository, which is the .NET clean repository. It's the latest and cleanest, so that's why it's called .NET clean build we have so far. So, what do we do here? We take binaries from Red Hat Enterprise Linux, which are built by a trusted developer. That's his name. We verify the package is correct, so we have the check sound. We make sure it's the exact same package, so we can trust it. Then we use the Robert tool to bootstrap it, and it partially rebuilds the complete .NET core and gives us the binaries. One small issue with this is that this binary, which we have on Fedora 25, reports the wrong RID. RID is a runtime ID. Each report is running on Red Hat Enterprise Linux, and it should report that it's running on Fedora 25. It's not a major issue, because we can run it, like we can run .NET core applications with the shared runtime, so it doesn't care what it reports, but we will definitely need to be fixing this. That's because the Robert tool doesn't completely rebuild the package. It only partially rebuilds the package. If you're interested how the spec file works, it's right there. The link is right there. The future of packaging .NET core for Fedora, we have to prepare for the new build system, which is coming soon. Until then, we agreed to build unstable versions, until .NET core 2.0 is released, so we are ready when it's released. We are meant to support secondary architectures, so you can run .NET core on your Raspberry Pi, because Fedora runs on Raspberry Pi now. Obviously, proper fully built packages for Fedora 26 or Fedora 27. We hope it's for Fedora 26. The last step is, of course, to write tutorials, documentations, and things like that. The tool on the inner field version, if you have Fedora and you just want to use .NET core, enable the copper, install the package name is .NET core, and you can run it just fine. That's it. I just want to briefly mention some other tools, since you're going to develop .NET core applications on Fedora. You can use Visual Studio Code. Others have mentioned it. It's a very nice textual editor. You can get an RPM from Microsoft, or even better. Fedora, a developer who maintains Visual Studio Code repository, it's the same file, but you get automatic updates, obviously, this way. I would recommend the second option. You can also use Microsoft SQL Server. Microsoft tools usually play nice together. The build for Red Hat Linux works fine on Fedora. There's a nice magazine article on how to get it running. I have it running at home. It's working pretty stable. It's a public preview version, so every time you start it, it says 167 days still self-destruction or something like that. It warns you it's not the final one. The last tool I want to mention, others didn't mention it, is the DreadBrain Rider. It's another IDE from DreadBrain, which I believe is a track company. Yes? Yes. It's still in early access preview, but I suggest you try it. It's pretty good. It has Resharper included. Resharper is like Linting helper tool, only one for .NET developers. It's pretty awesome. The Resharper is also their project, and this is the first time it's actually Resharper is coming to other platforms. So this is awesome. You previously could use it only with Windows and with Visual Studio. So try DreadBrain Rider. I meant to show it here, but this machine only has two gigabytes of RAM, and at the moment it's a bit heavy, so I'm not going to show it. I have it here, but it's a bit slow, so I don't want to, for you to think it's slow and don't try it, because if you want to try .NET Core really, you have to try the tool. It's pretty good. Okay, so we are left with another question. So is this .NET Core really ready for, should you trust this? Is it really ready to use in a production environment? Well, at my company we've been running a .NET Core application, which was a .NET, fully .NET built application, 4.5 I think it was, and we migrated it to .NET Core, mostly because I wanted to play with it and see how it is, and I developed on Fedora. So it's been running I think a year now. We developed on Fedora and then it's run on Windows machines, so it's opposite of the other demo that Tom showed, where we developed on Windows and run on Fedora, but we haven't had any issues with it, apart from the breaking changes which I mentioned, so between 1.0 release candidate, which was supported, go live license or whatever from Microsoft, 1.0 was a massive change, nearly all configuration was put out and then replaced with another model. So that was annoying, lost a week there, but other than that, no memory leaks, no things like that. I would say it's ready for production, it's a pretty good framework. You should definitely try it. It's a new framework in our world, in our open source Linux development world, but you should try it. It's not that difficult to use. You can use C sharp with it and it's pretty good. So I want to show you a quick demo. Let's just... So I meant to show you a demo where I run a small application on OpenShift, but Tom already did that, so I'm going to show you how easy it is to write a small, very small, in fact, web service using .NET Core. Can you see the... It's pretty big for me, but I don't know if you can see it. So what you need to do, I already have... So this is obviously Fedora 25, as you can see, and I have the clean version of the .NET framework. You can see it's clean because it reports the wrong RID, which I mentioned is the issue. Nowhere here it says it's clean, but you can trust me it's clean and it says that we are running on Fedora 25 Linux, et cetera, et cetera. Okay, so let's make a new directory and let's run .NET new. This creates two files. One is the main program class, the main entry point of program, which is just as hello world as you can see. And the other one is project JSON file, very simple. You can see you can declare your dependencies here, it works in runs on and things like that. I don't want to bore you. You already seen it and it's going away. So what's the point of showing it, yes? So let's just do a restore, which will restore all the packages that I specified. Okay, that was quick. And then .NET run, which will just show us a hello world. So nothing special here. So it's very easy to go from here. Let's use Visual Studio Code. It's very easy to go from here to a small web server, web service, sorry. So what you do, you will obviously need some dependency. It asks me, do I want to add some assets, Visual Studio Code? Okay, add them. So let's specify a few dependencies. We'll use Microsoft ASP.NET Core MVC framework. And we're going to use only the core part, which is basically just some routing, some templating, nothing more. No view rendering. You can write a very small API with this package. So version is one point. I don't know what is available. 110 should work. And we need another package where we would pull the web server. So let's pull the web server. It's also a NuGet package, so we can just find it. There it is. Okay? So I don't know if anyone else showed this, but there's a very cool feature in the Visual Studio Code where you can run a terminal inside. So let's just run .NET Restore again. It will pull this package, it pulls them locally because I had these packages in my cache already. Okay? So if I run it now, nothing will obviously change. I have to do some configuration. It will still just say hello world. There we go. But let's now modify this a bit. So instead of hello world, we want to start a web server. So let's just say new web host, I believe. Just one second. And just say what do we want to use? We want to use new web host dot. Is it web host? Just one moment, sorry. Actually, it's maybe better if I just use new, maybe shared web host. I'm not sure what it's called. Just one moment. Let's do it like this. Microsoft ASP.NET Core Hosting dot. I host, I web host builder, sorry. Then we can say, oh, sorry. Just one moment. I web host. Okay. I know what I'm going to do. I'm going to show you the finished demo, which I already have. Just one moment. So I can save you some time. Okay. It's difficult to remember all the class names. So I'll go to projects. Devconf demo. Okay. There we go. Let's just open this. It's called web host builder. Sorry. Okay. So instead of the hello world prompt, we just use a new web host builder. We tell it that we want to use Castrol, which is a web server from Microsoft. We want to use a startup class. Startup class is specified just under here. It's not very clean to specify them in the same file, but okay. We want to build this web host, and we want to run it. So in startup class, we just say, we have two methods. We just say add MVC core, which is the service we want to use.