.NET 8 End of Support Explained: Upgrade to .NET 10 Before 10 November 2026

Nothing breaks on the day, and that is the trap. Your app keeps starting and serving requests, but from 10 November 2026 Microsoft no longer fixes the next security hole in the .NET 8 runtime.

The dotnet 8 end of support deadline also covers .NET 9, which ends on the same day. Both dates come from Microsoft's .NET support policy page.

Picture a common setup. A services team in Pune looks after twelve ASP.NET Core web APIs for a bank client, all built for .NET 8 and shipped as Docker containers through a CI pipeline. The setup is made up, but the deadline is real.

If they wait, December can bring the problem. A scanner in the client's security review flags the base image, because a new runtime bug is fixed in .NET 10 but not in .NET 8. Twelve services then get upgraded under pressure.

This guide follows that team. You will see what end of support means, how .NET picks a runtime, where the version hides in a real project and how to move to .NET 10 safely.

You need six terms. Each one gets a plain meaning and a link to the running example.

• Runtime: the part of .NET that actually runs your compiled app on a server. Example: the team's servers run the ASP.NET Core runtime 8.0.33.
• SDK (software development kit): the tools that build your app, including the dotnet command. Each SDK can only build for .NET versions up to its own.
• Target framework: the .NET version your project is built for, written in the project file as a short name like net8.0 or net10.0.
• Patch version: the last number, as in 8.0.33. Patches fix bugs and security holes without changing features, and each patch includes all earlier ones.
• Base image: the ready-made Docker image your container starts from, such as mcr.microsoft.com/dotnet/aspnet:8.0. It carries the runtime inside it.
• Framework-dependent vs self-contained: a framework-dependent app uses the runtime installed on the machine. A self-contained app carries its own copy of the runtime inside its files.

.NET 8 reaches end of support on Tuesday 10 November 2026. From then on, Microsoft gives no more fixes, updates or online technical help for it. .NET 9 ends on the same day.

Microsoft defines end of life as the date it no longer provides fixes, updates or online technical assistance. It says end of life is also called end of support. The dates fall on Patch Tuesday, the second Tuesday of the month.

The 25 October patches were an out-of-band release, meaning one shipped outside the monthly schedule. The main fix, CVE-2026-111497, is a Brotli decoder out-of-bounds write.

It matters if your app decompresses Brotli data. The release notes say ASP.NET Core request decompression and HttpClient automatic decompression are not on by default, but direct use of the Brotli APIs is affected. The release also completes the fix for CVE-2026-70197, which the 13 October patch did not fully address.

A third fix, CVE-2026-114148, corrects file ownership in some Linux tarballs. The notes warn that downloading a new archive does not fix ownership in an existing installation.

Install the latest 8.0 patch before 10 November 2026, even if you plan to upgrade. Microsoft's policy says a system must have the latest patch to count as supported.

8.0.33 may not be the final one. Microsoft shipped 6.0.36 on the .NET 6 end-of-support day, and 7.0.20 on 28 May 2024, two weeks after .NET 7 ended. Check the releases page on 10 November and in the weeks after.

The only difference is how long Microsoft patches the release. LTS (long-term support) releases get three years of free support and patches. STS (standard-term support) releases get two years.

A new major version ships every November. Even numbers, like 8 and 10, are LTS. Odd numbers, like 9 and 11, are STS. Microsoft's policy says the quality of all releases is the same.

Each release first gets active support, with feature fixes and security fixes. The final six months are maintenance, with security fixes only. Then it is out of support.

STS used to mean 18 months. In September 2025, Microsoft extended STS to 24 months, starting with .NET 9. That change is why .NET 9 and .NET 8 end on the same day.

For the Pune team this settles the target. Moving to .NET 9 would buy zero extra days. .NET 10 gives two more years of patches, until 14 November 2028.

No. End of support stops new patches; it does not turn off installed runtimes. Microsoft's definition covers fixes, updates and technical help, and says nothing about apps stopping.

Three things keep working after 10 November 2026:

• Installed runtimes: Microsoft's policy describes no switch-off. An app built for net8.0 keeps using whatever 8.0 runtime is installed, unpatched from then on.
• Container images: the dotnet-docker tag policy says unsupported tags and images can still be pulled, but they will no longer receive updates for any reason.
• AWS Lambda: the runtimes page says you can keep invoking functions on a deprecated runtime indefinitely. It lists dotnet8 deprecation on 10 November 2026 as a forecast date.

What changes is risk. Every security bug found after that day stays open on 8.0. Security scanners and audit reviews can then flag your images and servers, as in the Pune team's December review.

Microsoft stops patching, but some third-party companies sell paid security support for .NET 8 after that date. That is a commercial contract with its own terms, not Microsoft support.

A framework-dependent app asks for a major version in a small file next to it, and the dotnet host looks for a matching runtime. If it finds no 8.x runtime, a net8.0 app does not quietly move to .NET 10.

The dotnet host is the small launcher behind the dotnet command. Every test in this guide ran on Ubuntu 24.04's own .NET packages: SDK 10.0.113 with runtime 10.0.13, and SDK 8.0.132 with runtime 8.0.32.

When you build, the SDK writes a file called APPNAME.runtimeconfig.json next to your app. Here is the one for a tiny console app built for net8.0, from SDK 10.0.113:

{
  "runtimeOptions": {
    "tfm": "net8.0",
    "framework": {
      "name": "Microsoft.NETCore.App",
      "version": "8.0.0"
    },
    "configProperties": {
      "System.Reflection.Metadata.MetadataUpdater.IsSupported": false,
      "System.Runtime.Serialization.EnableUnsafeBinaryFormatterSerialization": false
    }
  }
}

The version 8.0.0 is a minimum, not an exact match. The default roll-forward policy is called Minor. If any 8.x runtime is installed, the host picks the newest 8.0 patch it finds.

We tested the No path on a machine with only the .NET 10.0.13 runtime. The net8.0 app refused to start and the dotnet command exited with code 150:

$ dotnet HelloApp.dll
You must install or update .NET to run this application.

App: /path/to/app/bin/Release/net8.0/HelloApp.dll
Architecture: x64
Framework: 'Microsoft.NETCore.App', version '8.0.0' (x64)
.NET location: /path/to/dotnet/

The following frameworks were found:
  10.0.13 at [/path/to/dotnet/shared/Microsoft.NETCore.App]
$ echo $?
150
(the Learn more and download link lines are trimmed)

Setting the environment variable DOTNET_ROLL_FORWARD=Major made the same file run on .NET 10.0.13. The project property RollForward set to Major does the same, by writing rollForward into runtimeconfig.json.

Major picks the next major version installed, not the newest. In a host-selection test with runtime folders named 9.x and 10.x, Major chose 9.x and LatestMajor chose 10.x. .NET 9 ends on the same day as .NET 8.

In six places, and the upgrade is done only when all six agree. Teams usually remember the project file and forget the base image or the CI step.

The NuGet row needs care. Microsoft's EF Core docs say EF Core 10 requires the .NET 10 SDK to build and the .NET 10 runtime to run. Update framework packages together with the target framework.

The CI row surprises people. The setup-dotnet README says that unless global.json names a version, the runner uses its latest installed SDK, including preinstalled ones. So pin the SDK in global.json.

To find pins in a repository, search for the old version strings. This search looks for .NET 8 and .NET 9, since both end on 10 November 2026. We tested it with GNU grep on Linux:

grep -rnE '\bnet[89]\.0|dotnet/[a-z/-]+:[89]\.0|\b[89]\.0\.([0-9]+|\*)|\b[89]\.(0\.)?x\b' \
  --include='*.csproj' --include='*.fsproj' --include='*.vbproj' \
  --include='*.props' --include='*.targets' --include='Dockerfile*' \
  --include='*.yml' --include='*.yaml' --include='global.json' .

We planted nine .NET 8 pins in a sample repository, from project files and global.json to a runtime-deps image and CI versions. The search found all nine, and nothing in a clean .NET 10 copy.

A second sample added net9.0, unquoted SDK versions, a nightly image and Version 8.0.*, and all were found. It missed a version passed through a Dockerfile ARG and a devcontainer.json file. A third sample showed it also misses short CI forms such as dotnet-version: '8.0' or 8, and files named api.Dockerfile or Containerfile.

Files outside the include list, such as Bicep or Terraform, are not searched at all. Read every hit by hand, because third-party packages on 8.0.N or 9.0.N versions match too, such as Swashbuckle.AspNetCore 9.0.4.

Install the .NET 10 SDK, change the target framework, update packages, build, test, then change the image and CI. Microsoft's upgrade page says the only required change is the TargetFramework property; everything else follows from the build output.

1. 1

   Patch .NET 8 first

   Move every server and image to the latest 8.0 patch, 8.0.33 as of 26 October 2026. Check again on 10 November and in the weeks after.

2. 2

   Install the .NET 10 SDK

   Run dotnet --list-sdks and check that a 10.0 line appears. Without it, net10.0 builds fail with NETSDK1045.

3. 3

   Change the target framework

   Edit TargetFramework from net8.0 to net10.0 in each project file, or once in Directory.Build.props if your solution sets it there.

4. 4

   Update framework packages

   Move ASP.NET Core, EF Core and other Microsoft framework packages from 8.x to 10.x versions, all in the same change.

5. 5

   Build and read every warning

   Run dotnet build. Then read Microsoft's breaking-change lists for .NET 9 and .NET 10, because a jump from 8 skips over 9.

6. 6

   Run the tests and check the runtime

   Run your test suite. Then confirm the app reports a 10.0 runtime, using the check in the next section.

7. 7

   Change the base image and CI

   Change FROM lines from 8.0 to 10.0 tags and the CI SDK version from 8.0.x to 10.0.x. Rebuild the image.

8. 8

   Roll out one service at a time

   Deploy one service, watch errors and latency, and keep the last patched 8.0 image ready as a rollback until that service runs cleanly on .NET 10.

Here is the one-line change on the test project, after dotnet new console created it for net8.0:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net10.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>

</Project>

Ask the running app which runtime it is on. Two lines of C# print the target framework and the actual runtime, which together prove both the build and the host are on .NET 10.

using System.Runtime.InteropServices;

Console.WriteLine($"Built for:   {AppContext.TargetFrameworkName}");
Console.WriteLine($"Running on:  {RuntimeInformation.FrameworkDescription}");

Before the change, dotnet run printed the first block below. After changing net8.0 to net10.0, it printed the second. Your patch number will differ, so check the major version.

# TargetFramework net8.0
Built for:   .NETCoreApp,Version=v8.0
Running on:  .NET 8.0.32

# TargetFramework net10.0
Built for:   .NETCoreApp,Version=v10.0
Running on:  .NET 10.0.13

On a server or inside a container, run dotnet --list-runtimes. You should see a Microsoft.NETCore.App line starting with 10.0, plus Microsoft.AspNetCore.App 10.0 for web apps. Microsoft's latest patch on 26 October 2026 is 10.0.14.

Two things: the 8.0 tags stop getting updates after 10 November 2026, and the default 10.0 tags are built on Ubuntu instead of Debian. Both affect what your next image rebuild contains.

The official image tags like aspnet:8.0 are floating tags. The dotnet-docker documentation says a floating tag always points to the latest patch of that release. It keeps being updated only for the supported life of that .NET release.

So after 10 November, rebuilding from aspnet:8.0 gives you the same unpatched runtime every time. Fixes in the operating system layer stop too, because the policy says unsupported tags get no updates for any reason.

Microsoft's .NET 10 breaking-change notes say default tags, those that name no operating system, now use Ubuntu. For example, sdk:10.0 refers to Ubuntu 24.04 Noble Numbat. Debian images are not shipped for .NET 10.

• If your Dockerfile runs apt-get install, those package names come from Ubuntu now. Test the build, even though Microsoft says most users will not be affected.
• If you need Debian, Microsoft says you may have to build and maintain your own image.
• If your app is self-contained, the base image does not carry its runtime. You must republish the app with the .NET 10 SDK, because Microsoft's patches do not reach self-contained apps by themselves.

The .NET SDK has a warning for this, NETSDK1138, and you can turn it into a build error. But on 26 October 2026 it does not fire for net8.0 yet, so do not rely on it alone.

With SDK 10.0.113, building a project that targets net7.0 printed this warning:

warning NETSDK1138: The target framework 'net7.0' is out of support and will not receive security updates in the future. Please refer to https://aka.ms/dotnet-core-support for more information about the support policy.

Adding -p:WarningsAsErrors=NETSDK1138 turned the same line into error NETSDK1138, which fails a CI job. Setting CheckEolTargetFramework to false silenced it completely.

The warning comes from a list baked into each SDK

The SDK does not check dates. It reads a fixed list of version numbers from a file named Microsoft.NET.EolTargetFrameworks.targets. In SDK 10.0.113 that list is 1.0 to 3.1, 5.0, 6.0 and 7.0.

Building net8.0 with WarningsAsErrors on that SDK gave 0 warnings and 0 errors. The same list sits in the dotnet/sdk source on the main, release/10.0.1xx and release/10.0.4xx branches, as of 26 October 2026.

Those branch names are SDK feature bands. Microsoft's versioning docs say the SDK's third number carries its feature release in the hundreds digit. So 10.0.113 and 10.0.403 are both .NET 10 SDKs from different feature bands.

So nothing in your build changes on 10 November by itself. The warning for net8.0 can only appear after you install an SDK whose list includes 8.0. This is undocumented as of 26 October 2026; re-check whenever you move your SDK pin.

Class libraries skip the warning by default

The same file only turns the check on when OutputType is not Library. When we switched the net7.0 test project to a class library, NETSDK1138 did not appear at all.

Shared libraries are common in large solutions, so scan them with the grep search above instead. A library can also target both versions while apps move over, using TargetFrameworks net8.0;net10.0, and we built that successfully with SDK 10.0.113.

An old SDK in CI fails loudly

If CI or global.json still pins an 8.0 SDK, a net10.0 project fails. With global.json pinned to SDK 8.0.132, the build stopped with error NETSDK1045: the current .NET SDK does not support targeting .NET 10.0.

Turn the search into a CI gate

Run the search from earlier as a CI step that fails when it finds anything. Do not write it as ! grep followed by the pattern: under bash -e, a failed ! grep is ignored when more commands follow it.

This step saves the hits to a file, stops if grep itself errors, skips third-party packages you have checked, and fails on anything left. Here Serilog.AspNetCore is the example exclusion:

set +e
grep -rnE '\bnet[89]\.0|dotnet/[a-z/-]+:[89]\.0|\b[89]\.0\.([0-9]+|\*)|\b[89]\.(0\.)?x\b' \
  --include='*.csproj' --include='*.fsproj' --include='*.vbproj' \
  --include='*.props' --include='*.targets' --include='Dockerfile*' \
  --include='*.yml' --include='*.yaml' --include='global.json' . > old-pins.txt
status=$?
set -e
if [ "$status" -gt 1 ]; then echo "Search failed"; exit 2; fi
if grep -v -e 'Serilog\.AspNetCore' old-pins.txt; then
  echo "Old .NET 8 or 9 pins found"
  exit 1
fi

We ran it the way GitHub Actions runs bash, with -e and pipefail and another command after it. It failed with exit 1 on both pin samples, passed on the clean copy and exited 2 when the search folder was missing.

Neither. .NET 9 ends on the same day as .NET 8, and .NET 11 was not a final release as of 26 October 2026. .NET 10 is the only supported LTS target in October 2026.

The dotnet/core releases index lists .NET 11 at 11.0.0-rc.3, released 25 October 2026, with release type STS and phase go-live. Go-live means Microsoft supports release candidates in production, but it is still not a final release.

Under the two-year STS rule, .NET 11 would end around November 2028, about when .NET 10 does. That date is derived from the policy as of 26 October 2026, since Microsoft has not published it. Waiting buys no extra support, only a start past the deadline.

Anything built on .NET 8 or .NET 9 inherits the deadline. Two cases matter for most teams: PowerShell and serverless functions.

• PowerShell: Microsoft's PowerShell lifecycle page lists PowerShell 7.4 (on .NET 8) and 7.5 (on .NET 9) ending on 10 November 2026. PowerShell 7.6 LTS, on .NET 10, runs to 14 November 2028.
• AWS Lambda: the Lambda runtimes page lists dotnet8 deprecation on 10 November 2026. It calls these forecast dates, subject to change. It blocks creating dotnet8 functions from 29 July 2027 and updating them from 31 August 2027.
• Visual Studio and tools: your editor and build agents may ship their own SDKs. Check dotnet --list-sdks on every build machine, not just your laptop.

For the Pune team, the PowerShell line also matters. Their deployment scripts run on build agents, and those agents need PowerShell 7.6 before December's review.

Treat it as a fleet rollout with a deadline, not a code change. Interviewers want to hear inventory, risk, rollout order and rollback.

1. 1

   State the constraint

   Security patches for .NET 8 stop on 10 November 2026. Apps keep running, so the risk is silent exposure, not an outage.

2. 2

   Inventory every pin

   Project files, global.json, packages, base images, CI and hosts. Name the tools: dotnet --list-runtimes on hosts and a repository search.

3. 3

   Reduce risk first

   Patch everything to the latest 8.0 release first. This buys time and shows you separate urgent fixes from planned change.

4. 4

   Upgrade in waves

   Start with a low-traffic service, then shared libraries targeting both versions, then the busiest services last. Each goes out as a canary first, meaning a small slice of traffic.

5. 5

   Prove it and keep a way back

   Check the runtime each service reports, watch error rates, and keep the last patched 8.0 image ready for rollback until each wave settles.

6. 6

   Prevent the next deadline

   Add a CI check for old versions and put the .NET 10 end date, 14 November 2028, in the team calendar.