/migrate-dotnet8-to-dotnet9

name: migrate-dotnet8-to-dotnet9
description: >
  Migrate a .NET 8 project to .NET 9 and resolve all breaking changes.
  USE FOR: upgrading TargetFramework from net8.0 to net9.0, fixing build errors
  after updating the .NET 9 SDK, resolving behavioral changes in .NET 9 / C# 13 /
  ASP.NET Core 9 / EF Core 9, replacing BinaryFormatter (now always throws),
  resolving SYSLIB0054-SYSLIB0057, adapting to params span overload resolution,
  fixing C# 13 compiler changes, updating HttpClientFactory for SocketsHttpHandler,
  and resolving EF Core 9 migration/Cosmos DB changes.
  DO NOT USE FOR: .NET Framework migrations, upgrading from .NET 7 or earlier,
  greenfield .NET 9 projects, or cosmetic modernization unrelated to the upgrade.
license: MIT

.NET 8 → .NET 9 Migration

Migrate a .NET 8 project or solution to .NET 9, systematically resolving all breaking changes. The outcome is a project targeting `net9.0` that builds cleanly, passes tests, and accounts for every behavioral, source-incompatible, and binary-incompatible change introduced in the .NET 9 release.

When to Use

• Upgrading `TargetFramework` from `net8.0` to `net9.0`
• Resolving build errors or new warnings after updating the .NET 9 SDK
• Adapting to behavioral changes in .NET 9 runtime, ASP.NET Core 9, or EF Core 9
• Replacing `BinaryFormatter` usage (now always throws at runtime)
• Updating CI/CD pipelines, Dockerfiles, or deployment scripts for .NET 9

When Not to Use

• The project already targets `net9.0` and builds cleanly — migration is done. If the goal is to reach `net10.0`, use the `migrate-dotnet9-to-dotnet10` skill as the next step.
• Upgrading from .NET 7 or earlier — address the prior version breaking changes first
• Migrating from .NET Framework — that is a separate, larger effort
• Greenfield projects that start on .NET 9 (no migration needed)

Inputs

| Input | Required | Description | |-------|----------|-------------| | Project or solution path | Yes | The `.csproj`, `.sln`, or `.slnx` entry point to migrate | | Build command | No | How to build (e.g., `dotnet build`, a repo build script). Auto-detect if not provided | | Test command | No | How to run tests (e.g., `dotnet test`). Auto-detect if not provided | | Project type hints | No | Whether the project uses ASP.NET Core, EF Core, WinForms, WPF, containers, etc. Auto-detect from PackageReferences and SDK attributes if not provided |

Workflow

> **Answer directly from the loaded reference documents.** Do not search the filesystem or fetch web pages for breaking change information — the references contain the authoritative details. Focus on identifying which breaking changes apply and providing concrete fixes. > > **Commit strategy:** Commit at each logical boundary — after updating the TFM (Step 2), after resolving build errors (Step 3), after addressing behavioral changes (Step 4), and after updating infrastructure (Step 5). This keeps each commit focused and reviewable.

Step 1: Assess the project

1. Identify how the project is built and tested. Look for build scripts, `.sln`/`.slnx` files, or individual `.csproj` files. 2. Run `dotnet --version` to confirm the .NET 9 SDK is installed. If it is not, stop and inform the user. 3. Determine which technology areas the project uses by examining:

• **SDK attribute**: `Microsoft.NET.Sdk.Web` → ASP.NET Core; `Microsoft.NET.Sdk.WindowsDesktop` with `<UseWPF>` or `<UseWindowsForms>` → WPF/WinForms
• **PackageReferences**: `Microsoft.EntityFrameworkCore.*` → EF Core; `Microsoft.Extensions.Http` → HttpClientFactory
• **Dockerfile presence** → Container changes relevant
• **P/Invoke or native interop usage** → Interop changes relevant
• **`BinaryFormatter` usage** → Serialization migration needed
• **`System.Text.Json` usage** → Serialization changes relevant
• **X509Certificate constructors** → Cryptography changes relevant

4. Record which reference documents are relevant (see the reference loading table in Step 3). 5. Do a **clean build** (`dotnet build --no-incremental` or delete `bin`/`obj`) on the current `net8.0` target to establish a clean baseline. Record any pre-existing warnings.

Step 2: Update the Target Framework

1. In each `.csproj` (or `Directory.Build.props` if centralized), change:

   <TargetFramework>net8.0</TargetFramework>

to:

   <TargetFramework>net9.0</TargetFramework>

For multi-targeted projects, add `net9.0` to `<TargetFrameworks>` or replace `net8.0`.

2. Update all `Microsoft.Extensions.*`, `Microsoft.AspNetCore.*`, `Microsoft.EntityFrameworkCore.*`, and other Microsoft package references to their 9.0.x versions. If using Central Package Management (`Directory.Packages.props`), update versions there.

3. Run `dotnet restore`. Watch for:

• **Version requirements**: .NET 9 SDK requires Visual Studio 17.12+ to target `net9.0` (17.11 for `net8.0` and earlier).
• **New warnings for .NET Standard 1.x** and **.NET 7 targets** — consider updating or removing outdated target frameworks.

4. Run a clean build. Collect all errors and new warnings. These will be addressed in Step 3.

Step 3: Resolve build errors and source-incompatible changes

Work through compilation errors and new warnings systematically. Load the appropriate reference documents based on the project type:

| If the project uses… | Load reference | |-----------------------|----------------| | Any .NET 9 project | `references/csharp-compiler-dotnet8to9.md` | | Any .NET 9 project | `references/core-libraries-dotnet8to9.md` | | Any .NET 9 project | `references/sdk-msbuild-dotnet8to9.md` | | ASP.NET Core | `references/aspnet-core-dotnet8to9.md` | | Entity Framework Core | `references/efcore-dotnet8to9.md` | | Cryptography APIs | `references/cryptography-dotnet8to9.md` | | System.Text.Json, HttpClient, networking | `references/serialization-networking-dotnet8to9.md` | | Windows Forms or WPF | `references/winforms-wpf-dotnet8to9.md` | | Doc