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
- Change target framework in project files (*.csproj). Example:
- If the upgraded project uses ASP.NET Core, update NuGet packages specific to ASP.NET Core
- Update Dockerfiles. Example:
FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build (...)
- Update DevOps pipelines or GitHub Actions that deploy the code to use newer .NET SDK version. Example from GitHub Action:
Code language: YAML (yaml)
- name: Setup .NET Core uses: actions/[email protected] with: dotnet-version: 6.0.x include-prerelease: true
- (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.
- (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
usingdeclarations 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.
- 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.
- 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 🙂