.NET 5.0 Arrives and Finally Merges Framework With Core

Microsoft closed out its virtual .NET Conf yesterday by shipping .NET 5.0, and this one actually lives up to the “unification” pitch that’s been floated for years. Alongside the runtime, the release brings C# 9, F# 5, a new ASP.NET Core, and EF Core. If you’ve been juggling .NET Framework on Windows and .NET Core everywhere else, that split is now officially going away.

The headline is simple to state and genuinely hard to pull off: one .NET, running on Windows, macOS, Linux, and Arm. For a long time, “which .NET am I even targeting” was a real source of confusion for teams — Framework had the legacy APIs and Windows-only baggage, Core had the modern cross-platform story but wasn’t a drop-in replacement. .NET 5.0 is Microsoft’s attempt to stop making people choose.

Why skip 4.0?

Worth noting: there’s no .NET 4.0. Microsoft jumped straight to 5.0 specifically to avoid confusion with .NET Framework 4.x, which will keep existing as-is but isn’t getting new investment going forward. It’s a small naming decision, but it signals where the company wants your attention pointed.

What actually changed

C# 9 and F# 5 are the language-level updates riding along with this release, and both continue the trend of incremental but genuinely useful additions rather than a big rewrite. ASP.NET Core and EF Core also got refreshed to match, so the web and data-access story updates in lockstep with the runtime rather than lagging behind it.

The cross-platform piece is the part I’d pay attention to if you’re not already on Core. .NET has quietly become a legitimate option for Linux-first shops over the past few years, and having a single runtime target instead of maintaining a mental map of Framework-only versus Core-only APIs removes a lot of friction for teams that support mixed environments — say, Windows desktop tooling alongside Linux-hosted backend services.

It’s also a decent signal about Microsoft’s broader direction: betting on open, cross-platform tooling rather than doubling down on Windows-exclusive stacks. .NET Core already proved that strategy could work; folding Framework into it makes it the default rather than the alternative.

None of this means every existing Framework app should migrate today — there’s real work involved for anything leaning on Windows-specific APIs that didn’t make the jump, and Microsoft has been upfront that some of that surface area isn’t coming along. But for new projects, or for teams already eyeing a move to Core, .NET 5.0 removes the “which one do I even pick” question. The answer is just .NET now.

I’ll be curious to see how migration guidance shakes out over the next few months, especially for larger enterprise codebases that have been on Framework since the WinForms and early WPF days. Unifying the runtime is the easy part on paper; getting a decade of legacy code to actually move is the part that takes years, not a conference keynote.