Upgrading to .NET 5 and the Future of .NET Core

Welcome to today’s post.

In today’s post I will be explaining what.NET Core is, what .NET 5 is, the future of .NET Core, and the upgrade towards .NET 5. I will also explain what .NET Standard is and how it can impact the upgrade path.

I will now explain what each of the above .NET platforms is.

.NET Framework is the platform that provides libraries that are compatible with Windows-based application development.

.NET Core is the platform that provides libraries that are for cross-platform development in Windows, Linux, MacOS, Android etc.

.NET Standard is a set of libraries that are compatible with packages from.NET Core and .NET. The libraries within .NET Standard are base class libraries, which means they are developed to work for all packages and libraries within the new .NET framework. There are two versions of .NET Standard that have been in use since .NET Core, version 2.0 and 2.1. Version 2.0 is supported by .NET Framework, but version 2.1 is NOT supported by .NET Framework.

You may have already used some of the various versions of .NET Core from version 1.0 upwards to version 3.1 and may even have used .NET 5. If you have not used, or the applications you are building or maintaining do not depend on any of the versions before .NET 5, then this discussion probably is not as useful for you as you don’t need to upgrade. But still, I will raise some useful points along the way.

What will happen to .NET Core?

You will have heard about the future of .NET Core. Will it be phased out and die off as a legacy technology? Not any time soon. Read on.

First, you may have heard from various sites or forums from panicked developers that .NET Core has likely died as a platform and is being replaced with a new shiny .NET 5. Let me tell you something that will never be done, Microsoft will not replace the .NET Core platforms and packages or functionality completely with .NET any time soon. The .NET 5 upgrade is the initial release of a unified platform that will include both .NET Core and .NET Framework platforms in one unified platform used for Cloud, Web, Mobile, Windows, and Service based development.

If you are still using .NET Core 3.1, then migration to the .NET 5 platform will allow you to select which of the packages you wish to upgrade to use cloud-based features of .NET 5. In this case, you may be migrating an ASP.NET Core 3.1 web application. The upgrade is to an ASP.NET Core 5 web application. Now, an ASP.NET Core 5 web application is either a Web MVC or a Web API application. Many developers have used ASP.NET MVC version 5, which uses legacy .NET Framework 5. To avoid confusion between the new ASP.NET MVC 5 that uses the .NET Core library and the legacy ASP.NET MVC 5 that uses .NET Framework, the Microsoft platform teams renamed the new ASP.NET MVC 5 to ASP.NET Core MVC 5.

Similarly, if you have used the legacy Entity Framework 5 and 6 versions, the additional confusion would have arisen when upgrading to the new Entity Framework .NET 5.0. It made no sense to confuse developers into thinking that Entity Framework .NET Core 5.0 would be replaced with Entity Framework .NET 5.0 that is based on legacy .NET 5.0 Framework. They made the correct decision to keep the “Core” in the package library name, with the name Entity Framework .NET Core 5.0. This again alleviated confusion from developers that have used versions of Entity Framework Core 1.0 up to version 3.1.

With the above rationale, you should be reassured that the upgrade will migrate Cloud based .NET Core packages into Cloud based packages instead of legacy .NET Framework packages.

Aside from various improvements to the development environment tools, which are explained in the documentation on the Microsoft .NET site.

One of the significant changes is to the improvement in efficient application loading for single file deployment and executable. Single file deployments have been supported since .NET Core 3.0 and earlier versions supported multiple file deployment. The difference between .NET Core 3.x and .NET 5 single file deployment is the way the application loads. With .NET Core 3.x any DLLs that are bundled with the file are extracted into a folder and run from there, whereas with .NET 5 any DLLs are extracted into memory and run from there.

What will happen to .NET Standard?

As I mentioned earlier, .NET Standard, which is the base class library that has been in place since legacy .NET Framework and in use within .NET Core libraries up to and including .NET Core 3.1 will no longer be supported or upgraded with new versions. The new .NET 5 platform and libraries will replace .NET Standard 2.x. In addition, all .NET 5 libraries will be backward compatible with .NET Standard libraries. As with the .NET Core libraries, .NET Standard will reach an end of support data and will not receive service updates. The unified platform of .NET 5 and beyond will replace these two libraries with unified base class libraries.

The diagram below from the article detailing the difference between .NET standard and .NET core gives us a perspective on the purpose of the base class libraries in the context of the various platforms (windows, web and cloud).

I will now explain what libraries are no longer supported in .NET 5.

Application Domains

The purpose of application domains is to isolate code into different processes. The modern alternatively is to use separated containers and processes.

.NET Remoting

The purpose of remoting was used to communicate across application domains. The recent alternatives are Web API services and gRPC. Another less recent alternative is WFC services.

COM+ (Component Services)

The COM+ technology of System.EnterpriseServices are server-based component services, that allow Component Object Model classes to be called within an enterprise domain. Recent alternatives include WCF, Web API services and System.Transactions.    

WCF (Windows Communication Foundation)

Windows Communication Foundation is a technology that is used to allow services to communicate across server boundaries with different channels, bindings, and protocols. The recent alternatives are Web API services and gRPC. 

With the above legacy technologies, none of them can be seamlessly ported over to one of the recent technologies. They would require their code base to be refactored into modules and base libraries before incorporation into the new platforms. In addition, server upgrades may be necessary to use some of the recent technologies.

As I have discussed above, the base technologies behind .NET Framework and .NET Core and not going away or being phased out for a while, they are essentially evolving into another platform that is compatible with the needs of the current computing climate, namely cross-platform computing, cloud computing and distributed microservices computing. Being able to identify your own road map to the new platform libraries when migrating each of your legacy technologies is the key to a successful upgrade.

That is all for today’s post.

I hope you have found this post useful and informative.