.NET Portability Analyzer

.NET Portability Analyzer

In order to migrate your application from .NET Framework to .NET Core, one part of the migration is making sure your existing code that targets the .NET Framework BCL (Base Class Library) also works with the .NET Core BCL. This is where the .NET Portability Analyzer comes in.

Migrating from .NET Framework to .NET Core

This post is in a blog series for migrating from .NET Framework to .NET Core. Here’ are some earlier post if you need to catch up:


I’ve recorded a short video that also describes how to use the portability analyzer.


.NET Framework and .NET Core are two entirely different things. Yes, they share the name “.NET”, but they are comprised of different Runtimes and Base Class Libraries. The Base Class Library (BCL) is the foundation of the framework for .NET types such as Object, String, Boolean, Array, List, DateTime, and other primitive types and data structures.

.NET Standard

In order to share code/libraries between .NET Framework applications and .NET Core applications is where .NET Standard comes in. I’ve found the simplest way to explain this is to think of .NET Standard as an interface (or a contract).

Both .NET Framework and .NET Core implement that interface.

Because of this, if you write an application that is .NET Standard 2.0 compliant, you can then run your application on both .NET Framework or .NET Core.

  • .NET Framework 4.8 supports .NET Standard 2.0
  • .NET Core 2.1 supports .NET Standard 2.0
  • .NET Core 3.1 supports .NET Standard 2.1

Again, because both .NET Framework 4.8 and .NET Core 2.1 support .NET Standard 2.0, you could run your application on either.

Note that .NET Core 3.1 supports .NET Standard 2.1. And it has been noted that .NET Framework will never support .NET Standard 2.1.

.NET Portability Analyzer

The .NET Portability Analyzer is a tool that analyzes your codebase and provides a report about what types you’re using from the BCL that are supported in .NET Standard or .NET Core.

This allows you to determine how close or far you are away from being able to migrate to .NET Core. A lot of the Types and APIs that exist in .NET Framework also now exist in .NET Core. There are however some gaps that will never be officially implemented in .NET Core. Most notably this will be any type that lives in the System.Web namespace.

There are two ways to run the .NET Portability Analyzer. The simplest is to use the Visual Studio Extension.

Once installed, you can access the settings from the solution context menu:

The Portability Analyzer settings allow you to configure which target platforms to review against. You can specify .NET Core specific or .NET Standard.

.NET Portability Analyzer

After configuring you can then run the “Analyzer Assembly Portability” from the solution context menu. This will generate an Excel file (.xlsx) that will contain all the types that exist in your code that are not supported against the target platforms you specified.

The Portability Summary section gives overall % of each assembly/project in your solution and how it’s supported on the target platform.

.NET Portability Analyzer

The details section lists all the APIs that are missing from a target platform.

The missing assemblies section of the report likely will include a list of dependencies that you are likely using via NuGet. I’ll cover how to handle 3rd party dependencies in another post.

This report will be invaluable for tracking down APIs that you’re using that are not supported in .NET Core.

Once you have these missing APIs in hand that are not supported in .NET Core, it really is up to you to determine how you want to handle or rewrite that code.

If you’re not using Visual Studio, you can simply build the .NET Portability Analyzer and run it against your assembly. You can find the source and instructions on the projects GitHub repo.

Useful Links

If you’ve used the portability analyzer and have and or comments that may help others, let me know in the comments or on Twitter.

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.

Roundup #71: C# Source Generators, MsQuic, CoreBoy, Channels

Introducing C# Source Generators

We’re pleased to introduce the first preview of Source Generators, a new C# compiler feature that lets C# developers inspect user code and generate new C# source files that can be added to a compilation. This is done via a new kind of component that we’re calling a Source Generator.

Link: https://devblogs.microsoft.com/dotnet/introducing-c-source-generators/

MsQuic is Open Source

Microsoft is open sourcing our QUIC library, MsQuic, on GitHub under an MIT license. MsQuic is a cross-platform, general-purpose library that implements the QUIC transport protocol. QUIC is being standardized by the Internet Engineering Task Force (IETF). MsQuic is a client and server solution optimized for multiple usage patterns and is used by multiple Microsoft products and services. MsQuic is currently in preview and supports Windows and Linux.

Link: https://techcommunity.microsoft.com/t5/networking-blog/msquic-is-open-source/ba-p/1345441


Link: https://github.com/davidwhitney/CoreBoy

Working with Channels in .NET

Channels enable a producer to safely pass data over to a consumer along with the appropriate notifications in both directions.

In this episode, Stephen Toub chats with Rich about the what, why and how of using the System.Threadding.Channels library. They walk us through a simple demo of using channels and also discuss the various strategies at our disposal.

Link: https://www.youtube.com/watch?v=gT06qvQLtJ0

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.

Migrating to ASP.NET Core

Migrating to ASP.NET Core

In the quest to migrate to .NET Core, the first step at the time (a couple of years ago) was to start migrating to ASP.NET Core from using Katana (Owin). This seemed like a logical first step as ASP.NET Core 2.x could run on .NET Framework as well as .NET Core. Ultimately this was a good first step in our migration.

ASP.NET Core 3.x is only supported on .NET Core 3.0 because it targets netstandard2.1.

.NET Framework only supports netstandard2.0 and will never support netstandard2.1

This makes it much more challenging to migrate because my recommendation is to get your application 100% compatible with netstandard2.0. If you do this, then you’ll be compatible with .NET Core 2.1.

Once you’re compatible with .NET Core 2.1 you can then can start running your applications on .NET Core 2.1 and from there, you can then migrate to .NET Core 3.x.

Migrating from .NET Framework to .NET Core

This blog post is in a series about migrating from .NET Framework to .NET Core.

Katana (OWIN)

Our web application was using the Katana Project and was self hosted using HttpListener. It was not using IIS.

This made our migration much simpler in some aspects because Katana really feels like a precursor to ASP.NET Core. Much of the same concepts exists such as the Startup and Middleware.

I’ve previously blogged about Migrating from Katana to ASP.NET Core. The general gist for migration is to implement any custom middleware you have with Katana over to ASP.NET Core. It’s really straight forward to do so and should feel natural. Most of the types are even named the same or very close to the same.


If you’re using ASP.NET Web API my biggest recommendation is to use the Compatibility Shim package.

This will save a bit of work as it adds functionality to ASP.NET Core to that was available in Web API. For example, it adds an ApiController type so you don’t need to update all your controllers to reflect the new ASP.NET Core Controller type.

Check out the official docs on the compatibility shim and what it provides and how to use it.


I don’t have much experience migrating MVC, however, I have used both ASP.NET MVC 5 and ASP.NET Core MVC and it doesn’t feel all that different. All the same, types (by name) exist such as Controller, ActionResult, etc.

Razor is still the same and so are layout files and the _ViewStart.cshtml.

Just like migrating Web API, you will need to create an ASP.NET Core application with the correct Startup class, and add/configure the MVC.

Check out the official docs on migrating from ASP.NET MVC

Migrating to ASP.NET Core Recommendation

My recommendation is to migrate to ASP.NET Core 2.1 and run it on .NET Framework 4.8.

The long term goal is to be running the latest ASP.NET Core on .NET Core. However, in order to migrate to ASP.NET Core, you want to be able to still run your application, which requires .NET Framework.

Do not worry about all your other dependencies yet, we will cover that in another post.

Useful Links

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.