.NET is Dead, Long Live .NET

Microsoft has already said that .NET Core is the future of .NET, which means if you haven’t started, you’ll need to start migrating your existing .NET Framework applications to .NET Core. We’ll go over a few reasons to be excited about this change as well as how to get a head start on the move. 

In a world of evolving developer tooling, frameworks, and trends, Microsoft has an amazing track record of supporting the .NET ecosystem and the entire suite of products accompanying it. This is why the path that they have decided to take with .NET is surprising and a little welcomed. If you haven’t heard, .NET 4.8 is going to be the last release of the .NET Framework. The next release after .NET Core 3.0 will be .NET 5.0, which means that .NET Core will take on the mantle of .NET. One of the major goals of .NET Core has always been to unify the framework into having a single runtime that behaves similarly on all platforms.

With this announcement, Microsoft will be making two big steps, one of them planned and the other not so planned. The planned step is having .NET Core become the successor to the .NET legacy. The other step, which will be a little shakier, is the lack of 100% backward compatibility between .NET 5 and .NET 4.8. (At the time of this writing, Microsoft has committed to getting as close as possible to API parity in .NET 5.0).

We will go over some of the benefits to this announcement and how to get ready for this change if your codebase is still working with .NET Framework 4.8.

Benefits

The biggest upsides to this announcement are that .NET Core is the future and here to stay, as well as some performance improvements.

The future of .NET is open source and boundless. While .NET has been spreading to other platforms via Xamarin and Mono, .NET Core represents a unified approach to their cross-platform push. Along with the cross-platform unity, Microsoft is pushing heavily toward open-sourcing much of their code as well. By open-sourcing .NET, it has changed the licensing and hosting costs associated with choosing .NET and opens up the playing field for startups and developers who aren’t thrilled about “startup” languages. Another notable mention is that Microsoft has had the rare opportunity to rewrite their language with all the benefits of hindsight and practical real-world usage. They have definitely not wasted this opportunity either; they have made some noticeable improvements to .NET Core which you’ll be able to take advantage of as you migrate.

Most notable, they have introduced Span and Memory, which are contiguous allocations of memory that live in the stack and allow for faster operations than existing arrays. The concept is pretty simple, but the devil is in the details. They are available for everyone to play with, but just know that Microsoft has rewritten some of its internal APIs to take advantage of the performance enhancements, so you won’t have to learn all the nitty-gritty to get advantages from them.

Beware the Non-Starters

Before we jump into preparing for migration, there are some non-starters that, if you fall into these categories, you may need to rethink your current solutions or potentially dig into the .NET Framework for the life of your project.

At this time, there are no plans to implement these in .NET Core.

Non-Starters

• AppDomains
• Remoting
• Code Access Security (CAS)
• Security Transparency (Silverlight)
• System.EnterpriseServices

Steps to Get Ready for Migration

I’ve given a few reasons to get excited about the future of .NET, some caveats for whether this migration appropriately applies to your needs, and now we need to make some changes to our existing codebases to get ready for the next release.

Microsoft has done a good job of building out a set of tools to help with the migration.

Step 1. Set your project to target .NET Framework 4.7.2

The first step may seem like a step backward, but you’ll want to set your project to target .NET Framework 4.7.2. Microsoft recommends using 4.7.2 since this gives you the availability of the latest API alternatives for cases where the .NET Standard doesn't support existing APIs.

You’ll notice that I casually tossed out .NET Standard without going into much detail. .NET Standard is a formal set of APIs that are intended to be available on every .NET implementation which will allow you to seamless migrate to .NET Core from .NET Standard.

Step 2. Run Your Code through .NET Portability Analyzer

After ensuring that your code is targeting .NET Framework 4.7.2, it is time to run your code through the .NET Portability Analyzer (ApiPort) to determine how much work would be required to port your .NET Framework codebase to .NET Core, .NET Standard, ASP.NET Core, NET Core + Platform Extensions, or .NET Standard + Platform Extensions. This tool is versatile since you can use it to analyze your codebase with several different options. It allows you to specify the versions and get very granular with the recommendations.

If you happen to be using C#, you can use the API Analyzer to help analyze your code. While this tool is useful, it is not specific to porting your codebase to .NET Core — it definitely falls into the more general category of tooling that happens to track down obsolete code, but it can track down some portability issues.

Step 3. Implement Your Plan for Porting

At this point, you have a good idea of the scope of work required for moving your codebase to .NET Core or at least a potential path forward once until your compatibility issues are resolved. As you start porting, there are two techniques that you can use to make progress. The first would be to copy your code into a .NET Core project and pick a version of .NET Standard that you want to target and reference your ApiPort references on what changes need to take place, along with pulling down the necessary NuGet packages. The second option would be to modify it in place. The best approach is really based on your code and what works for you.

Step 4. Test

If you were able to port over your code, the next steps would be to run your unit tests against the migrated codebase to ensure that they are working. There are only three unit test libraries that run on .NET Core: MSTest, xUnit, and NUnit.

Wrapping Up

Hopefully, you are as excited about the future of .NET as me and feel like there is a path forward for your codebase to .NET 5.0. Happy Coding!

Read More

With Microsoft heading in this direction, the entire ecosystem is going that way too (our own Telerik UI for WinForms/WPF/Reporting already supports .NET Core, for example). Check out this related content to dig deeper into what's coming:

• How to Port Desktop Applications to .NET Core 3.0
• 3 Ways to Deploy a WinForms or WPF .NET Core Application
• Bring Your WPF and WinForms Apps to .NET Core 3 with Telerik UI for WPF and WinForms

Editor's Note: This post originally appeared on our Telerik blog. Check it out for the latest news on .NET and JavaScript developer tooling.