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 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 . 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, .
.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 . 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).
. 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
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.
, 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.
(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.
Copyright © 2020 IDG Communications, Inc.