Understanding Microsoft .NET 5

One of the key themes of Microsoft’s 2020 developer strategy is perhaps best thought of as the shift between generations. It’s a relatively smooth handover, framed as a unification of old and new ways of working. But in the end, whether it’s Project Reunion, WinUI 3, or the launch of .NET 5, the new technology forges ahead, leaving the old behind.

That’s not a bad thing. We develop new ways of doing things for many reasons, but they often coalesce around one key point: The new way is better. It solves problems that old tools couldn’t and answers new questions that weren’t being asked when the original solution was being defined.

A new .NET for a new world

All those reasons come together in the transition from the .NET Framework to .NET 5. Twenty-odd years ago when the original .NET Framework was being defined, we built monolithic client-server applications in tightly defined IT environments. Now we’re building a mix of lightweight distributed microservices and cross-platform mobile apps, using rapidly changing infrastructures. It is, despite the cliché, a whole new world.

.NET Core was designed for this way of working; cross-platform from early in its life and intended to support new, cloud-first mobile applications as well as traditional .NET development patterns and practices. It picked up more and more APIs through three major releases, and when the .NET Standard libraries began to offer a common target for code that made it easier to share projects across it, the .NET Framework, and Xamarin.

.NET 5: A path for future development

Technically this new release should be .NET Core 4, but Microsoft is skipping a version number to avoid confusion with the current release of the .NET Framework. At the same time, moving to a higher version number and dropping Core from the name indicates that this is the next step for all .NET development. Two projects still retain the Core name: ASP.NET Core 5.0 and Entity Framework Core 5, since legacy projects with the same version numbers still exist.

It’s an important milestone, marking the point where you need to consider starting all new projects in .NET 5 and moving any existing code from the .NET Framework. Although Microsoft isn’t removing support from the .NET Framework, it’s in maintenance mode and won’t get any new features in future point releases. All new APIs and community development will be in .NET 5 (and 2021’s long-term support .NET 6).

Some familiar technologies such as Web Forms and the Windows Communication Foundation are being deprecated in .NET 5. If you’re still using them, it’s best to remain on .NET Framework 4 for now and plan a migration to newer, supported technologies, such as ASP.NET’s Razor Pages or gRPC. There are plans for community support for alternative frameworks that will offer similar APIs, but working with newer approaches will help future-proof code and make it easier to work cross platform.

One slightly confusing aspect of .NET 5 is how it works with .NET Standard libraries. They’re not going away, though .NET 5 code doesn’t need to reference them directly as they’re now a subset of the .NET 5 target framework moniker (TFM). This new TFM replaces the old netcoreapp and netstandard TFMs, though if you’re writing code that needs to be shared across frameworks, you can still use the .NET Standard 2.0 TFM for compatibility purposes. In most cases, however, you’re likely to only be working in a .NET 5 environment so you can safely stick with a net5.0 TFM declaration.

Getting started with .NET 5

.NET 5.0 continues hosting the same familiar set of languages, including new versions of both C# and F#. These add many new features and come as part of Visual Studio 16.8 or with the updated C# Visual Studio Code extension. Microsoft has moved the framework and all its implementations, like much of Mono, into a single GitHub repository, consolidating development and ensuring that all versions have the same underlying features. As Microsoft moves to .NET 6 it’ll bring in other higher-level implementations, including Xamarin.

The new .NET remains based on the just-in-time compiler techniques developed for the original Common Language Runtime. The new CoreCLR continues to improve performance, while working across multiple processer architectures. With the arrival of Apple’s M1 ARM-based processors, code written in .NET for macOS will run as native binaries on both Intel- and ARM-based hardware, so code won’t have to go through a second layer of emulation. Support for ARM64 will allow .NET 5 applications to run natively on Windows on ARM hardware, taking advantage of features in Microsoft’s own SQ1 and SQ2 processors.

Some scenarios, like Web Assembly and mobile operating systems, require precompiled code, and .NET 5 offers an ahead-of-time compiler alongside its JIT tooling. The AOT compiler is now available for any development environment, and the Uno Platform team is already seeing significant speed increases for its Web Assembly support, on the order of 7 to 15 times over the previous Web Assembly language interpreter.

There are plans to make the AOT compiler available as an option for apps that need quick startup and lower memory footprints, for example on resource-limited smartwatches and IoT hardware. Another option is single file deployments. Everything needed for an application (including the runtime) is bundled into a single package, making it easier to deploy .NET applications in containers or on non-Windows systems.

The new .NET shouldn’t be seen in isolation. Additional developments around Web Assembly with Blazor and cross-platform UI development with MAUI (multiplatform app UI), are also important. By using a combination of these technologies, very little can’t be targeted with .NET 5, from Raspberry Pi-class hardware to Android phones to Kubernetes-hosted containers running on AWS and Azure.

On to .NET 6 in 2021

One important point is that this is only one more step in a process. .NET 5 is a key technology for the separation of the Windows APIs from the OS, the Project Reunion merger of WinRT and Win32 APIs, and the move to both WinUI 3 and MAUI as UI layers. Much of that work continues with 2021’s release of .NET 6—the target for many of these projects. You don’t need to wait for .NET 6 to get started with migrations. The sooner you start, the better, giving you time to deal with any issues that may emerge.

You should see .NET 5 as a first step in the next leg of the .NET journey, one where you should start to take all that legacy code and decide what’s necessary to bring forward by porting and updating, and what needs to be completely replaced. As 2020 comes to an end, you’re likely to be planning your 2021 development schedule. With that in mind, .NET 5 should be a lens that helps you focus on what needs to be done to keep your software estate ready for a much faster-moving future that’s no longer tethered to Windows releases—or to Windows at all.