Does .NET 5 Deliver on Its Promises?
By: Matthew Macdonald
Tags: Programming, Aspnetcore, Dotnet, Csharp, Microsoft

In a year full of unexpected disruptions, you could be excused if you missed Microsoft’s massive milestone. But here were are — as of November 10th, .NET 5 is an official release, replacing both .NET Core and the .NET Framework.

As we explained last year, .NET 5 isn’t just a bundle of new features. It’s the conclusion of a major effort to port .NET to a cross-platform, open source architecture. Essentially, it’s a mission to rebuild .NET, without disrupting the developers who currently rely on it for mature, deployed applications. The change isn’t without risk. In fact, it’s a bit like replacing the wheels on a racecar while it’s speeding down the track.

The effort began six years ago, when Microsoft surprised most of the world with the cross-platform .NET Core. Depending on your perspective, .NET Core was either an emerging .NET alternative or a strange shadow-clone version of the framework with its own conventions and headaches.

Then, .NET Core swallowed the entire framework. Or at least it got its jaws around the head—up until last year, it was still too soon to tell if it would manage to digest its entire meal. (Everyone who’s worked on an over-ambitious software project recognizes the point when you’ve gone so far on a major change that you can’t back out, but you’ve just realized there’s no way to complete the work on time and with all its promises intact.)

So now that .NET 5 is an official release, what’s the verdict? Did it fulfil its goal? And do its broken promises — and there were a couple — prevent it from succeeding?

The cross-platform promise

The central ambition of .NET 5 is to be a universal version of .NET — one that works for all modern types of applications, and replaces both the .NET Framework and .NET Core. And on this count, .NET 5 delivers.

.NET 5 supports every project type it set out to support, with no real asterisks. You can build the full suite of ASP.NET applications (Razor pages, Blazor apps, and Web API services). It’s a similar story on the desktop side, with support for Windows applications that encompasses Windows Forms and WPF. (Obviously, all these applications rely on the Windows operating system. Despite the cross-platform powers of .NET, you can’t run or develop them on different operating systems.)

The limits of the .NET promise haven’t changed either. For example, there are some legacy technologies that aren’t in .NET 5, including:

ASP.NET Web Forms

WCF (Windows Communication Foundation)

WF (Windows Workflow Foundation)

Some developers are understandably angry about these changes, but there are no surprises here — none of these technologies were ever in the .NET 5 roadmap. If you still need to support applications that use them, you’ll probably continue using the last version of .NET Framework (4.8). If you’re more ambitious, there are community projects trying to patch the WCF and WF gaps.

Blazor and C# in the browser

There’s nothing quite as exciting as brand new tech, and for the last year there’s been nothing newer or more ambitious in the Microsoft developer ecosystem than Blazor WebAssembly, an optimized runtime that lets you run C# code in a web browser.

Officially, Blazor had its first release in .NET Core 3.1, but .NET 5 gives it a chance to reach a wider audience, including plenty of developers who are still wondering whether the platform is stable enough for them to start exploring. The answer is yes—with a few caveats.

Blazor has definitely evolved past the point where it started, as a proof-of-concept experiment. But it’s still bigger and heavier than pure JavaScript frameworks like React and Vue. And the application model, which closely follows ASP.NET Razor, is a convenience for some and an irritation to others, especially those who don’t already have a background in ASP.NET.

Incidentally, there were a number of major Blazor enhancements that developers were hoping would make the .NET 5 cutoff. Most didn’t. We did get lazy loading and CSS isolation. But if you were waiting for one of these features, prepare to be disappointed:

Ahead-of time (AoT) compilation, which should make Blazor applications much faster, although it may require larger downloads.

True multithreading, which depends on still-uneven browser support.

Hot reloading, which triggers an automatic recompile when changes are made, and seamlessly shifts to the new version without restarting the application.

All of these features are still in play, and many are likely to show up in .NET 6. Whether Blazor is the best way to take advantage of WebAssembly in a browser — and how bright its future will be — are still up for debate.

See also:

The best examples to get started learning Blazor.

A deeper look at how Blazor works from our pre-release review, written exactly one year ago.

Harmonizing desktop development

Microsoft is famous for reinventing the wheel — except, instead of a wheel, think “desktop API.” Somehow, in a world that prizes a single codebase and run-everywhere languages like JavaScript, Microsoft has ended up simultaneously supporting three different models for Windows desktop development:

Windows Forms

WPF (Windows Presentation Foundation)

UWP (the ironically named Universal Windows Platform)

Although there’s still no sign of a single technology that can replace them all, Microsoft is trying to break down some of the walls that separate them. They launched Project Reunion, an initiative that will let Windows Forms and WPF applications use the FluentUI bits from UWP. Even more exciting, there’s a possibility that they’ll extend support beyond Windows 10, and all the way back to Windows 8.1.

The Project Reunion features were initially slated for .NET 5, but they missed the cut. They’re currently a part of the WinUI 3 library, which is floating in preview limbo.

See also: A deeper look at what’s coming in Project Reunion, eventually.

Fusing mobile and desktop

.NET 5 is a release that brings everything under one big developer tent. That includes the Xamarin technology used for native mobile applications.

But here’s the catch. Xamarin didn’t just use a scaled-down .NET runtime, it also used a different UI model — one based in XAML, influenced by WPF, but still thoroughly its own. In other words, Xamarin is one more awkward island. It doesn’t mesh with Blazor on the web side, or with any of the Windows toolkits on the desktop side.

Microsoft had solution for that, too, called .NET MAUI (for Multi-platform App UI). It’s an evolution of Xamarin that allows you to target mobile Android and iOS platforms, and desktop Windows applications (WPF or UWP), with everything magically bundled into a single project. It might even integrate with the world of standard web applications through Blazor.

For a while, Microsoft was promising that this ambitious change would happen in time for .NET 5, but it eventually slipped to .NET 6. (They specifically blamed the coronavirus for the delay, if you’re looking for another reason to hate 2020.)

The bottom line is that you’re hoping for an easier way to create native applications on a variety of platforms, you’re stuck waiting. Or, you can consider a third-party tool, like the excellent Uno Platform.

See also: A deeper look at .NET MAUI.

Single-file applications

Under the heading of “nice little things that are actually much more difficult than they seem,” Microsoft has been trying to deliver a true single-file deployment solution for quite some time. In .NET 5, they didn’t quite succeed.

The goal of single-file deployment is to package an application and all its dependencies in a single executable file. When you launch the file, the runtime unpacks the resources and loads them dynamically. Simple, right? Not so fast.

It turns out that there are operating system and security considerations that complicate the picture. The solution Microsoft settled on generates a true single-file package that works flawlessly on Linux. But on Windows and macOS computers, you still need to include a few separate runtime files and distribute them alongside your “single-file” executable. Microsoft explains the reasons for this painful compromise here, and plans to revisit the issue again in .NET 6, with no guarantee that the situation will improve.

C# 9 goes functional

As always, .NET 5 also includes updated versions of its core languages, C# 9 and F# 5. The changes in C# aren’t as dramatic as they’ve been in some previous versions (remember the introduction of generics and LINQ?). But they’re still significant.

The most notable changes show C# creeping closer to functional programming, with a new feature for immutable data objects and a more powerful expression syntax.

See also: The functional-programming changes in C# 9.

VB slides into irrelevance

For years, we’ve watched C# go from strength to strength. And now .NET 5 makes it explicit—there is only one core, do-everything .NET language, and that’s C#.

In second place? You must mean the nicely crafted but very niche F#, a language explicitly designed for functional programming. Its most important contribution just might be the way it keeps nudging C# to add more functional features.

As for VB, once the world’s most popular hobbyist language and a side-by-side equal to C#, it’s now little more than a legacy. You can use VB with some older project types, most notably Windows Forms and WPF. (This is an improvement over the non-existent support offered in the most recent version of .NET Core.) But ASP.NET? Not if you want project support and Visual Studio designers. In fact, there’s more ASP.NET support for F# than there is for VB, and C# remains the clear favorite across the board.

Here’s a handy table that summarizes the project support you get out of the box in .NET 5:

This change isn’t all bad. Having extra languages splits the developer ecosystem, and there’s no point encouraging developers to code in VB if the documentation, examples, and .NET communities are all talking in C#. But it’s still a sad ending for one of the world’s most influential languages.

A .NET every year?

Perhaps the greatest success in .NET 5 is that it launched precisely on time. A year ago, its release date was set for November 2020, and the binaries dropped ten days into the month.

This is significant because November is about to become a lot more important for .NET developers. Microsoft has made a long-term pledge of releasing a new .NET version in November, every year. Here’s the current release plan:

In Microsoft terminology, .NET 5 is a current release, which means it gets a limited support lifetime that will end a few months after .NET 6 debuts next year. This is unlike Microsoft’s LTS releases, which have a guaranteed support window of 3 years. The last version of .NET Core (3.1) is an LTS release, and the next version of .NET (6) will be one, too. So if you’re working in a government organization or a large company that needs a stronger support policy, now may be the time to plan with .NET 5, but it’s not the time to deploy.

In the end, the most exciting part of .NET 5 isn’t new tech like Blazor, or its cross-platform support, or even its open-source status. It’s the fact that Microsoft has successfully pulled off a critical reboot. They’ve replaced the aging .NET Framework, revitalized the .NET family, and all-but guaranteed that their programming tools will thrive for another decade.