Migrate from .NET 5 to .NET 6: my checklist

by

New releases of .NET often come with features that I really like to use in my daily developer work. Therefore, I like to keep projects I work on at the most recent stable version of .NET.

Soon we’ll officially have stable versions .NET 6, released along with C# 10 and Visual Studio 2022. I like the productivity improvements those versions introduce. As we already have a Release Candidate available, I decided to play a bit and upgrade some of my side projects to see how it goes. As a by-product of this play, I created a checklist for migration to .NET 6. I expect I’ll be doing that many more times in the future, so I wrote it down:

My checklist for migrating solutions to .NET6

  1. Change target framework in project files (*.csproj). Example: <TargetFramework>net6.0</TargetFramework>
  2. If the upgraded project uses ASP.NET Core, update NuGet packages specific to ASP.NET Core
  3. Update Dockerfiles. Example: FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build (...)
  4. Update DevOps pipelines or GitHub Actions that deploy the code to use newer .NET SDK version. Example from GitHub Action:
    - name: Setup .NET Core
      uses: actions/setup-dotnet@v1
      with:
        dotnet-version: 6.0.x
        include-prerelease: true
Code language: YAML (yaml)
  1. (Optional) Update all NuGet package dependencies. That’s really unrelated to framework upgrade, but it’s a good opportunity, as we will need to test the whole solution anyway.
  2. (Optional) Update projects to take advantage of new .NET 6 features:
    • Refactor to use file scoped namespace declarations everywhere to reduce code indentation by 1 level.
    • Enable implicit using declarations by adding <ImplicitUsings>enable</ImplicitUsings> to the *.csproj files. Run code cleanup in Visual Studio to remove using declarations which became redundant.
    • Enable nullable reference types by adding <Nullable>enable</Nullable> to the *.csproj files. This feature was available since C#8, but was not included in project templates until .NET 6. It’s likely not present if you migrate projects, and it enables super-useful analysis of nullability-related issues.
  3. Fix all new warnings that appeared. Some APIs might now be obsolete or there could have been breaking changes, although so far, I didn’t encounter anything that wouldn’t be easy to fix.
  4. Finally, make sure everything compiles and works in runtime!

Can you see anything else worth doing as a part of target framework upgrade? Thanks for stopping by 🙂

Leave a Comment