The Reunification of .NET 5

We’re less than a year away from the final step in .NET’s cross-platform transformation

Matthew MacDonald
Jan 13 · 7 min read
Where the two tracks meet / [Pixabay]

If you build something truly successful, eventually you’ll run into a problem: what do you do when it’s time to replace it?

This was the quiet crisis Microsoft faced in 2014, when it saw its popular .NET development platform eroding against open source competitors. The company that had faced down tech challenges from IBM, Sun, Netscape, Oracle, and plenty more suddenly found itself in a losing battle.

Open source was nothing new in 2014. In fact, it had already existed for nearly two decades. But this was the first time that it felt like Microsoft might be left behind. Up until this point, Microsoft had been able to survive with a combination of strategies. It outcompeted with valuable, proprietary, and often Windows-only features. It hid what it didn’t want to share, and used standardization to expand the reach of key bits of technology, like the C# language. It offered developers a rich toolset, including interop features that could span the gaps between Microsoft’s closed-source technology and open standards. Yes, there had been a few misadventures — most notably Silverlight, the technology that was supposed to kill Flash. (Instead, they died side-by-side when HTML5 took over the web.) But from the outside, it looked like Microsoft had barely lost momentum.

But in 2014, the development world was approaching a tipping point. The enthusiasm was leeching out of monolithic software frameworks and into more nimble, community-backed projects, and the large expanse of Microsoft developer mindshare was melting away at the edges. It was the kind of change that, once it starts, can only gain momentum. Some thought that Microsoft would gradually shrink down to its last impenetrable fortress es— business tools like Excel and Office, intranet applications using technologies like SharePoint and Outlook, and data warehousing with SQL Server.

Then they tried something new.

.NET Core: The paths diverge

.NET Core was a modern, reimagined .NET. It was everything the .NET Framework would be if Microsoft developers were to recreate it from scratch: modular and open source. And it was multi-platform — not just for the people using the applications created with .NET, but also for the developers coding them and the web shops hosting them.

Of course, Microsoft couldn’t rewrite the entire .NET Framework. After all, .NET was a mature product with a fifteen-year footprint of changes and dependencies. And because countless businesses relied on these technologies, Microsoft couldn’t afford to deprecate the .NET Framework. (Even sidelining a relatively small technology like Silverlight had been painful.) So instead, Microsoft pursued a so-crazy-it-just-might-work strategy of offering developers two overlapping development systems. The .NET Framework had all the capabilities and baggage of the past. And .NET Core was a streamlined alternative that looked toward the future

.NET 5: The paths rejoin

Although Microsoft was careful not to call .NET Core the successor to the .NET Framework, it was obvious that the possibility was on the horizon — if they could make it happen. And in 2020, Microsoft is poised to make it happen. They are closing the loop, deprecating the final technologies they couldn’t bring on board, and shifting their entire developer ecosystem to .NET Core — now renamed .NET 5.

Microsoft is currently promising an early beta of .NET 5 in the first half of 2020. The milestone tracking on Github suggests they’re roughly two thirds of the way there:

After .NET 5 is released, Microsoft aims to settle into a regular release schedule, with a new version of .NET every November for the foreseeable future. Here’s their developer roadmap for the next three years:

Of course, there will be plenty of legacy code. The final version of the .NET Framework (4.8) is considered a system component of Windows 10. It’s guaranteed to receive patches and minor fixes for the next five years, and likely to remain supported as legacy software for the better part of the next decade. That means there’s no harm (or shame) in maintaining an old .NET application. But there are tempting rewards ahead of you, if you can make the transition to .NET 5.

What gets left behind

.NET Core was necessarily incomplete. Microsoft has been steadily patching the gaps up through the recently released .NET Core 3.1. However, some bits won’t ever make the jump.

Here’s a quick rundown of what will still be missing when .NET 5 takes over:

  • ASP.NET Web Forms. The web application development that launched with .NET and was one of its most popular features has finally reached the end. ASP.NET MVC is also retired, leaving ASP.NET Razor as the next step in .NET web app evolution.
  • WCF. Windows Communication Foundation is probably the most controversial omission, because there’s nothing that directly takes its place. Modern applications can use the ASP.NET Web API, which provides a far less complicated way to talk over HTTP, but doesn’t support other protocols like TCP or MSMQ. Another alternative for some applications is gRCP. Either way, some serious rewriting is in order.
  • WWF. Windows Workflow Foundation is a runtime for managing long-running workflows that span different applications and services. There’s an open-source project attempting to rebuild the runtime, but it’s likely to remain a tool for specialized scenarios and legacy systems.

There’s a common theme here. Many of the sidelined technologies depended on proprietary technology that’s deeply integrated with the Windows operating system. By removing Windows-only features like WCP, .NET Remoting (WCF’s predecessor), COM+ services, and WWF, Microsoft removes the Windows lock-in factor. It allows .NET to be cross-platform not just in theory, but in the practical life of a business programmer.

It’s also worth pointing out a few features that are making the jump to .NET 5, but still have a big fat asterisk next to their names:

  • WPF and WinForms. These are popular but dated toolkits for creating Windows applications. Microsoft added support for both in .NET Core 3, without proper designers (those will appear in .NET 5). But the bigger caveat is that both features will only work in applications running on Windows.
  • Visual Basic. One of the world’s most famous languages has had its role been dramatically downgraded in .NET. In the first version of .NET, VB was a near equal to C#. In the years since, it’s lost out on new language features and capabilities. In .NET Core 3, VB was sidelined, with no support for creating any type of ASP.NET web application. This gap will be patched in .NET 5, but other details are still likely to be left out. For example, .NET 5 will probably not support the less common parts of VB’s My class, like audio playback.

Looking to the future

The unification of .NET Framework and .NET Core also presents some new opportunities. This is where the story becomes more interesting.

The most dramatic change is that cross-platform .NET applications will no longer need separate toolkits or extra compilation steps. The Xamarin framework, which allowed developers to create C#-powered apps for Android devices, is also joining the .NET 5 fold, along with support for iOS, macOS, and Linux. Those of us who started with .NET 1.0 will remember when running C# code on a non-Windows computer was a fantasy. Now it will be almost seamless.

To make applications work more capably on other platforms, Microsoft is deepening its support for interop with different languages. We’ve already seen hints — for example, the planned C# 8 feature default interface methods that mimics a similar feature in Java. But now Microsoft has promised to expand interoperability with Java, Swift, and Objective-C.

The biggest change is Blazor, Microsoft’s early-beta technology for running C# in a web browser. Right now, Microsoft talks about Blazor as a proof-of-concept for .NET 5’s new LVVM-powered compilation pipeline. But it’s still a bleeding-edge technology that requires a significant investment to adopt. But in the world of .NET 5, Blazor will be just another compilation target. All of a sudden, every .NET developer will have access to a miniature .NET runtime that works everywhere yet requires no deployment. The temptation to use it could transform .NET application development.

That might also be part of the reason that Microsoft hasn’t rushed to update WPF, or create a cross-platform user interface toolkit like Google’s Flutter. If the rich client space stays open, Blazor could become a partial replacement — not for JavaScript, but for the aging, Windows-only WPF.


When Microsoft releases .NET 5 in November 2020 (or thereabouts), it will have successfully pulled off one of the trickiest maneuvers in software development — changing a platform that underpins hundreds of thousands of applications, without disrupting anyone. Even more impressively, it will have finished a transformation of its cornerstone developer technology into a modern, fast-moving, open-source project. The only remaining question is where it takes us next.

For a once-a-month email with our best tech stories, subscribe to the Young Coder newsletter.

Young Coder

Hack. Code. Think. Stories about science, tech, and programming.

Matthew MacDonald

Written by

Teacher, coder, and author of heavy books. Join me at Young Coder for a creative take on science and technology.

Young Coder

Hack. Code. Think. Stories about science, tech, and programming.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade