Should You Skip .NET 5?


Crista Perlton

Crista Perlton


Are You Safe from Malicious and Vulnerable Python Packages? 16th September, 2022

PyPI Package Dependencies and Their Unintended Consequences 03rd May, 2022


Should You Skip .NET 5?

Posted on .

.NET 5 is “.NET Core vNext” and is the exciting future of .NET development. But switching to .NET 5 right away could be the wrong choice. Unlike previous major version updates in .NET Framework (like 4.0), you can probably sit this one out and wait for .NET 6 or even .NET 8.

.NET 5 is Microsoft’s shiniest, newest .NET. But brand-newness means new problems, unknown quality, and other question marks. And nobody has time for that.

The good news is you can wait to use the new .NET until .NET 6 or even .NET 8.

This article explains exactly why waiting is not just okay but is probably your best bet.

The Jumpy, Bumpy History of .NET Releases

Mono, Standard, Framework, Core, and now 5+. It’s enough to make your head spin. .NET is the David Bowie of development platforms: Each new .NET is often a total reinvention of past platforms.

They may all be called “.NET,” but the different .NET platforms (Framework, Standard, etc.) are often too different to be cross-compatible. For example, .NET Framework is different enough from .NET Core that, unless they’re multi-targeted, NuGet libraries can’t be shared between them.

Complicating things further: even different major and minor versions of the same .NET platform can be different enough to cause serious complications. For example, the difference between .NET Framework 1 and .NET Framework 2.0 introduced many breaking changes that made the migration very difficult for users.

Not complicated enough? Sometimes even “patch” releases—releases that are only supposed to be minor bug fixes and security updates—can create multiple breaking changes that mess up your code (Those of us who remember the release of .NET Framework 3.5 SP1 are having flashbacks of this.)

.NET 5+: A Whole New .NET

.NET 5 marks an entirely new .NET platform that Microsoft has created, theoretically, from the very best the other .NET platforms offered, plus new features not yet before included.

According to Microsoft, “With .NET 5, your code and project files will look and feel the same no matter which type of app you’re building.” .NET 5 is .NET Core rewritten to emphasize side-by-side installs, not being a component of the Windows OS, and cross-platform development. And, of course, the new .NET path benefits Microsoft by being a single, unified platform to maintain.

What This Means for You

When it comes to Microsoft’s .NET, you must always keep two things in mind:

1. Think of Microsoft’s version numbers as just names, rather than strict “versioning.”

General best practices for version naming follow Semantic Versioning 2 (SemVer2), indicating the “severity” of a release by the numbers in its name. Big, breaking changes are usually a new major version (like the proverbial “2.0” version of something being reinvented).

Release TypeDescriptionExample
MajorThe change will be incompatible with previous versions1.0.0
MinorAdd functionality while being backward-compatible1.1.0
PatchBackwards-compatibly fixes bugs or patches security1.1.1

By this logic, .NET Framework 3.5 SP1 should have been .NET Framework 4, since it created so many breaking changes. But it was numbered as a patch. Thus, it’s much better to assume that Microsoft’s .NET numbers are names, rather than strict versions.

2. Let your application lifecycles guide decision-making.

These are pieces of software, not “the latest fall fashions” that will be out of style next year. Changing .NET just because there is a new platform available is NOT a good idea, as most of your applications will continue to run just fine on the .NET platform they already use.

The lifecycles of older .NET platforms —especially the most recent .NET Framework—are so long that there is often no compelling reason to use another .NET until the 2030s.

As this table from our article on long-term support shows, .NET releases starting with .NET 5 will not only have a shorter time between releases but even the long-term support versions will have substantially shorter lifecycles than older versions. It is a waste of time and adds unnecessary risk to switch an application that uses a perfectly functional .NET Framework version over to .NET 5+.

Simply put, Microsoft’s .NET versions are really names and the lifecycles vary widely. You cannot assume that the jump from .NET Framework etc. to .NET 5+ will be any harder than past updates, just because it’s a major version number change.

In fact, there will be only three years (and likely fewer breaking changes) between .NET 5 and .NET 8, while there were almost five years between .NET Framework 4.5 and 4.6.

Why You Should Skip .NET 5

Switching to a different .NET platform always takes effort. Because it is almost a page-one rewrite of .NET, there are untold opportunities for problems in .NET 5. You can minimize the impact of these problems by waiting.

By waiting for .NET 6 or even .NET 8, you benefit from the improvements that will come from .NET 5’s unforeseen bugs and problems. And the even-numbered .NET 5+ releases are long-term support, so your applications using .NET 6, 8, 10, etc. will have a longer lifecycle than the short life of .NET 5, 7, and so on.

Furthermore, waiting gives you time to assess whether you will ever have to use a different .NET platform. Some of your applications will reach their end-of-life before their .NET platform stops working (like many ASP.NET Web Forms applications, for example). Sometimes the best choice is to abandon old libraries and applications once they are no longer useful to you, rather than trying to adapt old stuff for the future. Instead, wait to rewrite the application “from the ground up” when the time comes—just like Microsoft did with .NET 5+.

Why and When You Should Use .NET 5

There are definitely good reasons to use .NET 5, the most obvious being that eventually everyone will have to use some form of .NET 5+.

Consider “beta testing” .NET 5 at your organization: If you have developers eager to give the new platform a try, assign them low-risk applications they can use with .NET 5. An experiment like this is low-stakes and high-return, giving you valuable information without much expense or risk.

Testing .NET 5 on some of your lower-risk applications gives you a preview of the difficulties you may face when the time comes to use new .NET platforms. That time may come sooner than later if you plan to take advantage of .NET 5+’s central features, like being cross-platform.

It’s Really OK to Wait

Remember that Microsoft’s “version numbers” are just names. Going from .NET Framework 4.5 to .NET 8 may make you feel anxious, being a jump of almost four major versions. But in fact, .NET 8 will be more similar to .NET 5 than .NET Framework 4.5 is to .NET 5. The jump is much less intense than it might seem.

The new release cadence and LTS versions should guide your decision-making as you assess your applications’ lifecycle stages to plan for the future. Start learning and planning today for how you will modernize your applications over time.

Learn and Plan with the .NET 5 Migration Guide

We’ve built a guide on how to successfully migrate to .NET 5+ so you can make the best decisions for your organization’s applications. Get your free copy today!

Crista Perlton

Crista Perlton