.NET Core: 3.0 New Features You Need to Know

Learn what is new in .NET Core 3.0. .NET Core 3.0 contains support for Windows desktop applications, improvements in C# 8.0, .NET Standard 2.1, framework-dependent executables, assembly linking, cryptography ciphers, and many other amazing features.

.NET Core 1.0 launched on November 2014. It runs across Linux, Windows, and macOS operating systems. Additionally, it is a free, open-source development environment for the building of any kind of application such as web, Android, iOS, cloud, and IoT Applications..Net core is maintained by Microsoft as well as the Dot NET community on GitHub.

 

In .Net core, you can install a new version without worrying about breaking existing applications. Furthermore, apps can easily embed the .NET framework. In the first version, their primary focus was to maintain high-performance web and microservices. In Core 2.0 version, they added many things to simplify the port of web apps, SignalIR, Razor Pages, etc. The latest version is now .Net Core 3.0. In this article, I mention all the improvements and the latest features of the new .Net core.                                                                                                                                                                                                                                                                              

 

Windows Desktop Apps

 

The highlight of .NET Core 3 is support for Windows desktop applications, specifically Windows Forms, Windows Presentation Framework (WPF), and UWP XAML. You will be able to run new and existing Windows desktop applications on .NET Core and enjoy all the benefits that .NET Core has to offer.

 

One can assemble Windows desktop applications utilizing Windows Forms and WPF. with the .NET Core 3.0. It supports the use of modern controls and familiar styling from the Windows UI XAML Library (WinUI). It is a piece of the Windows .NET Core 3.0 SDK.

 

Language improvements C# 8.0

 

In .Net core 3.0, C# 8.0 is also released, which includes the Nullable reference types. This was already considered in the release of C# 7.0 development but was postponed until the 8.0 version. The main concern of this feature is to help developers avoid unhandled NullReferenceException exceptions. The principle idea allowing variable type definitions to specify whether or not they can have a null value assigned to them. As the technology moves toward more microservices and other cloud-based architectures, other language tools are needed. C# 8.0 expands this vocabulary so that you can use more pattern expressions at increased spots in your code. C# 8.0 introduced Tuple patterns, Positional patterns, Switch expression and Property patterns.

 

Pattern matching provides tools to give shape-dependent functionality across related but different kinds of data. C# 7.0 introduced syntax for type patterns and constant patterns by using the 'is' expression and the switch statement. These features represented the first tentative steps toward supporting programming paradigms where data and functionality live separately. Consider these features when your data and functionality are separate. Consider pattern matching when your algorithms depend on a fact other than the runtime type of an object. These techniques provide another way to express designs. Also, work on Language enhancements by adding the API features of Async streams and Ranges and indices.

 

.NET Standard 2.1

 

.NET Core 3.0 implements .NET Standard 2.1. In total, about 3k APIs are planned to be added in .NET Standard 2.1. A good chunk of them are brand-new APIs while others are existing APIs that we added to the standard in order to converge the .NET implementations even further.

The .NET Standards are the formal specifications of .NET APIs that are intended to be available on all .NET implementations. The motivation behind the .NET Standard is to establish greater uniformity in the .NET ecosystem. To target .NET Standard 2.1, edit your project file and change the TargetFramework property to netstandard 2.1. (If you're using Visual Studio, you need Visual Studio 2019, as Visual Studio 2017 doesn't support .NET Standard 2.1 or .NET Core 3.0.)

 

Blazor Server

 

With .NET Core 3.0, you can develop amazing interactive client-side UI with Blazor Server. Blazor Server can be used to write completely new apps or to complement existing MVC and Razor Pages apps. There’s no need to rewrite existing app logic. Blazor is designed to work together with MVC and Razor Pages, not to replace them. You can continue to use MVC and Razor Pages for your server-rendering needs while using Blazor for client-side UI interactions.

 

 

 

Blazor Server is a great way to add client-side functionality to your existing and new web apps using your existing .NET skills and assets. Blazor Server is built to scale for all your web app needs. Blazor WebAssembly is still in preview but is expected to ship in May of next year. In the future, it is expected to continue to evolve Blazor to support PWAs, hybrid apps, and native apps. For now, we hope you’ll give Blazor Server a try by installing .NET Core 3.0.

 

Deployment of Application

 

Default executables

 

Previously, only self-contained deployments would produce an executable. Now .NET Core now builds framework-dependent executables by default. This behavior is new for applications that use a globally installed version of .NET Core. By using framework-dependent, the size of your deployment package is small. You only deploy your app and its dependencies, not .NET Core itself.

 

Your app can be run by calling the published executable without invoking the dotnet utility directly.

 

Single-file executables

 

The executable is self-extracting and contains all dependencies (including native) that are required to run your app. When the app is first run, the application is extracted to a directory based on the app name and build identifier. Startup is faster when the application is run again. The application doesn't need to extract itself a second time unless a new version was used.

 

Assembly linking

 

The .NET core 3.0 SDK comes with a tool that can reduce the size of apps by analyzing IL and trimming unused assemblies. Self-contained apps include everything needed to run your code without requiring .NET to be installed on the host computer. However, many times the app only requires a small subset of the framework to function, and other unused libraries could be removed. To enable this tool, add the <PublishTrimmed> setting in your project and publish a self-contained app:

<PropertyGroup>
<PublishTrimmed>true</PublishTrimmed>
</PropertyGroup>

 

ReadyToRun images

 

You can improve the startup time of your .NET Core application by compiling your application assemblies as ReadyToRun (R2R) format. R2R is a form of ahead-of-time (AOT) compilation.

 

R2R binaries improve startup performance by reducing the amount of work the just-in-time (JIT) compiler needs to do as your application loads. The binaries contain similar native code compared to what the JIT would produce. However, R2R binaries are larger because they contain both intermediate language (IL) code, which is still needed for some scenarios, and the native version of the same code. R2R is only available when you publish a self-contained app that targets specific runtime environments (RID) such as Linux x64 or Windows x64.

To compile your project as ReadyToRun, do the following:

Add the <PublishReadyToRun> setting to your project:

<PropertyGroup>
<PublishReadyToRun>true</PublishReadyToRun>
</PropertyGroup>

 

Cross platform/architecture restrictions

 

The ReadyToRun compiler doesn't currently support cross-targeting. You must compile on a given target. For example, if you want R2R images for Windows x64, you need to run the publish command on that environment.

 

Exceptions to cross-targeting:

• Windows x64 can be used to compile Windows ARM32, ARM64, and x86 images.
• Windows x86 can be used to compile Windows ARM32 images.
• Linux x64 can be used to compile Linux ARM32 and ARM64 images.

Windows desktop

 

.NET Core 3.0 supports Windows desktop applications using Windows Presentation Foundation (WPF) and Windows Forms. These frameworks also support using modern controls and Fluent styling from the Windows UI XAML Library (WinUI) via XAML islands. The Windows Desktop component is part of the Windows .NET Core 3.0 SDK. You can create a new WPF or Windows Forms app with the following dotnet commands:

.NET Core CLI

dotnet new wpf
dotnet new winforms

Visual Studio 2019 adds New Project templates for .NET Core 3.0 Windows Forms and WPF.

For more information about how to port an existing .NET Framework application, see Port WPF projects and Port Windows Forms projects.

 

SerialPort for Linux

 

.NET Core 3.0 provides basic support for System.IO.Ports.SerialPort on Linux. Previously, .NET Core only supported using SerialPort on Windows.

 

For more information about the limited support for the serial port on Linux, see GitHub issue #33146.

 

Docker and cgroup memory Limits

 

Running .NET Core 3.0 on Linux with Docker works better with cgroup memory limits. Running a Docker container with memory limits, such as with docker run -m, changes how .NET Core behaves.

Default Garbage Collector (GC) heap size: maximum of 20 mb or 75% of the memory limit on the container. Explicit size can be set as an absolute number or percentage of cgroup limit. The minimum reserved segment size per GC heap is 16 Mb. This size reduces the number of heaps that are created on machines.

 

Fast built-in JSON support

 

.NET users have largely relied on Json.NET and other popular JSON libraries, which continue to be good choices. Json.NET uses .NET strings as its base datatype, which is UTF-16 under the hood.

 

The new built-in JSON support is high-performance, low allocation, and based on Span<byte>. For more information about the System.Text.Json namespace and types, see JSON serialization in .NET - overview. For tutorials on common JSON serialization scenarios, see How to serialize and deserialize JSON in .NET.

 

Cryptography ciphers

 

.NET 3.0 adds support for AES-GCM and AES-CCM ciphers, implemented with System.Security.Cryptography.AesGcm and System.Security.Cryptography.AesCcm respectively. These algorithms are both Authenticated Encryption with Association Data (AEAD) algorithms.

 

The following code demonstrates the use of AesGcm cipher to encrypt and decrypt random data.

public static void Sharper()
      {
          // key should be: pre-known, derived, or transported via another channel, such as RSA encryption
          byte[] key = new byte[16];
          RandomNumberGenerator.Fill(key);

          byte[] nonce = new byte[12];
          RandomNumberGenerator.Fill(nonce);

          // normally this would be your data
          byte[] dataToEncrypt = new byte[1234];
          byte[] associatedData = new byte[333];
          RandomNumberGenerator.Fill(dataToEncrypt);
          RandomNumberGenerator.Fill(associatedData);

          // these will be filled during the encryption
          byte[] tag = new byte[16];
          byte[] ciphertext = new byte[dataToEncrypt.Length];

          using (AesGcm aesGcm = new AesGcm(key))
          {
              aesGcm.Encrypt(nonce, dataToEncrypt, ciphertext, tag, associatedData);
          }

          // tag, nonce, ciphertext, associatedData should be sent to the other part

          byte[] decryptedData = new byte[ciphertext.Length];

          using (AesGcm aesGcm = new AesGcm(key))
          {
              aesGcm.Decrypt(nonce, ciphertext, tag, decryptedData, associatedData);
          }

          // do something with the data
          // this should always print that data is the same
          Console.WriteLine($"AES-GCM: Decrypted data is {(dataToEncrypt.SequenceEqual(decryptedData) ? "the same as" : "different than")} original data.");
      }

 

Cryptographic Key Import/Export 

 

.NET Core 3.0 supports the import and export of asymmetric public and private keys from standard formats. You don't need to use an X.509 certificate. All key types, such as RSA, DSA, ECDsa, and ECDiffieHellman, support the following formats:

Public Key

• X.509 SubjectPublicKeyInfo

Private key

• PKCS#8 PrivateKeyInfo
• PKCS#8 EncryptedPrivateKeyInfo
• RSA keys also support:

Public Key

• PKCS#1 RSAPublicKey

Private key

• PKCS#1 RSAPrivateKey

The export methods produce DER-encoded binary data, and the import methods expect the same. If a key is stored in the text-friendly PEM format, the caller will need to base64-decode the content before calling an import method.