Page 65 - MSDN Magazine, December 15, 2017

On-Premises
SQL Database
1
2
3 The important point is: This is a step-by-step process and you want to make sure your applica- tion is operational after performing each step. This includes having the code compile and passing all tests (you do have tests, right?), but it might also mean being able to deploy the current system to production. Whether you need that is a function of how much time the migration will take and how much your system is under active development. Alternatively, you might decide to bring up the new system independently of the
On-Premises Windows
Windows
SQL Database
Figure 1 Migrating a Typical .NET App Partially to the Cloud
Plan Your Migration
Unless your project is very small, you should take the time to plan your migration, and the most important part is understanding what you want to get out of it. Moving to .NET Core just because it’s the new hotness isn’t a good enough reason (unless you’re a true fan) as migrations are never free.
Let’s look at a typical .NET app, the Fabrikam Asset Management application. It consists of a Windows Presentation Foundation (WPF) front end and a Web API back end, storing data in a SQL Server, all deployed on Windows and on-premises. Fabrikam decided it would like to move its back end to Azure. The company is quite happy with the desktop application and wants to continue to leverage WPF. It also decided it’s best to use ASP.NET Core for the Web API back end as this allows more flexibility in the choice of server OS, as well as for isolated deployments using Docker.
A migration plan should include several steps instead of doing everything in one big swoop (also known as the big outage). This ensures you can deliver incremental value, keep your system operational, and learn and adapt as you perform the migration. Fabrikam’s migration plan looks like what’s shown in Figure 1.
As a first step, the plan moves the Web API back end to .NET Core, but the app will remain on Windows. This minimizes the amount of change the code must accommodate. The next step entails moving the .NET Core back end to the cloud. Then the company plans to move the back end to Linux. Later steps might involve Fabrikam deciding to leverage Docker.
On-Premises
WPF App
.NET Framework
WPF App
Windows
.NET Framework
Windows
WPF App
.NET Framework
Cloud
Web API Back End
Linux .NET Core
Azure SQL Database
Web API Back End
Web API Back End
Windows
.NET Framework
.NET Core
WPF App
.NET Framework
Business Logic
.NET Framework
12
WPF App
.NET Framework
Business Logic
.NET Standard
Web API Back End
.NET Core
old one to reduce the risk of operational disruption in case you manage to corner yourself.
Understanding your goals and migration path helps to reveal any new constraints you need to factor in when refining your architecture. In this case, Fabrikam needs to share business logic and infrastructure code between the WPF application and the Web API back end. In the current system, both are running on top of .NET Framework so that code is simply contained in a class library that also targets .NET Framework. Moving forward, Fabrikam needs to share that code between .NET Framework and .NET Core, so it decides to give .NET Standard 2.0 a shot, as shown in Figure 2.
Once you understand which part of your existing code needs to be ported and what it needs to be ported to, you should use the API Port tool (which you’ll find at aka.ms/apiport). See my demo at bit.ly/2zkaKDn to understand how easy or difficult this might be. API Port scans your existing application binaries, including any third-party code you might have, and produces a report that shows you assembly by assembly how portable each is, and provides a table of all the APIs that are either unavailable or must be migrated. API Port isn’t specific to .NET Standard or .NET Core: You can select any .NET implementation you want, including .NET Framework, .NET Core, .NET Standard, UWP, Mono and Xamarin. This allows you to plan your migrations regardless of what you’re porting from and what you need to port to.
When you run API Port, I recommend you use the targets .NET Standard + Platform Extensions and .NET Core + Platform Extensions. Including the extensions ensures you don’t get false negatives for APIs that don’t ship as part of the platform, but can be added by referencing an additional NuGet package. I also rec- ommend you use the command-line version of API Port and run it over your existing application as this is much easier, especially when your source code is spread across several solutions. This also allows you to assess third-party dependencies.
In the Fabrikam case, however, the company only needs to run
API Port over the shared library:
$ apiport analyze -f C:\\src\\fabrikam\\bin\\Fabrikam.Shared.dll -t ".NET Standard + Platform Extensions"
Fortunately for Fabrikam, the report API Port produces shows its library only uses APIs that are available for .NET Standard 2.0 (see Figure 3).
Dec. 15, 2017 / Connect(); Special Issue 61
Web API Back End
.NET Framework
Figure 2 Handling Shared Code When Targeting Multiple .NET Implementations
msdnmagazine.com