Migrating legacy projects to .Net Core/Standard



Introduction

After the second version of .NET Core, it is pretty likely to be the future for .NET development, at least for many years. Luckily for legacy projects, Microsoft still continues supporting .NET Framework and developing new versions, such as .NET framework 4.8, which currently available as early access https://github.com/Microsoft/dotnet-framework-early-access. Even though, .NET Core provides some benefits that might be considered to port your legacy projects from .NET Framework to .NET Core. According to this article Choosing between .NET Core and .NET Framework for server apps, these are the points that you should consider to choose between .NET Core or .NET Framework:

Use .NET Core for your server application when:

  • You have cross-platform needs.
  • You are targeting microservices.
  • You are using Docker containers.
  • You need high-performance and scalable systems.
  • You need side-by-side .NET versions per application.


Use .NET Framework for your server application when:

  • Your app currently uses .NET Framework (recommendation is to extend instead of migrating).
  • Your app uses third-party .NET libraries or NuGet packages not available for .NET Core.
  • Your app uses .NET technologies that aren't available for .NET Core.
  • Your app uses a platform that doesn’t support .NET Core. 

So as conclusion, use .NET Core if you can, because there are more benefits. For this reason, if you start a new project you should consider .NET Core as first option. But, what happens with legacy projects? According to the previous article, they recommend extend legacy project with .NET Core, instead of migrating. However, I would say "it depends on the project". Calculate the cost of migrating and then decide, because using .NET Core will be rewarding in the long run if it is possible to migrate your project easily.

In addition, if you have some cross-cutting infrastructure libraries shared by your different services, you should consider a migration to .NET Standard for those libraries, so new micro-services or projects will be able to use .NET Core. Remember you can make your libraries compatible with .NET Framework and .NET Standard at the same time, which can be very handy to support legacy and new projects.

Migrating analysis for Legacy Projects to .NET Core/.NET Standard

To illustrate how we can analyze the migration of a legacy project to .NET Core/Standard, I will use a DDD example project shared as open source on GitHub: https://github.com/sandipray63in/DDD-Based-Enterprise-Application-Framework

In order to analyze the migration of a legacy project, we can use a very useful Visual Studio extension called .NET Portability Analyzer. You can download this extension here: https://marketplace.visualstudio.com/items?itemName=ConnieYau.NETPortabilityAnalyzer.
After installing .NET Portability Analyzer, we can configure which parameters we want to analyze in or project. To do so, right click on your solution and you will see a new option "Portability Analyzer Settings".

 

 In Options window, you can set up your settings, depending on the analysis you want to generate. 


Now, in right-click menu, select "Analyze Assembly Portability" and after a few seconds (depending on the size of your project), you will have a new report. For the DDD project example, we can see we have a very high rate of compatibility with .NET Core. The project more problematic would be RestfulWebAPI with a 74.95% of compatible code.  



In the second tab of the report, we can see the details of the compatibility problems that we have, so we can see the assemblies with classes and namespaces not supported by each platform.


Considering this report, we should have an estimation of the different incompatibilities of our project to migrate it to .NET Core/Standard. Depending of the incompatibilities, we should see if we have a similar functionality in .Net Core/Standard or we have to change our source code, which would involve extra work.


I hope you found this post useful.

Happy conding! :)

Comments

Post a Comment

Popular posts from this blog

Building Micro-Frontends with Single-Spa

Image
Introduction Micro-services architecture is becoming trendy since it is a suitable option many projects, specially those that are complex and we want to be able spilt our business logic into different services that can be built and deliver independently. In spite of the fact that micro-services architectures are more complex, they increase the resilience of your system and increase the time-to-market delivery, which can be crucial for many companies. But it is not all about services and backend. With the introduction of single page applications (SPAs), we can build fully-functional user interfaces that can work independently in the browser. And here we should ask ourselves the same questions as for backend applications: Is my SPA becoming a huge monolith? Would I like to deliver functional modules independently? If you using micro-services, is there a relation between my services and your UI? Do we want to have functional teams that can deliver new features (frontend+backend) independe...
Read more

AWS assuming role + MFA with pulumi (and other applications)

Image
Introduction In AWS, managing your IAM in a centralized account is a good practice, so then you can assume a role to access to other accounts without need of duplicating users. You can find more info about this approach in this article . In addition, for security reasons, it is highly recommended to enable MFA (Multi-factor Authentication), so you need a device to generate a temporary code to get access. In the image below it is showed how assume role with MFA works, but you also have an article about MFA in this link . This approach is really useful and most of the configuration can be automated with pulumi (or other providers like terraform or CloudFormation). And once it is configured, you can switch your role and get access to other accounts with a few clicks.  However, when it comes to external software such us pulumi, getting access assuming a role and using MFA might not be too straightforward. In this article we will see how this can be configured and how we can easily refr...
Read more

Managing snapshots for Amazon ElasticSearch with Dotnet Core Lambdas

Image
Introduction It is awesome to have some useful services like ElasticSearch managed by AWS , so you don't have to care about patching, monitoring, etc.  When it comes to backup management for indexes, Amazon ElasticSearch includes automated snapshots. Automated snapshots are only for cluster recovery. You can use them to restore your domain in the event of red cluster status or other data loss. Amazon ES stores automated snapshots in a preconfigured Amazon S3 bucket at no additional charge. In particular, if you are using a higher version than 5.3, Amazon ElasticSearch takes hourly automated snapshots and retains up to 336 of them for 14 days. However, this policy might not be enough if you need to keep your snapshots for a longer 15 days, or you need to take a snapshot to create a new cluster in another region, subnet, etc. If you have different requirements to manage your snapshots, you will have to work with manual snapshots. For this part, AWS does not offer a good managed exper...
Read more