.NET Framework to .NET 6 Migration - FinTech Product

While implementing a solution, the thumb rule is to finish it as soon as possible. Because the product is already live and they are doing continuous enhancements and bug fixes into the same. So, I need to apply a solution which requires minimal code changes and lesser efforts. So, we go with the following:

• Implementing Dependency Injection : Previously, they created all the classes and created instances of the classes on other classes as per their need. So, created proper interfaces and used contractor based injection in most of the places but in some places where facing issues of circular dependency. For class libraries, create a Register method and put all the dependency registrations into that method. Later, I called that method from the API project’s dependency registration class.
• Used Extension Methods and base classes to minify the code changes : We created many custom extension methods of the method due to changes in the calling structure of the method which exactly looks the same like .NET framework. So, in the existing code base, changes are implemented by importing the required namespace. Similarly, in the .NET framework, all the API controller classes are extended from APIController but in .NET 6 it is extended from ControllerBase. So, we created custom APIController classes and extended it from ControllerBase. In this way, you don't need to change the base class into all controllers.
• Migrate Database First to EF Core : As EF Core does not provide database first entity framework support, we have to use the migrations toolkit provided by Microsoft. Using that toolkit, it provides several CLI commands. By running those commands, the database is updated / created with the model we have. After done with migrations, we manually written migration script for all of our stored procedure because it does not natively support automatic migration generation for stored procedures that were created in Entity Framework 6 (EF6) database first projects
• Finding alternatives of System.Web namespace : closest alternative of system.web namespace is Microsoft.AspNetCore. So, I need to replace that class. But not only that, found following alternatives for essential items:
  • ASP.NET Core : We transitioned it from System.web for web-related functionality, to ASP.NET Core. It provides a modern, cross-platform framework for building web applications. ASP.NET Core includes features for handling HTTP requests, routing, authentication, authorization, and more.
  • HttpContext : The HttpContext class in ASP.NET Core provides similar functionality to the HttpContext class in System.Web. We accessed it within controllers and middleware to work with the current HTTP request and response.
  • Hosting : The Microsoft.AspNetCore.Hosting namespace provides classes and interfaces for hosting ASP.NET Core applications. It includes the IWebHost and IWebHostBuilder interfaces, which are used to configure and start the web host. We used IWebHostBuilder as a replacement for Server.MapPath of the .NET framework.
  • HttpRequest and HttpResponse : In ASP.NET Core, we used HttpRequest and HttpResponse classes from the Microsoft.AspNetCore.Http namespace. These classes offer similar functionality to their System.Web counterparts.
  • HttpClient : We replaced System.Net.Http.HttpClient class for making HTTP requests, with IHttpClientFactory interface.NET Core because it has following benefits:
    • It is a bit easier to mock the request while writing a unit test case and adds logging for all requests sent through clients created by the factory.
    • Naming and configuring logical HttpClient instances.
    • Build an outgoing request middleware to manage cross-cutting concerns around HTTP requests.
    • Integrates with Polly for transient fault handling.
    • Avoid common DNS problems by managing HttpClient lifetimes.
    • Adds logging for all requests sent through clients created by the factory.
• Fetching configuration from AppSettings.json : In order to fetch the configuration from appsettings.json, we implemented the IOptions pattern. First we are going to create the custom class which contains all the properties which are required in configuration. After that, in program.cs or supported extension class method, we are registering it. So, whenever we need, we can directly inject it using DI. It means, we are only reading configuration from appsettings.json at application startup and use it anywhere we need because it is present in the memory.
• Implementing Middleware : Same way created many other middlewares to fulfill the many other requirements. Some of them are as follows:
  • Authentication and Authorization : Created middleware t o handle authentication and authorization in web applications. It can intercept incoming requests, verify user credentials, and enforce access control policies before allowing access to protected resources.
  • Error Handling : Created exception middleware to handle all the exceptions in a single central place and logged those exceptions to the database as well as logged into the Azure monitor.
  • Request and Response Transformation : Created middleware which is used for adding checksum parameters and validates the checksum parameter. If matches then proceed further else return appropriate response.
  • Request Rate Limiting : Created middleware which can enforce rate limits on incoming requests to protect the application from abuse or denial-of-service attacks. They can track request counts per client IP address or user and reject requests that exceed predefined limits.
  • Security Headers : Created middlewares which can add security headers to the responses of web applications to enhance security. We included security headers like Content Security Policy (CSP) and Strict-Transport-Security (HSTS).
  • Request Filtering : Created middlewares which can inspect incoming requests and apply filtering rules based on specific criteria. For example, they can block requests containing malicious or unwanted content, filter out requests with specific query parameters, or enforce request validation rules.
• Serilog implementation : We created our own implementation of Serilog Sink to implement Azure Monitor with it. Reason behind implementing Serilog is it has multiple Sinks based on certain conditions. If we wanted to write log some other places we can do it easily and Azure monitor because it has Kusto query. Based on that we can write our custom query and fetch the logs whenever we need. Based on that, we integrated Grafana to show logs in graph format. Due to that, monitoring becomes easy as well as we can create our custom alerts based on our custom Kusto query and send notifications via an email or message, etc.
• Azure KeyVault Implementation : We have securely relocated sensitive information such as connection strings, API keys, ClientId, and ClientSecrets of banks from the web.config file. This approach ensures that the secrets are automatically versioned within Azure KeyVault, eliminating the need for manual updates. To incorporate these, we need to store ClientId, ClientSecret and baseUrl of Azure KeyVault into our code base or database, in the encrypted and base64 encoded way. By adopting this method, we have effectively removed secrets from our code base, enhancing security and maintaining better separation of concerns.
• Properly Implemented Inheritance : To achieve proper inheritance and reduce repetition, the code has been refactored by implementing base classes. These base classes contain common properties and mapping logic for third-party API models, stored procedure parameters, ADO.NET DataRow mapping, and other objects. Additionally, base repository and service classes have been created to consolidate commonly used non-public methods. By organizing the code in this manner, the common functionality can be reused without duplicating it throughout the codebase.
• Centralized API calling mechanism : We have implemented a generic helper method that facilitates making API calls with any method, and allows the API to return various types of content. This approach offers several benefits, including a single point of control for managing common operations. For instance, we can securely log all request and response parameters, ensuring the protection of sensitive information such as personally identifiable information (PII) and payment card industry (PCI) data. Additionally, we have integrated a quick retry mechanism using Polly to handle situations where the API returns an invalid response. This ensures robustness and improves the reliability of our API calls
• Generic Filters : Building upon the advantages of properly implemented inheritance, we have leveraged it to create generic filters that accept a type parameter, ensuring it is extended from a specific base class. This approach offers several benefits, including the ability to write conditions and validations on common parameters easily. By moving the model-specific validations into the respective model classes, we can override the method defined in the base model and perform the required validations inside them. This simplifies the implementation, as we can now simply call the overridden method to perform the necessary validations for each specific model.
• MassTransit Implementation : In order to fulfill the use case of conditionally switching between various message brokers, MassTransist is the best fit for the same. This ensured high availability, fault tolerance, and message durability. By adopting MassTransit, we gained numerous benefits. Firstly, MassTransit provided a centralized and flexible messaging infrastructure, enabling decoupled communication between services. This resulted in improved scalability, as services could be added or removed without impacting the overall system.
• Migration from Newtonsoft.Json to system.text.json : We initiated the migration process with careful planning and execution, successfully replacing all references to Newtonsoft.Json with the native System.Text.Json library. The migration delivered substantial performance enhancements, reduced memory usage, and improved compatibility with the latest .NET Core platform. We capitalized on this opportunity to optimize our JSON processing practices by leveraging the advanced features of System.Text.Json. The seamless integration with Microsoft technologies and frameworks ensured a cohesive development experience and long-term compatibility. Throughout the migration, we addressed challenges associated with polymorphic deserialization errors, including inconsistencies and mismatches in type information during deserialization. Additionally, we resolved issues related to null values and case-sensitive type checking by creating custom JsonConverters. Notably, these challenges were particularly prominent when processing incoming requests to our API. As a result, we now have a more efficient and future-proof JSON processing solution for our application.