ASP.NET Core 2.2 to 3.0 migration

· Read in about 3 min · (452 words) ·


  • Notes below are kind of switching between .NET Core & .NET Standard & ASP.NET Core as it makes sense. Those are all closely related although perhaps not really…
  • There is still some confusion on my part so some of the information below may not be fully accurate - I would hear back to learn.

Lessons (re-)learned - ASP.NET Core is not .NET Core

  • None of the ASP.NET Core APIs is considered to be part of .NET Standard
    • It is obvious but it is easy to forget about it. Things like: Microsoft.Extensions.Logging.Abstractions, Microsoft.Extensions.DependencyInjection.Abstractions etc. are part of ASP.NET Core and thus are not covered by .NET Standard 2.0
  • Things are not made simpler since ASP.NET Core has same major version as new .NET Core (3.0)
  • ASP.NET Core 3.0 implements breaking changes (logging, service setup, …) - intent is clearly stated by major version change


  • Third party libraries which state that are .NET Standard 2.0 are not necessarily compatible with ASP.NET Core 3.0
    • The reason is that ASP.NET Core 3.0 allows safely reference .NET Standard 2.0 assemblies but upgrades references according to built-in versioning policies
    • So in compile time things will pass while in runtime some of the libraries my start throwing runtime exception like missing methods etc. since those are now using ASP.NET Core 3.0 libraries instead of ASP.NET Core 2.2.
  • There is a change in some of the areas - with older version of ASP.NET Core it was possible to easily write unit tests or expand functionality since majority of event internal things was exposed as public - I came across places which heavily moved towards the internal implementation.
  • The safest way how to avoid issues above seems to be re-target all the libraries to .NET Standard 2.1 and re-compile.
    • Suggestion in some ASP.NET Core forums is to rather re-target to ASP.NET Core 2.2
    • This means that it will be never possible to consume such libraries in full .NET Framework
  • General suggestion for library creators is to stay with .NET Standard 2.0
    • Which implies that C# 8 features cannot be used
    • Or to split and target two platforms utilizing old style #if and/or project changes.