Grids, Hubs, & Buses... Oh My!

on

A Path from .Net Framework to .Net Core

on
Software developers love to work on "greenfield" development projects where they can start from scratch and work with a blank canvas.   Unfortunately, this is not reality and  we are mostly tasked to work with existing functionality and or applications and ultimately presented with a decision to modernize or not when working with existing or legacy applications.

This blog post focuses on the migration or modernization of  .NET Framework based applications to .NET Core.  I will show reasons for modernization, rationale for modernization, and finally a high-level overview of the modernization process from .NET Framework to .NET Core.

There are many reasons for modernization, but we must entertain the valid option  of "Not to Modernize" .   Microsoft has no plans for further major releases or feature additions to .NET Framework, but .NET Framework continues to be supported by Microsoft.

The amount of time and cost to modernize .NET Framework applications to .NET Core is dependent on many factors including size of project, project type, and resource availability.    Benefit/Cost must be realized prior to deciding on a modernization strategy.  Some of the benefits of moving to .NET Core include the following:    
  •  .NET Core has many performance improvements
  •  Cross-platform support for Windows, Linux, MacOS
  •  Microservice support via extensible framework
  •  Multiple language and API Features
  •  Latest technology and ecosystem NuGet libraries, tools, and components

We follow the workflow below when wanting to migrate an application from .NET Framework to .NET Core.



Preparation

We use the preparation phase to determine how long will it take to move to .NET Core and what is the effort to do so.   Different aspects of the project are analyzed to gives us the analysis we require.   We will look at project types as ASP Web applications highly differ from class libraries or console applications.  We look at project dependencies including 3rd party dependencies, .NET API dependencies, and project to project dependencies.   We also look at the target platform and the priorities of the projects to be migrated.   Each part of this analysis can greatly effect the estimated time and effort for your migration.   It is at this point we can make a determination in the cost/benefit analysis of whether to migrate or not.

Project Upgrade

The project upgrade phase is where we manually upgrade our .NET project file from the old *.csproj to the new SDK project style.  We will also upgrade all the NuGet packages to reflect our target migration framework.   It is at this point we decide our strategy going forward and there are many factors that go into making this distinction and better left for a blog post on its own.

Option 1 - Upgrade the project  source code in place (edit and alter existing source code files)
Option 2 - Upgrade project source side-by-side (create new source code files from existing files)

This is a good point in the process to take a look at some tools that may be able to assist with our transition.    The .NET Upgrade Assistant is a command line tool that can help automate some of the upgrade work.  This tool is limited to some project types and usually requires manual intervention after the fact.     The .NET portability Analyzer is a tool that analyzes assemblies and provides a portability report. I have found this very useful with looking at my dependencies in the preparation phase.

Source Upgrade

This is where the rubber meets the road and we are transitioning our source code.   This includes source code, app configurations, static content, views, models, etc..  This is also the point where we could use the .NET Upgrade Assistant.

We will also look at more global functionality and how it may change in our new target environment.  This typically results in some refactoring around areas such as authentication/authorization,  logging, error handling, and dependency injection.

Test & Deploy

"Just because it compiles does not mean that it works!"

Different operating runtime environments can cause vastly different results.   Your application may run differently on Linux then it does on Windows.    The .NET API may work a little differently in .NET Framework then in .NET Core.

We may also have to refactor based on where we are deploying as many times a migration to .NET Core may also entail a migration from on premise to a Cloud environment.  

As with all development efforts...   TEST, TEST and RETEST...


This is a very high-level phased approach to updating or transform existing software.  We can now leverage latest technologies, improve performance, enhance user experiences, and align with current business needs.   I fully recommend that organization continually assess their specific application requirements, dependencies, and the potential benefits of migrating to newer frameworks.