As 2020 came to an end, Microsoft announced their .Net 5 release along with a fixed schedule for release and support for future updates and EOLs.
Going forward .Net, .Net Core, and Xamarin will be consolidated during the .Net 5 to .Net6 wave. This is likely to make the development process for Mobile, Web, and Desktop with .Net much more unified and easier. Here are some of the major highlights from a fairly beefy update:
- .Net now supports single file applications that don’t necessitate for .Net to be on your machine. Now you can compile .Net in your application and get a small single file that you can copy to any machine.
- One .Net means one SDK for mobile, web, desktop, and console.
- Native support for ARM64 in .Net core
- Smaller containers than ever before
- Cross-platform Native UI
Migration Plan
As with any migration plan, first and foremost you need to be aware of everything that is not making it to the upgraded version. Earlier Core 2.0 borrowed some technologies from the .Net framework, that’s not the case with newer versions. Rather some things may be skipped in the new version for some technological reason or the other.
- AssemblyLoadContext is replacing app domains, as the latter is quite an expensive runtime feature and not suitable for modern app development.
- Remoting is being replaced by named pipes and gRPC
- WebForms is being replaced by ASP.Net Blazor
- WCF Server is being replaced by gRPC and Open source CoreWCF
- WF is being replaced by Open source Corewf
How to Migrate your project to .Net 5
1. Ask if and why you need to migrate
The first step in migration is to understand the feasibility and goals for migration. No need to be over aggressive with the migration because .Net is not going anywhere. If you’re happy with how things are, then there is no need to migrate as .Net is part of Windows and is bound to get fixes for a considerably long period.
On the other hand, if you want to innovate and leverage new features and technologies then .Net 5 is the way forward. Your migration approach will also depend on your choice of Operating System. If you’re sticking with the existing one or shifting to another.
Pro Tip: Ensure that you have backups along the way so you can still ship working software. It’s futile to port in a big one-off migration. While it might work for small projects, not so much as your projects get bigger.
2. Analyze your app
Having worked months, even years on an app, one might think that they know the app inside out. It might be true for simple apps but in the case of complex projects, it’s easy to overlook obsolete things that might add to the difficulty of an already grueling undertaking. Things to keep in mind while auditing your app:
- Use ApiPort to list outcode and its dependencies.
- Legacy code can be a pain to carry forward. Analyze legacy code for feasibility if it seems obsolete and expensive to refactor then consider dropping before the port.
- Analyze dependencies and ensure they have support for .net 5. If they are not supported then consider moving to modern alternatives before porting.
3. Convert Project
After understanding the needs for the port and deciding to ahead with it, you’ll need to convert your project. Conversion typically involves:
- Replace packages.config with<packageReference> elements in the project
- Another option would be to use Try-Convert to automate the process to migrate the project files to SDK style
Pro Tip: Consider only migrating the project files without changing the target framework as you’ll need click stops for big projects in case of unexpected downtime
There are some limitations to Try-Convert method
- It can’t convert some project types like ASP.NET and Xamarin
- It doesn’t migrate any source code (*.cs), only project files(*.csproj)
4. Time to make the move
Replace the target framework string in the project file from the existing version to .Net 5. As stated earlier avoid moving everything at once you would want to start from the bottom with reusable libraries and make your way from there.
Additionally, identify if you have shared components that need to continue to work on the existing .Net framework. Retarget those to .Net Standard and then retarget remainder to.Net 5.0
5. If you want to move to another OS
When you’re looking to change your operating system, ensure that you use a CI environment that can run your code in multiple operating systems. Azure DevOps, Github actions, etc.
And last but not least, run tests to ensure that everything is working as expected.
There are a lot of moving parts in an enterprise .Net project, and the scope for mistakes while porting is immense. It’s not a question of expertise but of time and resources. While the automated tools might make the process less of a pain but you’d still have to engage resources to make time-consuming changes in the source code.
Currently handling numerous .Net projects, a few of which are under migration, Galaxy provides the needed expertise and resources to make the migration smoother with zero downtime.
Contact us now for a free consultation on your .Net project.
