.NET Core 3 for Windows Desktop

In September, we released .NET Core support for building Windows desktop applications, including WPF and Windows Forms. Since then, we have been pleased to see many developers share their stories about porting desktop applications to .NET Core. We constantly hear stories from .NET developers of Windows desktop applications about how they support their business with WPF and Windows Forms, especially when the desktop wins, including:

• FOD applications (forms over data) with a dense UI
• Responsive, low latency user interface
• Applications that must work offline
• Applications with dependencies on custom device drivers

Check out the cat to learn more about the benefits of .NET Core for building Windows applications.

Why is Windows desktop on .NET Core?

.NET Core (and in the future .NET 5, built on the basis of .NET Core) will become the future of .NET. We strive to support the .NET Framework as long as possible, however it will not receive any new features, they will be added only to .NET Core (and, ultimately, .NET 5). To improve the Windows desktop stacks and allow .NET desktop developers to benefit from all future updates, we introduced Windows Forms and WPF for .NET Core. They will continue to be Windows-only technologies, as they are closely related to the Windows APIs. But .NET Core, in addition to cross-platform, has many other features that can improve desktop applications.



First of all, all runtime improvements and language features will be added only in .NET Core, and in the future in .NET 5. A good example here is C # 8, which became available in .NET Core 3.0. In addition, .NET Core versions of Windows Forms and WPF will become part of the .NET 5 platform. And, porting your application to .NET Core, you prepare it for .NET 5.



In addition, .NET Core provides deployment flexibility for your applications with new options not available in the .NET Framework, such as:

• Parallel deployment Now you can have several versions of .NET Core on one computer and you can choose which version each of your applications should focus on.
• Offline Deployment. You can deploy the .NET Core platform along with your applications and become completely independent of the end-user environment - your application has everything you need to run on any Windows computer.
• Smaller application sizes. In .NET Core 3, we introduced a new feature called the linker (also sometimes called a trimmer) that will analyze your code and include in the offline deployment only those assemblies from .NET Core that are necessary for your application. Thus, all platform details that are not used in your case will be deleted.
• Single .exe files. You can pack your application and .NET Core platform into a single .exe file.
• Improved runtime performance. .NET Core has many performance optimizations over the .NET Framework. If we recall the history of .NET Core, which was originally created for workloads on the web and server, it helps to understand whether your application can feel the noticeable benefits of optimizing the runtime. In particular, desktop applications that are highly dependent on file I / O, networking and database operations are likely to show performance improvements for these scenarios. Some areas in which you may not notice significant changes relate to the performance of rendering the user interface or launching applications.

By setting the properties <PublishSingleFile>



, <RuntimeIdentifier>



and <PublishTrimmed>



in the publication profile, you can deploy the cropped stand-alone application as a single .exe file, as shown in the example below.

 <PropertyGroup> <OutputType>Exe</OutputType> <TargetFramework>netcoreapp3.0</TargetFramework> <PublishSingleFile>true</PublishSingleFile> <RuntimeIdentifier>win-x64</RuntimeIdentifier> <PublishTrimmed>true</PublishTrimmed> </PropertyGroup>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Differences between .NET Framework desktop and .NET Core desktop

When developing desktop applications, you will not notice a big difference between the versions of WPF and Windows Forms for the .NET Framework and .NET Core. Part of our efforts was to provide functional similarities between these platforms in the field of desktop PCs and to expand the capabilities of .NET Core in the future.



WPF applications are fully supported in .NET Core, and you can start working with them while we work on minor updates and improvements. For Windows Forms, the runtime has been completely ported to .NET Core, and the team is currently working on the Windows Forms Designer. We plan to prepare it for the fourth quarter of 2020, but for now you can check the preliminary version of the designer in Visual Studio 16.4 Preview 3 or later. Remember to check the box under Tools-> Options-> Preview Features-> Use the Preview of Windows Forms designer for .NET Core apps and restart Visual Studio. Please keep in mind that experience with use is still limited, as work is still underway.

Important changes

There were several major changes to the .NET Framework and .NET Core, but most of the code related to the Windows Forms and WPF areas was ported to Core in the same way. If you previously used components such as WCF Client, Code Access Security, App Domains, Interop, and Remoting, you will need to refactor the code if you want to switch to .NET Core.



One thing to keep in mind: the default output paths in the .NET Core are different from the paths in the .NET Framework, so if your code has some assumptions about the file / folder structure of the running application, then it will probably fall in runtime.



There are also changes to the configuration of .NET functions. Instead of using the machine.config



file, .NET Core uses the <something>.runtimeconfig.json



file that comes with the application and has the same main purpose and similar information. Some configurations, such as system.diagnostics



, system.net



, or system.servicemodel



, are not supported, so the application configuration file cannot be loaded if it contains any of these sections. This change applies to System.Diagnostics



tracing and WCF client scripts that were previously typically configured using the XML configuration. In .NET Core, you need to configure them in code instead. To change the behavior without recompiling, consider customizing trace types and WCF using values ​​downloaded from a Microsoft.Extensions.Configuration



source or from appSettings



.



You can find more information about the differences between the .NET Core and the .NET Framework in the documentation .

To get started

Check out these short tutorials:

• Getting started with WPF and .NET Core
• Getting Started with Windows Forms and .NET Core
• Differences between .NET Core and .Net Framework and what to choose for your application

Porting from the .NET Framework to the .NET Core

First of all, start the Portability Analyzer (portability analyzer) and, if necessary, update the code to ensure 100% compatibility with .NET Core. Here are instructions for using the portability analyzer. . We recommend that you use source control or make a backup of your code before making any changes to your application, in case the refactoring fails the way you want, and you decide to return to your original state.



When your application is fully compatible with .NET Core, you will be ready to port it. As a starting point, you can try the tool we created to help automate the conversion of your .NET Framework projects to .NET Core - try-convert .



It is important to remember that this tool is just a starting point in your journey to .NET Core. Also, this is not a supported Microsoft product. Although it may help you with some of the mechanical aspects of migration, it will not handle all scenarios or project types. If your solution has projects that the tool rejects or cannot convert, you will have to transfer them manually. Don’t worry, we have prepared many lessons on how to do this (at the end of the article).



The try-convert tool will try to transfer the old-style project files to the new SDK-style and reconfigure the corresponding projects in .NET Core. For your libraries, we leave it up to you to choose the platform: .NET Core or .NET Standard. You can specify one of them in the project file by updating the value for <TargetFramework>



. Libraries without .NET Core-specific dependencies such as WPF or Windows Forms can benefit from .NET Standard:

 <TargetFramework>netstandard2.1</TargetFramework>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

so that they can be used by callers targeting many different .NET platforms. On the other hand, if the library uses a function that requires .NET Core (for example, the Windows desktop UI API), the library should focus on .NET Core:

 <TargetFramework>netcoreapp3.0</TargetFramework>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

try-convert is a global tool that you can install on your computer and then call from the CLI:

 C:\> try-convert -p <path to your project>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

or

 C:\> try-convert -w <path to your solution>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

As mentioned earlier, if the try-convert tool does not work in your case, here are the materials on how to port the application manually.



Video

• Simple porting case
• Advanced Porting Case

Documentation

• Simple porting case
• Advanced Porting Case ( Part 1 , Part 2 )
• Porting Overview

---

See also: 7 free developer courses