⏲ Understand the .NET release cycles and support

It’s hard to believe that two weeks from tomorrow, .NET 5 will be generally available. Week by week, we’ve been poking around the improvements between general .NET, ASP.NET Core and Blazor, and EF Core 5, which are all released together now. While the release candidates offer production licenses, on November 10 things will get real.

To that end, you might be wondering when future releases will occur, how Microsoft is supporting .NET 5, and what that means for older versions of .NET Core and .NET Framework. (This isn’t as sexy as Blazor, I suppose, but is important to understand as you plan your app’s future.)

In terms of future releases, new major releases will be released every November.

As you can see, “LTS” and “Current” support will alternate between releases. As a refresher, let’s walk through those.

Long Term Support (LTS) releases - supported for a minimum of three years (or 1 year after the next LTS ships, whatever is longer). The current LTS releases are .NET Core 2.1 (with end of support on August 21, 2021), and .NET Core 3.1 (December 3, 2022).
Current releases - supported for 3 months after the next major or minor release ships

.NET 5 is a “Current” release. Typically, you’d have three months to upgrade to 5.1 but Microsoft says they’re no longer doing point releases. When it comes to .NET 6, it’ll be LTS (supported for three years after general availability)—giving you a less hands-on approach. There’s a Twitter discussion on the benefits and drawbacks.

Microsoft has published an official .NET 5 support policy if you want to explore this further.

What about .NET Framework? While .NET Framework is not dead, it’s basically done. All new features will be built on .NET Core. With .NET Framework 4.8 being the last major release for .NET Framework, it’ll only be supported with reliability and security fixes. You aren’t being forced to move .NET Framework apps to .NET Core, and there are no plans to remove .NET Framework from Windows, but you won’t see any feature improvements.

🔨 AWS open-sources .NET Core migration tool

This week, Amazon Web Services (AWS) open-sourced their Porting Assistant for .NET tool, which assists you in porting your .NET Framework apps to .NET Core on Linux. It was first released in July.

AWS says their differentiator is assessing the entire tree of package dependencies and functionality like incompatible APIs—it uses solution files as the starting point, preventing the need to analyze individual binary files. Interestingly, this single tool appears to be more robust than Microsoft’s migration tools.

This begs the question: what does Microsoft offer? For their part, Microsoft has a comprehensive document about migrating from .NET Framework to .NET Core. They also have a list of tools you can utilize.

The .NET Portability Analyzer, which analyzes your code and provides a report about how portable your code is between Framework and Core
The .NET API Analyzer, a Roslyn analyzer that detects compatibility in cross-platform libraries
The Platform Compatibility Analyzer, another Roslyn analyzer that informs devs when using platform-specific APIs from call sites where API might not be supported
A try-convert utility, a .NET Core global tool that helps convert from the project.json model to the .csproj model. Microsoft makes clear it is not supported in any way.

It reminds me of the old American football adage: if you have two quarterbacks, you have none. I’ve heard a common question: shouldn’t Microsoft be leading this charge since … they own .NET and are the most familiar with the platform? Why haven’t they invested in robust migration tooling? I see a few factors at play here.

Considering .NET is a free product, the Microsoft play is to get you on Azure. What’s to prevent you from using their awesome conversion tool and heading over to the competition? From AWS’s standpoint, they’re quite incentivized to do this: the sell for .NET devs is hard enough and they need to make things as easy as possible. If you couple that with the complexities of this tooling, Microsoft seems to be a little leery of making any big investments in that space.

📓 An update on ASP.NET Core feedback for .NET 6

A few weeks ago, I wrote about the GitHub issue you can visit to chime in on the future of ASP.NET Core for .NET 6. I’d like to call out a comment by Muhammad Rehan Saeed that outlines core ASP.NET issues that aren’t Blazor related.

While Blazor is awesome and the future of ASP.NET Core, there are tons of ASP.NET developers who aren’t using it for various reasons and are fine with using MVC or Razor Pages. If you’re interested in providing feedback on those issues, look at Muhammad’s comment—personally, I’m interested in HTTP/3 support, streaming API support for MVC, and C# 8 nullable reference type support.