Official agent skill

Migrate Dotnet8 To Dotnet9

by dotnet in dotnet/skills

Migrate a .NET 8 project to .NET 9 and resolve all breaking changes.

OfficialMITAuto-check passedDevelopment

Install Migrate Dotnet8 To Dotnet9

skills CLI
$ npx skills add dotnet/skills --skill migrate-dotnet8-to-dotnet9 -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install dotnet/skills migrate-dotnet8-to-dotnet9 --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/dotnet/skills.git skills-src && mkdir -p .claude/skills && cp -r skills-src/plugins/dotnet-upgrade/skills/migrate-dotnet8-to-dotnet9 .claude/skills/migrate-dotnet8-to-dotnet9 && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
migrate-dotnet8-to-dotnet9
GitHub stars
5.6k
Used in
2 other repos
Token cost
~3.9k tokens
SKILL.md length
1,635 words
Files
11 (incl. references)
Skills in repo
91
Repo updated
First seen
Licence
MIT

At a glance

Migrate a .NET 8 project to .NET 9 and resolve all breaking changes.

  • Works in 6 steps: Assess the project → Update the Target Framework → Resolve build errors and… → …
  • : upgrading TargetFramework from net8.0 to net9.0
  • SKILL.md covers When to Use, When Not to Use, Inputs and Workflow, plus 1 more section
  • Calls dotnet and apt-get

What it does

Migrate Dotnet8 To Dotnet9 is an agent skill from dotnet/skills, published by the product's own GitHub organization. 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…

Its SKILL.md is about 3.9k tokens, which your agent loads only when the skill is triggered. The skill folder holds 11 other files, including reference files (for example `references/aspnet-core-dotnet8to9.md`, `references/containers-interop-dotnet8to9.md` and `references/core-libraries-dotnet8to9.md`).

It sits in Development, covering Legacy modernization and Code migrations. It works with .NET, ASP.NET Core, C# and Azure Cosmos DB. The repository describes itself as: Repository for skills to assist AI coding agents with .NET and C. The licence is MIT.

When your agent uses it

  • : 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)

Example prompts

  • “/migrate-dotnet8-to-dotnet9”

Requirements

  • Docker

Workflow steps

6 steps, taken from the step headings in SKILL.md.

  1. Assess the project
  2. Update the Target Framework
  3. Resolve build errors and source-incompatible changes
  4. Address behavioral changes
  5. Update infrastructure
  6. Verify

What it can do on your machine

Read from SKILL.md and the folder at commit a660de8. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • dotnet
    • apt-get

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Migrate Dotnet8 To Dotnet9 loads about 3.9k tokens when it runs, and up to ~14k if it reads all its reference files. Until then it costs about 175 tokens; SKILL.md has 1,635 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~175
When it runs · the whole SKILL.md, loaded when a task matches
~3.9k
With references · SKILL.md plus every file in references/, read only if the agent opens them
~14k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from dotnet/skills at commit a660de8, republished under its MIT licence (© dotnet). 1,635 words, ~3,917 tokens.

Download SKILL.mdSave it as .claude/skills/migrate-dotnet8-to-dotnet9/SKILL.md (or your agent's skills folder). This skill also uses 10 other files; get the full folder from GitHub.
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

InputRequiredDescription
Project or solution pathYesThe .csproj, .sln, or .slnx entry point to migrate
Build commandNoHow to build (e.g., dotnet build, a repo build script). Auto-detect if not provided
Test commandNoHow to run tests (e.g., dotnet test). Auto-detect if not provided
Project type hintsNoWhether 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:

    xml
    <TargetFramework>net8.0</TargetFramework>

    to:

    xml
    <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 projectreferences/csharp-compiler-dotnet8to9.md
Any .NET 9 projectreferences/core-libraries-dotnet8to9.md
Any .NET 9 projectreferences/sdk-msbuild-dotnet8to9.md
ASP.NET Corereferences/aspnet-core-dotnet8to9.md
Entity Framework Corereferences/efcore-dotnet8to9.md
Cryptography APIsreferences/cryptography-dotnet8to9.md
System.Text.Json, HttpClient, networkingreferences/serialization-networking-dotnet8to9.md
Windows Forms or WPFreferences/winforms-wpf-dotnet8to9.md
Docker containers, native interopreferences/containers-interop-dotnet8to9.md
Runtime configuration, deploymentreferences/deployment-runtime-dotnet8to9.md

Common source-incompatible changes to check for:

  1. params span overload resolution — New params ReadOnlySpan<T> overloads on String.Join, String.Concat, Path.Combine, Task.WhenAll, and many more now bind preferentially. Code calling these methods inside Expression lambdas will fail (CS8640/CS9226). See references/core-libraries-dotnet8to9.md.

  2. StringValues ambiguous overload — The params Span<T> feature creates ambiguity with StringValues implicit operators on methods like String.Concat, String.Join, Path.Combine. Fix by explicitly casting arguments. See references/core-libraries-dotnet8to9.md.

  3. New obsoletion warnings (SYSLIB0054–SYSLIB0057):

    • SYSLIB0054: Replace Thread.VolatileRead/VolatileWrite with Volatile.Read/Volatile.Write
    • SYSLIB0057: Replace X509Certificate2/X509Certificate binary/file constructors with X509CertificateLoader methods
    • Also SYSLIB0055 (ARM AdvSimd signed overloads) and SYSLIB0056 (Assembly.LoadFrom with hash algorithm) — see references/core-libraries-dotnet8to9.md
  4. C# 13 InlineArray on record structs — [InlineArray] attribute on record struct types is now disallowed (CS9259). Change to a regular struct. See references/csharp-compiler-dotnet8to9.md.

  5. C# 13 iterator safe context — Iterators now introduce a safe context in C# 13. Local functions inside iterators that used unsafe code inherited from an outer unsafe class will now error. Add unsafe modifier to the local function. See references/csharp-compiler-dotnet8to9.md.

  6. C# 13 collection expression overload resolution — Empty collection expressions ([]) no longer use span vs non-span to tiebreak overloads. Exact element type is now preferred. See references/csharp-compiler-dotnet8to9.md.

  7. String.Trim(params ReadOnlySpan<char>) removed — Code compiled against .NET 9 previews that passes ReadOnlySpan<char> to Trim/TrimStart/TrimEnd must rebuild; the overload was removed in GA. See references/core-libraries-dotnet8to9.md.

  8. BinaryFormatter always throws — If the project uses BinaryFormatter, stop and inform the user — this is a major decision. See references/serialization-networking-dotnet8to9.md.

  9. HttpListenerRequest.UserAgent is nullable — The property is now string?. Add null checks. See references/serialization-networking-dotnet8to9.md.

  10. Windows Forms nullability annotation changes — Some WinForms API parameters changed from nullable to non-nullable. Update call sites. See references/winforms-wpf-dotnet8to9.md.

  11. Windows Forms security analyzers (WFO1000) — New analyzers produce errors for properties without explicit serialization configuration. See references/winforms-wpf-dotnet8to9.md.

Build again after each batch of fixes. Repeat until the build is clean.

Show full SKILL.md (719 more words)Show less
Step 4: Address behavioral changes

Behavioral changes do not cause build errors but may change runtime behavior. Review each applicable item and determine whether the previous behavior was relied upon.

High-impact behavioral changes (check first):

  1. Floating-point to integer conversions are now saturating — Conversions from float/double to integer types now saturate instead of wrapping on x86/x64. See references/deployment-runtime-dotnet8to9.md.

  2. EF Core: Pending model changes exception — Migrate()/MigrateAsync() now throws if the model has pending changes. Search for DateTime.Now, DateTime.UtcNow, or Guid.NewGuid() in any HasData call — these must be replaced with fixed constants (e.g., new DateTime(2024, 1, 1, 0, 0, 0, DateTimeKind.Utc)). See references/efcore-dotnet8to9.md.

  3. EF Core: Explicit transaction exception — Migrate() inside a user transaction now throws. See references/efcore-dotnet8to9.md.

  4. HttpClientFactory uses SocketsHttpHandler by default — Code that casts the primary handler to HttpClientHandler will get InvalidCastException. See references/serialization-networking-dotnet8to9.md.

  5. HttpClientFactory header redaction by default — All header values in Trace-level logs are now redacted. See references/serialization-networking-dotnet8to9.md.

  6. Environment variables take precedence over runtimeconfig.json — Runtime configuration settings from environment variables now override runtimeconfig.json. See references/deployment-runtime-dotnet8to9.md.

  7. ASP.NET Core ValidateOnBuild/ValidateScopes in development — HostBuilder now enables DI validation in development by default. See references/aspnet-core-dotnet8to9.md.

Other behavioral changes to review (may cause runtime exceptions ⚠️ or subtle behavioral differences):

  • ⚠️ FromKeyedServicesAttribute no longer injects non-keyed service fallback — throws InvalidOperationException
  • ⚠️ Container images no longer install zlib — apps depending on system zlib will fail
  • ⚠️ Intel CET is now enabled by default — non-CET-compatible native libraries may cause process termination
  • BigInteger now has a maximum length of (2^31) - 1 bits
  • JsonDocument deserialization of JSON null now returns non-null JsonDocument with JsonValueKind.Null instead of C# null
  • System.Text.Json metadata reader now unescapes metadata property names
  • ZipArchiveEntry names/comments now respect the UTF-8 flag
  • IncrementingPollingCounter initial callback is now asynchronous
  • InMemoryDirectoryInfo prepends rootDir to files
  • RuntimeHelpers.GetSubArray returns a different type
  • PictureBox raises HttpRequestException instead of WebException
  • StatusStrip uses a different default renderer
  • IMsoComponent support is opt-in
  • SafeEvpPKeyHandle.DuplicateHandle up-refs the handle
  • HttpClient metrics report server.port unconditionally
  • URI query strings redacted in HttpClient EventSource events and IHttpClientFactory logs
  • dotnet watch is incompatible with Hot Reload for old frameworks
  • WPF GetXmlNamespaceMaps returns Hashtable instead of String
Step 5: Update infrastructure
  1. Dockerfiles: Update base images. Note that .NET 9 container images no longer install zlib. If your app depends on zlib, add RUN apt-get update && apt-get install -y zlib1g to your Dockerfile.

    dockerfile
    # Before
    FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
    FROM mcr.microsoft.com/dotnet/aspnet:8.0
    # After
    FROM mcr.microsoft.com/dotnet/sdk:9.0 AS build
    FROM mcr.microsoft.com/dotnet/aspnet:9.0
  2. CI/CD pipelines: Update SDK version references. If using global.json, update:

    json
    {
      "sdk": {
        "version": "9.0.100",
        "rollForward": "latestFeature"
      }
    }

    Review the rollForward policy — if set to "disable" or "latestPatch", the SDK may not resolve correctly after upgrading. "latestFeature" (recommended) allows the SDK to roll forward to the latest 9.0.x feature band.

  3. Visual Studio version: .NET 9 SDK requires VS 17.12+ to target net9.0. VS 17.11 can only target net8.0 and earlier.

  4. Terminal Logger: dotnet build now uses Terminal Logger by default in interactive terminals. CI scripts that parse MSBuild console output may need --tl:off or MSBUILDTERMINALLOGGER=off.

  5. dotnet workload output: Output format has changed. Update any scripts that parse workload command output.

  6. .NET Monitor images: Tags simplified to version-only (affects container orchestration referencing specific tags).

Step 6: Verify
  1. Run a full clean build: dotnet build --no-incremental
  2. Run all tests: dotnet test
  3. If the application is containerized, build and test the container image
  4. Smoke-test the application, paying special attention to:
    • BinaryFormatter usage (will throw at runtime)
    • Floating-point to integer conversion behavior
    • EF Core migration application
    • HttpClientFactory handler casting and logging
    • DI validation in development environment
    • Runtime configuration settings (environment variable precedence)
  5. Review the diff and ensure no unintended behavioral changes were introduced

Reference Documents

The references/ folder contains detailed breaking change information organized by technology area. Load only the references relevant to the project being migrated:

Reference fileWhen to load
references/csharp-compiler-dotnet8to9.mdAlways (C# 13 compiler breaking changes — InlineArray on records, iterator safe context, collection expression overloads)
references/core-libraries-dotnet8to9.mdAlways (applies to all .NET 9 projects)
references/sdk-msbuild-dotnet8to9.mdAlways (SDK and build tooling changes)
references/aspnet-core-dotnet8to9.mdProject uses ASP.NET Core
references/efcore-dotnet8to9.mdProject uses Entity Framework Core
references/cryptography-dotnet8to9.mdProject uses System.Security.Cryptography or X.509 certificates
references/serialization-networking-dotnet8to9.mdProject uses BinaryFormatter, System.Text.Json, HttpClient, or networking APIs
references/winforms-wpf-dotnet8to9.mdProject uses Windows Forms or WPF
references/containers-interop-dotnet8to9.mdProject uses Docker containers or native interop (P/Invoke)
references/deployment-runtime-dotnet8to9.mdProject uses runtime configuration, deployment, or has floating-point to integer conversions

© dotnet, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 10 other files (references) in plugins/dotnet-upgrade/skills/migrate-dotnet8-to-dotnet9 of dotnet/skills.

  • SKILL.md
  • references/aspnet-core-dotnet8to9.md
  • references/containers-interop-dotnet8to9.md
  • references/core-libraries-dotnet8to9.md
  • references/cryptography-dotnet8to9.md
  • references/csharp-compiler-dotnet8to9.md
  • references/deployment-runtime-dotnet8to9.md
  • references/efcore-dotnet8to9.md
  • references/sdk-msbuild-dotnet8to9.md
  • references/serialization-networking-dotnet8to9.md
  • references/winforms-wpf-dotnet8to9.md

Open the folder on GitHubat commit a660de8

Used in 2 other repositories

We found 3 copies of this SKILL.md (exact, near-identical or edited) in other folders, from 2 other GitHub owners. This page covers the copy in dotnet/skills, which our catalogue first saw on October 7, 2026.

Compare with similar skills

Migrate Dotnet8 To Dotnet9 next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Migrate Dotnet8 To Dotnet9 compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Migrate Dotnet8 To Dotnet9 this skilldotnet/skills5.6k2 repos~3.9kAutomated safety check: PassMIT
Dotnet Csharpnovotnyllc/dotnet-artisan233—~1.7kAutomated safety check: PassMIT
Aspire Project V2 MigrationCommunityToolkit/Aspire629—~3.4kAutomated safety check: PassMIT
Neo4j Driver Dotnet Skillneo4j-contrib/neo4j-skills114—~4.5kAutomated safety check: NotesMIT
Dynamo Dotnet JanitorDynamoDS/Dynamo2k—~682Automated safety check: PassApache-2.0
Modern Csharpcodewithmukesh/dotnet-claude-kit7511 repos~1.7kAutomated safety check: PassMIT

Similar skills

  • Dotnet Csharp

    novotnyllc/dotnet-artisan

    Baseline C skill loaded for every .NET code path. An agent skill from novotnyllc/dotnet-artisan.

    233 GitHub stars~1.7k tokensUpdated today
    DevelopmentAuto-check passed
  • Aspire Project V2 Migration

    CommunityToolkit/Aspire

    WORKFLOW SKILL - Safely migrates eligible Aspire 13.6+ AppHosts from legacy ProjectResource APIs to experimental DotnetProjectResource APIs after a per-resource assessment and explicit approval of…

    629 GitHub stars~3.4k tokensUpdated yesterday
    DevelopmentAuto-check passed
  • Neo4j Driver Dotnet Skill

    neo4j-contrib/neo4j-skills

    Neo4j .NET Driver v6 — IDriver lifecycle, DI registration (singleton), ExecutableQuery fluent API, ExecuteReadAsync/ExecuteWriteAsync managed transactions, IResultCursor (FetchAsync/ ToListAsync)…

    114 GitHub stars~4.5k tokensUpdated 2 days ago
    DevelopmentAuto-check: notes
  • Dynamo Dotnet Janitor

    DynamoDS/Dynamo

    Perform janitorial tasks on C/.NET code including cleanup, modernization, and tech debt remediation.

    2k GitHub stars~682 tokensUpdated today
    DevelopmentAuto-check passed
  • Modern Csharp

    codewithmukesh/dotnet-claude-kit

    Modern C language features for .NET 10 and C 14. An agent skill from codewithmukesh/dotnet-claude-kit.

    751 GitHub starsUsed in 1 repo~1.7k tokens
    DevelopmentAuto-check passed
  • Csharp Patterns

    softspark/ai-toolkit

    C/.NET: LINQ, async/await, DI, records, nullable refs, ASP.NET Core, EF Core, MediatR.

    179 GitHub stars~3.6k tokensUpdated yesterday
    DevelopmentAuto-check passed

More from dotnet/skills

All 91 skills in this repo
  • Official

    Resolves .NET runtime frames in Apple .ips crash logs to function names, source files and line numbers using dSYM symbols, atos and the Microsoft symbol server.

    5.6k GitHub starsUsed in 1 repo~2.4k tokens
    Auto-check passed
  • Official

    Resolves native crash frames from .NET Android tombstones to function names, source files and line numbers using BuildIds, Microsoft's symbol server and llvm-symbolizer.

    5.6k GitHub starsUsed in 1 repo~2.1k tokens
    Auto-check passed
  • Official

    Scans C# and .NET code for about 50 performance anti-patterns and reports prioritized findings with concrete fixes, at a scan depth you choose.

    5.6k GitHub starsUsed in 3 repos~3.1k tokens
    Auto-check passed
  • Official

    Statically pairs source files with test files to list code that no test references, using Roslyn for C# or tree-sitter for many languages, with no build.

    5.6k GitHub starsUsed in 1 repo~3.3k tokens
    Auto-check passed
  • Microbenchmarking

    dotnet/skills

    Official

    Activate this skill when BenchmarkDotNet (BDN) is involved in the task — creating, running, configuring, or reviewing BDN benchmarks.

    5.6k GitHub starsUsed in 3 repos~3.3k tokens
    Auto-check passed
  • Official

    Makes .NET projects compatible with Native AOT and trimming by resolving IL trim and AOT analyzer warnings through annotations rather than suppressions.

    5.6k GitHub starsUsed in 2 repos~4.2k tokens
    Auto-check passed

Categories

Questions about Migrate Dotnet8 To Dotnet9

What does Migrate Dotnet8 To Dotnet9 do?

Migrate a .NET 8 project to .NET 9 and resolve all breaking changes. Migrate Dotnet8 To Dotnet9 is an agent skill from dotnet/skills, published by the product's own GitHub organization.NET 9 and resolve all breaking changes.

When should I use Migrate Dotnet8 To Dotnet9?

Migrate Dotnet8 To Dotnet9 fits situations like: : 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).

How do I install Migrate Dotnet8 To Dotnet9 in Claude Code?

Run `npx skills add dotnet/skills --skill migrate-dotnet8-to-dotnet9 -a claude-code`. Or copy the skill folder (plugins/dotnet-upgrade/skills/migrate-dotnet8-to-dotnet9 in dotnet/skills) into .claude/skills/migrate-dotnet8-to-dotnet9 in your project. Claude Code loads it when a task matches its description.

How do I install Migrate Dotnet8 To Dotnet9 in Codex?

Run `npx skills add dotnet/skills --skill migrate-dotnet8-to-dotnet9 -a codex`. Or copy the skill folder (plugins/dotnet-upgrade/skills/migrate-dotnet8-to-dotnet9 in dotnet/skills) into .agents/skills/migrate-dotnet8-to-dotnet9 in your project. Codex loads it when a task matches its description.

Can I use Migrate Dotnet8 To Dotnet9 in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add dotnet/skills --skill migrate-dotnet8-to-dotnet9 -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/migrate-dotnet8-to-dotnet9, .gemini/skills/migrate-dotnet8-to-dotnet9, .github/skills/migrate-dotnet8-to-dotnet9 and .opencode/skills/migrate-dotnet8-to-dotnet9 in your project.

What does Migrate Dotnet8 To Dotnet9 need to run?

Going by SKILL.md and its folder, Migrate Dotnet8 To Dotnet9 needs the command-line tools its instructions call (dotnet and apt-get). Our summary lists: Docker.

Does Migrate Dotnet8 To Dotnet9 access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Migrate Dotnet8 To Dotnet9 safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Migrate Dotnet8 To Dotnet9 use?

Migrate Dotnet8 To Dotnet9 is published under the MIT licence (declared in SKILL.md). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Migrate Dotnet8 To Dotnet9 use?

About 3.9k tokens (SKILL.md is roughly 16k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full. Its references folder adds about 9.6k tokens, read only when the agent opens those files.

What are the alternatives to Migrate Dotnet8 To Dotnet9?

Skills that share tags, products or a category with Migrate Dotnet8 To Dotnet9: Dotnet Csharp (novotnyllc/dotnet-artisan, 233 stars), Aspire Project V2 Migration (CommunityToolkit/Aspire, 629 stars), Neo4j Driver Dotnet Skill (neo4j-contrib/neo4j-skills, 114 stars) and Dynamo Dotnet Janitor (DynamoDS/Dynamo, 2k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Migrate Dotnet8 To Dotnet9?

dotnet (a GitHub organization, an official publisher) maintains it in dotnet/skills, which has 5,576 GitHub stars. The repository holds 91 skills in this directory. The repository was last updated on October 8, 2026.

Source: dotnet/skills on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.