March 3, 2022
Using Postman with SignalR WebSockets Development
.NET 5 has been available for some time now and .NET 6 will be released in late 2021, but perhaps your team is still using .NET Framework 4.7 or 4.8. You may have preferred to stick with what your team knows, or with the time-tested platform that has been around for decades, but .NET 5 presents a compelling case for those who haven’t made the jump yet. And while it may seem like a small jump in version numbers from 4.x to 5, .NET 5 is a major leap from .NET 4.x and a continuation of the all-new framework that started with .NET Core 1.0 through .NET Core 3.1 and is now the future for all .NET development.
Some of the benefits of migrating to .NET 5:
Depending on the size of your application, this may be a larger undertaking than any framework upgrade you’ve done in the past, but it also holds greater potential for performance improvements than any prior .NET Framework upgrade. We have helped many clients make this migration, and we have refined the process to make it as painless as possible. Every project has its own constraints and dependencies, so your migration process may be slightly different and require additional steps, but most our .NET 5 migrations follow these steps:
The first step in the migration is to analyze your current application to determine the amount of effort to expect when migrating to .NET 5. The .NET Portability Analyzer is a free tool that will analyze your assemblies and provide you with a report of APIs in your current application that are no longer supported. There is typically a path forward for code that uses APIs that are no longer supported, but these changes will require more effort than supported APIs that can easily be shifted to the new version of .NET.
Evaluate dependencies between projects and determine whether to upgrade library classes to .NET Standard or .NET 5. If all projects are being upgraded to .NET 5, then all projects can target .NET 5. In the case where you need to leave a project in .NET Framework and that project needs to reference an upgraded class project, you will need to target .NET Standard 2.0 instead of .NET 5. Refer to the .NET Standard implementation support page to determine what versions of .NET and .NET Standard are compatible with each other.
Class libraries are typically the easiest project types to convert. If they do not have any compatibility warnings in Step 1, it is very likely that you will be able to simply migrate all of the existing code to the new project structure. Before you start converting projects, ensure that you have the desired version of the .NET SDK installed.
When you are ready to migrate your projects, you can start with the Try Convert tool to see if your entire solution or individual projects can be migrated automatically. If that does not succeed, or if you want to convert them manually to have more control over the process, you can take the following approach:
dotnet new classlib -o <ProjectName>
There have been a lot of changes to how .NET Core and .NET 5 initialize and run ASP.NET projects, so this step tends to be more involved than migrating class libraries.
Similar to Step 3, you may be able to automatically convert your entire solution or the ASP.NET projects with the Try Convert tool. But if it does not succeed, or if you want to perform the conversion manually, you can follow these steps:
usingstatements to account for changed namespaces in .NET 5.
If you are using an older version of Entity Framework, this is a good time to at least consider whether you want to migrate to Entity Framework Core 5. Because there are significant changes between EF 6 and EF Core 5, Microsoft refers to this as a “port” rather than a “migration” and it is worth reviewing all of their considerations on the Porting from EF6 to EF Core page. If you do port to EF Core 5, you should plan to test your application to ensure it works and performs as expected. Some queries may need to be adjusted to align with how EF Core handles joins and split queries, and some aspects have changed that will need to be restructured, such as complex Group By queries.
Moving to EF Core 5 does have its advantages, and similar to the rest of the .NET 5 platform, every release adds new capabilities and performance improvements.
If you decide to move to EF Core 5, the typical migration steps are:
Add-Migrationto create a new starting point for future updates and migrations.
If you are already using Dependency Injection, you can likely continue to use the same DI framework. If you are not using DI at all, the migration to .NET 5 provides the perfect opportunity to start using the built-in Dependency Injection framework. Even if you are using a different DI framework, it may be worth considering making the switch to .NET Dependency Injection because of its excellent performance, and since it is a first-class citizen in .NET, it is very easy to adopt and use.
Similar to EF Core and DI, the migration to System.Text.Json for serialization and deserialization is an optional migration. If you are using Newtonsoft.Json currently, there won’t be complete feature parity in System.Text.Json, so it is worth reviewing the differences outlined here. But if System.Text.Json does provide all of the features you need, it is likely that you will see performance improvements by making the switch.
Here are our typical steps for migrating to System.Text.Json:
Making the move from .NET Framework to the latest .NET platform can be a large effort, but it certainly has its benefits. Along with the immediate performance gains, you will once again be on the current .NET platform that will continue to improve over time.
We have helped many clients make this migration, so let us know if we can help!