November 10: Moving .NET 8 and .NET 9 AI and MCP Projects to .NET 10

.NET 8 and .NET 9 reach end of support on November 10, 2026. A checklist for moving AI and MCP projects to .NET 10, and why .NET 11 can wait in CI for now.

By Ajith Joseph · Fri Nov 06 2026 · Updated Fri Nov 06 2026 · 5 min read · intermediate

#dotnet #csharp #ai #aspnet-core

Both .NET 8 and .NET 9 reach end of support on November 10, 2026. That is three days from now. After that date your applications keep running, but Microsoft stops shipping security fixes and technical support for them. Microsoft's .NET team recommends .NET 10, the current long-term support release, as the target.

If you maintain MCP servers or AI services on .NET 8 or 9, this is the checklist I would work through. It focuses on the parts specific to AI and MCP projects, and it assumes you can retarget in a branch and run your tests.

The dates

From Microsoft's .NET blog and the sources that repeat it:

.NET 8 (LTS) was released November 14, 2023, and ends support November 10, 2026.
.NET 9 (STS) was released November 12, 2024. Microsoft extended STS support from 18 to 24 months starting with .NET 9, which is why it ends the same day as .NET 8.
.NET 10 (LTS) was released November 11, 2025 and is supported until November 2028. Sources disagree on the exact day in November 2028, so check Microsoft's support policy page if you need it.
.NET 11 is scheduled for general availability on November 10, 2026, during .NET Conf 2026 (November 10 to 12). Release candidate 2 came out on October 13.

Visual Studio 2022 is expected to mark its .NET 8 and .NET 9 components as out of support in a future servicing update.

Which version should you move to

Move production workloads to .NET 10. It is long-term support with a support window through 2028, and you can go straight from 8 or 9 to 10.

.NET 11 is a standard-term release and the headline C# 15 feature is union types. That is interesting, but sources I found disagree on how long .NET 11 is supported, so I would not move production to it this week. A good plan: run your build and tests against .NET 11 in CI once it ships, so you learn about problems early, and keep deploying .NET 10.

The mechanical steps

Retarget. In each project file, change the target framework to net10.0. For several projects, use Directory.Build.props so there is one line to change.
Pin the SDK. If you use a global.json, update it so developers and CI use a .NET 10 SDK.
Update container images. Move from the 8.0 or 9.0 runtime and SDK images to the 10.0 ones in every Dockerfile, and rebuild.
Update CI agents and hosting. Confirm your build image and hosting platform provide the .NET 10 runtime before you deploy.
Run the upgrade tooling and the tests. Microsoft's upgrade guidance points to the .NET Upgrade Assistant. Run it, then your unit and integration tests.
Read the breaking changes list for .NET 9 and .NET 10 for the libraries you use, especially if you skip from 8.

What is specific to AI and MCP projects

MCP packages already target .NET 10. The ModelContextProtocol packages I restored this week include assets for net8.0, net9.0 and net10.0 (and netstandard2.0 for the core), so retargeting does not require a different package. Keep all the MCP packages on the same version, because mixing them produces a NuGet version conflict (NU1107). My notes on the C# SDK 2.x releases list what changed.
The MCP project template needs the .NET 10 SDK. Microsoft's quickstart says installing the Microsoft.McpServer.ProjectTemplates package and running dotnet new mcpserver requires the .NET 10 SDK. Another reason to have it installed.
Microsoft.Extensions.AI follows the .NET version. The 10.x line (10.11.0 was the newest I found) is the one that matches .NET 10. Move the AI packages and the framework together, and run your evaluation tests, because a package update can change model call behaviour.
File-based apps. The MCP package page notes the #:package directive for C# file-based apps, available since .NET 10 preview 4. Handy for a one-file MCP tool, and it needs the .NET 10 SDK.
Container tool packages. If you ship a server as a self-contained NuGet tool, rebuild and republish after retargeting so users get a runtime that is still supported.

What I did not do

I did not migrate a large solution for this post, so I have no measured performance numbers. The guidance above is the process, backed by Microsoft's published dates and by the packages I restored. Your own tests are the real checklist.

If you cannot finish by Monday

Applications on .NET 8 and 9 do not stop on November 10, so there is no emergency shutdown. The risk is that new vulnerabilities will not be patched. Prioritise what is internet-facing, which includes any MCP server reachable from outside your network, and move those first.