 Hello everyone. Thank you for watching this session. My name is Olya Gavrish, I'm Program Manager on .NET team working on desktop, and today we will talk about modernizing your .NET desktop applications with .NET Core 3. But first, there are many different ways you can modernize or upgrade your applications. It's not only about how your application looks, it's also about how it works, how performant it is, what device or platform APIs it is using, how do you do DevOps, how do you deploy and distribute your application. This year has been a truly amazing year for .NET Desktop, because we got innovations in all of those areas. We will talk about all new features available for your desktop applications throughout the old .NET conference. In this talk, we will focus on how you can update your apps with .NET Core 3.0. On the day three, you will have another session by Mike Rousses about more advanced scenarios on porting to .NET Core your WPF applications. How to make your application look modern, how to integrate your application with devices and platform features. Everything about ZAML tools and ZAML islands will be covered by Dmitri in his talk tomorrow. Everything related to DevOps, MSIX, App Center, so how to capture analytics and diagnostics, how to deploy and distribute your application, you will learn from the talk by Daniel and Mike right after this session. So keep tuned and let's move to the agenda of this talk. First, I would like to start with, why should you care about .NET Core for desktop, and what to choose, .NET Core or .NET Framework for your desktop applications. Then I will talk about how you can port your framework application to .NET Core, if you decide so, and how to fix sporting issues. Then I would like to show you the .NET desktop tooling. It's ZAML and WinForms designers. So let's start. Why should you care about .NET Core for desktop? Well, there are many good reasons, but the most important is because .NET Core is the future of .NET. As you probably heard from the keynote, .NET Core is a platform that will receive feature updates in the future. In the next year, we will release .NET 5 in November 2020, which will be the next iteration on .NET Core. So by porting your application to .NET Core, now you're preparing your app for .NET 5. To switch from .NET Core to .NET 5 will be as easy as upgrading it to the next version of the platform. If you want your application to incorporate all the new things that will come in future, you want to be on .NET Core. That is what you should keep in mind when you think about future, but even today there are many great .NET Core specific things available that are not possible for .NET Framework application. We also talked about it at keynote, so I'll just briefly list them here. It's a side-by-side deployment of different versions of .NET Core on the same machine. For .NET Framework, you could have only one version and every time you want to switch to the later version of .NET Framework, you had to update it and all application that will run on that machine will have a dependency of that update. For developers, it usually means that you have to make a company-wide decision run by IT department which results in delays. With .NET Core, you can update at your own pace, because you can have many different versions of .NET Core on the same machine, and you can specify in your application which version of .NET Core you would like to target. You can go even further and you can package your .NET Core application with .NET Core platform itself. So you can distribute to your client self-contained application, which will be completely independent on the environment it will run on. Another great feature is a single file executable, where you can package your application and .NET Core Framework in just one .EXE file. A new feature of .NET Core 3 will allow you to trim out assemblies from .NET Core that are not required for your application. So that way, your single .EXE file will have much smaller size. There are many other great features that you can read about, and in future we will receive even more. So usually, I get the question, okay, does that mean I need to port all my existing .NET Framework applications to .NET Core, or how do I decide? Our advice is usually start your new applications on .NET Core. But if you have a completed apps that are in maintenance mode only, all development is finished, you don't want to touch that code again, it's completely fine to leave it on .NET Framework. In fact, we're leaving one of our applications on .NET Framework ourselves. Maybe you have heard of Visual Studio. So .NET Framework will be fully supported, it will receive all required and security updates. It's totally fine to leave your apps on .NET Framework. But if your application is an active development, and you keep changing the code, and you want to benefit from new features that are available only in .NET Core, you can consider porting your app from .NET Framework to .NET Core. So evaluate how much work that is, what are benefits you will get from .NET Core that are important for your particular case and make the call. Next question that usually comes up to might how much work is it to port from .NET Core to .NET Standard? Or in other words, how compatible is my app with .NET Core? Well, to find out use portability analyzer. This tool will tell you about all APIs in your code that are not supported with .NET Core 3, if you have any of those, and it will help you to refactor, to find areas that you will need to refactor to be .NET Core compatible. With that, let me go ahead and show you that portability analyzer in action. But first, let me show you the application I'm going to be porting today. So this is a WPF application that it's called PhotoStore. It will allow you to make online purchases of printing goods. Let's for this application run portability analyzer and see if this app is compatible with .NET Core. So I'm going to specify the path to my project and I will click button analyze. What this analyzer does, it looks at the references in your assemblies and it checks if all APIs that you're using from .NET Framework are present in .NET Core. So as a result, we will get a portability report where in the first column you have assembly names then target framework that they are targeting right now, and then how compatible they are with .NET Core. So 100 percent compatibility means you're good to go. If you have less than 100, it means that those assemblies have some APIs that are not fully supported in .NET Core. To learn more details, you can go to details tab and here you will see target type, target member, assembly where these APIs is used, and so on. But before diving into details tab, I would encourage you to take a closer look at the first tab and actually see what assemblies are not compatible. So in my case, the lines that have less than 100 percent compatibility, these are not actually my code. These are Newton-soft.js on Nuget packages that I'm using in my code. So I don't need to update their APIs. All that I need to do is to check that the author of the package provides the version that supports .NET Core or .NET Standard. To do that, you can go on nuget.org and just see if it supports .NET Core. I know for sure that Newton-soft.js on supports .NET Standard 1.2, that means it automatically supports .NET Core. So I'm good to go. So again, I don't need to worry about any of these, and everything else is 100 percent compatible. So I can go ahead and port my application to .NET Core. Let's talk about porting now. Porting from framework to Core is simply updating the value of the target framework parameter in your project file. But if you created your application on .NET Framework, and you did not touch your project file since then, it will have the old style project file. So before updating this value, you first need to migrate to the new so-called SDK style project file. Let me show you what is old project file. Let's go back to Visual Studio, and I'm going to unload my project. Then I will click Edit, Photo Store, and here we can see a very large XML file. This XML file also has parameters like Project Guides, like Project Types Guide, etc. That all tells me that this is old project file. Before porting to .NET Core, I will need to update my project file to the latest SDK style. There are ways how you can port to .NET Core manually. These are the steps how you do it. First thing, you search for package.config in your solution. If you have this file, you will need to right-click and choose migrate packages.config to package reference. Let me show that in Visual Studio. I will reload the project, and here I see packages.config. That is where we use to store references to the packages for the old style project file. For the new one, they are stored in the project file itself, so to not lose them, you will need to do right-click migrate package.config to package reference. Then next step is update content of your project file with the new SDK format. The easiest way to do it is to create a blank application targeting.NET Core. If you are porting WinForms app, then create a WinForms targeting.NET Core. If you're porting WPF, then WPF. Open the project file, copy everything from it, and paste it in your current project file. But make sure you have the copy of the old project file because you will need that as well. You will need that to get all references and resources from your old project file to the new one. So everything related to package reference, project reference, content, resources, and so on, should be moved to the new project file. Well, it seems like a lot of work, and we've been constantly asked to please try and automate at least some common steps for all APIs. Of course, every application is different, and it's almost impossible to create a silver bullet that will work for everything, but at least we can try to automate most cases. We did that and we created a tool called TriConvert. So what it will do, it will try to convert your old project file to the new SDK style project file, and it will update the version to.NET Core 3.0. To use it, I'm going to just type in the console triconvert.exe, and as a parameter, I will send the pass to my project file. Let's see. Okay. Conversion complete. Let's go back to Visual Studio. I'm going to reload the files, and now if I right-click on properties and go here, I can see that target framework is.NET Core 3.0. So the tool worked and we successfully converted our.NET Framework application to.NET Core. In just a few clicks. Let's now run our application and see how that looks. So it looks and feels the same, but right now it's running on top of.NET Core instead of.NET Framework, which means that we can benefit from all the.NET Core features. Okay. I'm going to go back to my slides and this is TriConvert. If you got any portability errors. So if after porting to.NET Core, you're getting an error that some assembly is missing, but your portability report was 100 percent compatible, was completely green. That means you can easily fix those errors by just adding Nuget package microsoft.windows.com compatibility. That package has 21,000 APIs. Some of them are Windows only and some of them are cross-platform and these are areas that those APIs are related to. So with that, I would like to talk about tooling for desktop. Let's go back to my application. As you remember that is WPF application and we just ported it to.NET Core. So if I open Windows, mainwindows.zaml, you can see the designer. This ZAML designer, it looks very similar to the traditional.NET Framework designer. In fact, you barely can see any differences, but it runs outside of the process. It means that the surface of the designer talks to Visual Studio, they communicate between two different processes, and it was not very easy for us to implement that. So ZAML designer is already available in Visual Studio, and you can use it, you can go ahead and port your applications to.NET Core and try that amazing tech. As for WinForms designer, we started working on WinForms later than on ZAML designer, and it was a huge technical effort for us to re-architect the way how designer surface will talk to the Visual Studio process. So we're in very early days and today, I'm very happy to announce that we are releasing the first preview version of Windows Forms Designer. It's available at this link, it's a V6 package. It's not included in Visual Studio just yet because it's still very early days for it. What this first version has, it has a coverage for common controls and base operations. We will be adding functionality, we will be releasing new preview versions every month. Next one is coming early November. Just to let you know, this version is our first start, so it's not yet ideal to port your existing applications. It will be good for prototyping and writing hello world with basic common controls, basically to see the progress and to give us early feedback. But for your production applications, wait till the designer gets more mature and we will definitely let you know when it's a good time to port your apps to.NET Core. So please give us feedback via Visual Studio Channel, and let me show you how the VIN Forms Designer look. So I'm going to close this and I will create a new VIN Forms application targeting.NET Core. I'll search for VIN Forms here, and when I click on Form 1.cs, I can see the new VIN Forms Designer. So when we look at the toolbox, these are the controls that are supported in the first preview version. Of course, by the GA of VIN Forms Designer, we will be at functional parity with the traditional framework designer. So all controls will be there and you will have a seamless experience of porting your apps to.NET Core. Right now, it's just those guys. So we have button, checkbox, check links, etc. We can add the controls the same way. We can interact with properties, we can change name, and so on. I know that I'm not showing you guys anything new because you've seen that designer for many, many years. But the amazing thing about this designer is that it runs outside of the process and it allows you to build.NET Core applications. So let me run that. This is the regular VIN Forms form. Right. So that was everything I had for today. Thank you very much for watching. Please give us your feedback. It's very important for us to know that we're developing the right thing for you, and you can reach me out on Twitter. Thank you for watching.