dotnet · ViktorHofer · Nov 20, 2025 · Nov 20, 2025 · Dec 2, 2025 · Dec 2, 2025
diff --git a/Directory.Build.props b/Directory.Build.props
@@ -57,19 +57,19 @@
 
   <!-- The TFMs to build and test against. -->
   <PropertyGroup>
-    <NetCoreAppCurrentVersion>10.0</NetCoreAppCurrentVersion>
+    <NetCoreAppCurrentVersion>11.0</NetCoreAppCurrentVersion>
     <NetCoreAppCurrentIdentifier>.NETCoreApp</NetCoreAppCurrentIdentifier>
     <NetCoreAppCurrentTargetFrameworkMoniker>$(NetCoreAppCurrentIdentifier),Version=v$(NetCoreAppCurrentVersion)</NetCoreAppCurrentTargetFrameworkMoniker>
     <MicrosoftNetCoreAppFrameworkName>Microsoft.NETCore.App</MicrosoftNetCoreAppFrameworkName>
     <NetCoreAppCurrentBrandName>.NET $(NetCoreAppCurrentVersion)</NetCoreAppCurrentBrandName>
     <NetCoreAppCurrent>net$(NetCoreAppCurrentVersion)</NetCoreAppCurrent>
 
     <!-- The previous supported .NET version. -->
-    <NetCoreAppPrevious>net9.0</NetCoreAppPrevious>
-    <NetCoreAppPrevious Condition="'$(DotNetBuildSourceOnly)' == 'true'">$(NetCoreAppCurrent)</NetCoreAppPrevious>
+    <NetCoreAppPrevious />
+    <!-- <NetCoreAppPrevious Condition="'$(DotNetBuildSourceOnly)' == 'true'">$(NetCoreAppCurrent)</NetCoreAppPrevious> -->
 
     <!-- The minimum supported .NET version. -->
-    <NetCoreAppMinimum>net8.0</NetCoreAppMinimum>
+    <NetCoreAppMinimum>net10.0</NetCoreAppMinimum>
     <NetCoreAppMinimum Condition="'$(DotNetBuildSourceOnly)' == 'true'">$(NetCoreAppCurrent)</NetCoreAppMinimum>
 
     <!-- when this is updated, make sure to keep $(_NetCoreAppToolCurrent)
@@ -87,8 +87,8 @@
     <NetFrameworkToolCurrent Condition="'$(DotNetBuildSourceOnly)' == 'true'" />
     <NetFrameworkCurrent Condition="'$(DotNetBuildSourceOnly)' == 'true'" />
 
-    <ApiCompatNetCoreAppBaselineVersion>9.0.0</ApiCompatNetCoreAppBaselineVersion>
-    <ApiCompatNetCoreAppBaselineTFM>net9.0</ApiCompatNetCoreAppBaselineTFM>
+    <ApiCompatNetCoreAppBaselineVersion>10.0.0</ApiCompatNetCoreAppBaselineVersion>
+    <ApiCompatNetCoreAppBaselineTFM>net10.0</ApiCompatNetCoreAppBaselineTFM>
   </PropertyGroup>
 
   <PropertyGroup Label="CalculateConfiguration">

diff --git a/docs/coding-guidelines/adding-api-guidelines.md b/docs/coding-guidelines/adding-api-guidelines.md
@@ -24,8 +24,8 @@ the implementation without compat concerns in future releases.
 
 ### Determine target framework
 
-`net10.0` is the target framework version currently under development and the new apis
-should be added to `net10.0`. [More Information on TargetFrameworks](https://learn.microsoft.com/dotnet/standard/frameworks)
+`net11.0` is the target framework version currently under development and the new apis
+should be added to `net11.0`. [More Information on TargetFrameworks](https://learn.microsoft.com/dotnet/standard/frameworks)
 
 ## Making the changes in repo
 

diff --git a/docs/coding-guidelines/project-guidelines.md b/docs/coding-guidelines/project-guidelines.md
@@ -25,7 +25,7 @@ Below is a list of all the various options we pivot the project builds on:
 ## Individual build properties
 The following are the properties associated with each build pivot
 
-- `$(BuildTargetFramework) -> Any .NETCoreApp or .NETFramework TFM, e.g. net10.0`
+- `$(BuildTargetFramework) -> Any .NETCoreApp or .NETFramework TFM, e.g. net11.0`
 - `$(TargetOS) -> windows | linux | osx | freebsd | ... | [defaults to running OS when empty]`
 - `$(Configuration) -> Debug | Release | [defaults to Debug when empty]`
 - `$(TargetArchitecture) - x86 | x64 | arm | arm64 | [defaults to x64 when empty]`
@@ -59,7 +59,7 @@ A cross-targeting project which targets specific platform with `$(NetCoreAppCurr
 A full or individual project build is centered around BuildTargetFramework, TargetOS, Configuration and TargetArchitecture.
 
 1. `$(BuildTargetFramework), $(TargetOS), $(Configuration), $(TargetArchitecture)` can individually be passed in to change the default values.
-2. If nothing is passed to the build then we will default value of these properties from the environment. Example: `net10.0-[TargetOS Running On]-Debug-x64`.
+2. If nothing is passed to the build then we will default value of these properties from the environment. Example: `net11.0-[TargetOS Running On]-Debug-x64`.
 3. When building an individual project (either from the CLI or an IDE), all target frameworks are built.
 
 Any of the mentioned properties can be set via `/p:<Property>=<Value>` at the command line. When building using any of the wrapper scripts around it (i.e. build.cmd) a number of these properties have aliases which make them easier to pass (run build.cmd/sh -? for the aliases).

diff --git a/docs/project/dogfooding.md b/docs/project/dogfooding.md
@@ -124,8 +124,8 @@ This is the default case for applications - running against an installed .NET ru
 ```XML
   <PropertyGroup>
     <OutputType>Exe</OutputType>
-    <!-- Ensure that the target framework is correct e.g. 'net10.0' -->
-    <TargetFramework>net10.0</TargetFramework>
+    <!-- Ensure that the target framework is correct e.g. 'net11.0' -->
+    <TargetFramework>net11.0</TargetFramework>
     <!-- modify version in this line with one reported by `dotnet --info` under ".NET runtimes installed" -> Microsoft.NETCore.App -->
     <RuntimeFrameworkVersion>9.0.0-preview.5.22224.3</RuntimeFrameworkVersion>
   </PropertyGroup>
@@ -147,8 +147,8 @@ make it self-contained by adding a RuntimeIdentifier (RID).
 ```XML
   <PropertyGroup>
     <OutputType>Exe</OutputType>
-    <!-- Ensure that the target framework is correct e.g. 'net10.0' -->
-    <TargetFramework>net10.0</TargetFramework>
+    <!-- Ensure that the target framework is correct e.g. 'net11.0' -->
+    <TargetFramework>net11.0</TargetFramework>
     <!-- modify build in this line with version reported by `dotnet --info` as above under ".NET runtimes installed" -> Microsoft.NETCore.App -->
     <!-- moreover, this can be any valid Microsoft.NETCore.App package version from https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet9/nuget/v3/index.json -->
     <RuntimeFrameworkVersion>9.0.0-preview.5.22224.3</RuntimeFrameworkVersion>
@@ -159,7 +159,7 @@ make it self-contained by adding a RuntimeIdentifier (RID).
 ```
 $ dotnet restore
 $ dotnet publish
-$ bin\Debug\net10.0\win-x64\publish\App.exe
+$ bin\Debug\net11.0\win-x64\publish\App.exe
 ```
 
 ### Daily builds table

diff --git a/docs/workflow/building/coreclr/nativeaot.md b/docs/workflow/building/coreclr/nativeaot.md
@@ -33,7 +33,7 @@ The paths to major components can be overridden using `IlcToolsPath`, `IlcSdkPat
 Run `build[.cmd|.sh] -c Release` from the repo root to build the NativeAOT toolchain packages. The build will place the toolchain packages at `artifacts\packages\Release\Shipping`. To publish your project using these packages:
 
 * Add the package directory to your `nuget.config` file. For example, add `<add key="local" value="C:\runtime\artifacts\packages\Release\Shipping" />`
-* Run `dotnet add package Microsoft.DotNet.ILCompiler -v 10.0.0-dev` to add the local package reference to your project.
+* Run `dotnet add package Microsoft.DotNet.ILCompiler -v 11.0.0-dev` to add the local package reference to your project.
 * Run `dotnet publish --packages pkg -r [win-x64|linux-x64|osx-64] -c [Debug|Release]` to publish your project. `--packages pkg` option restores the package into a local directory that is easy to cleanup once you are done. It avoids polluting the global nuget cache with your locally built dev package.
 
 ## High Level Overview

diff --git a/docs/workflow/building/coreclr/wasm.md b/docs/workflow/building/coreclr/wasm.md
@@ -64,7 +64,7 @@ You can also run the runtime directly in Node.js:
 In script below please replace `/path/to/runtime/` by a **absolute unix path** to the actual runtime repo (even on Windows).
 
 ```bash
-cp ./artifacts/bin/microsoft.netcore.app.runtime.browser-wasm/Debug/runtimes/browser-wasm/lib/net10.0/*.dll ./artifacts/bin/coreclr/browser.wasm.Debug/IL
+cp ./artifacts/bin/microsoft.netcore.app.runtime.browser-wasm/Debug/runtimes/browser-wasm/lib/net11.0/*.dll ./artifacts/bin/coreclr/browser.wasm.Debug/IL
 cp helloworld.dll ./artifacts/bin/coreclr/browser.wasm.Debug/IL
 cd ./artifacts/bin/coreclr/browser.wasm.Debug/
 node ./corerun.js -c /path/to/runtime/artifacts/bin/coreclr/browser.wasm.Debug/IL /path/to/runtime/artifacts/bin/coreclr/browser.wasm.Debug/IL/helloworld.dll
@@ -75,7 +75,7 @@ node ./corerun.js -c /path/to/runtime/artifacts/bin/coreclr/browser.wasm.Debug/I
 You can also run the corehost directly in Node.js:
 
 ```bash
-cp ./artifacts/bin/microsoft.netcore.app.runtime.browser-wasm/Debug/runtimes/browser-wasm/lib/net10.0/*.dll ./artifacts/bin/coreclr/browser.wasm.Debug/corehost
+cp ./artifacts/bin/microsoft.netcore.app.runtime.browser-wasm/Debug/runtimes/browser-wasm/lib/net11.0/*.dll ./artifacts/bin/coreclr/browser.wasm.Debug/corehost
 cp helloworld.dll ./artifacts/bin/coreclr/browser.wasm.Debug/corehost
 cd ./artifacts/bin/coreclr/browser.wasm.Debug/corehost
 node ./main.mjs

diff --git a/docs/workflow/building/libraries/README.md b/docs/workflow/building/libraries/README.md
@@ -76,7 +76,7 @@ The libraries build has two logical components, the native build which produces
 
 The build settings (BuildTargetFramework, TargetOS, Configuration, Architecture) are generally defaulted based on where you are building (i.e. which OS or which architecture) but we have a few shortcuts for the individual properties that can be passed to the build scripts:
 
-- `-framework|-f` identifies the target framework for the build. Possible values include `net10.0` (currently the latest .NET version) or `net481` (the latest .NET Framework version). (msbuild property `BuildTargetFramework`)
+- `-framework|-f` identifies the target framework for the build. Possible values include `net11.0` (currently the latest .NET version) or `net481` (the latest .NET Framework version). (msbuild property `BuildTargetFramework`)
 - `-os` identifies the OS for the build. It defaults to the OS you are running on but possible values include `windows`, `unix`, `linux`, or `osx`. (msbuild property `TargetOS`)
 - `-configuration|-c Debug|Release` controls the optimization level the compilers use for the build. It defaults to `Debug`. (msbuild property `Configuration`)
 - `-arch` identifies the architecture for the build. It defaults to `x64` but possible values include `x64`, `x86`, `arm`, or `arm64`. (msbuild property `TargetArchitecture`)

diff --git a/docs/workflow/building/libraries/cross-building.md b/docs/workflow/building/libraries/cross-building.md
@@ -46,30 +46,30 @@ To build native runtime libraries for arm:
 
     $ ROOTFS_DIR=`pwd`/.tools/rootfs/arm ./build.sh libs.native --cross --arch arm --librariesConfiguration Release
 
-Build artifacts can be found in `artifacts/bin/native/net10.0-<TargetOS>-<BuildArch>-<BuildType>/`:
-
-    $ ls artifacts/bin/native/net10.0-Linux-Release-arm/*
-    artifacts/bin/native/net10.0-Linux-Release-arm/libSystem.Globalization.Native.a
-    artifacts/bin/native/net10.0-Linux-Release-arm/libSystem.Globalization.Native.so
-    artifacts/bin/native/net10.0-Linux-Release-arm/libSystem.Globalization.Native.so.dbg
-    artifacts/bin/native/net10.0-Linux-Release-arm/libSystem.IO.Compression.Native.a
-    artifacts/bin/native/net10.0-Linux-Release-arm/libSystem.IO.Compression.Native.so
-    artifacts/bin/native/net10.0-Linux-Release-arm/libSystem.IO.Compression.Native.so.dbg
-    artifacts/bin/native/net10.0-Linux-Release-arm/libSystem.IO.Ports.Native.a
-    artifacts/bin/native/net10.0-Linux-Release-arm/libSystem.IO.Ports.Native.so
-    artifacts/bin/native/net10.0-Linux-Release-arm/libSystem.IO.Ports.Native.so.dbg
-    artifacts/bin/native/net10.0-Linux-Release-arm/libSystem.Native.a
-    artifacts/bin/native/net10.0-Linux-Release-arm/libSystem.Native.so
-    artifacts/bin/native/net10.0-Linux-Release-arm/libSystem.Native.so.dbg
-    artifacts/bin/native/net10.0-Linux-Release-arm/libSystem.Net.Security.Native.a
-    artifacts/bin/native/net10.0-Linux-Release-arm/libSystem.Net.Security.Native.so
-    artifacts/bin/native/net10.0-Linux-Release-arm/libSystem.Net.Security.Native.so.dbg
-    artifacts/bin/native/net10.0-Linux-Release-arm/libSystem.Security.Cryptography.Native.OpenSsl.a
-    artifacts/bin/native/net10.0-Linux-Release-arm/libSystem.Security.Cryptography.Native.OpenSsl.so
-    artifacts/bin/native/net10.0-Linux-Release-arm/libSystem.Security.Cryptography.Native.OpenSsl.so.dbg
-
-    $ file artifacts/bin/native/net10.0-linux-release-arm/libSystem.Native.so
-    artifacts/bin/native/net10.0-linux-release-arm/libSystem.Native.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, BuildID[sha1]=5f6f6f9c4012dffed133624867adf32ac2af130d, stripped
+Build artifacts can be found in `artifacts/bin/native/net11.0-<TargetOS>-<BuildArch>-<BuildType>/`:
+
+    $ ls artifacts/bin/native/net11.0-Linux-Release-arm/*
+    artifacts/bin/native/net11.0-Linux-Release-arm/libSystem.Globalization.Native.a
+    artifacts/bin/native/net11.0-Linux-Release-arm/libSystem.Globalization.Native.so
+    artifacts/bin/native/net11.0-Linux-Release-arm/libSystem.Globalization.Native.so.dbg
+    artifacts/bin/native/net11.0-Linux-Release-arm/libSystem.IO.Compression.Native.a
+    artifacts/bin/native/net11.0-Linux-Release-arm/libSystem.IO.Compression.Native.so
+    artifacts/bin/native/net11.0-Linux-Release-arm/libSystem.IO.Compression.Native.so.dbg
+    artifacts/bin/native/net11.0-Linux-Release-arm/libSystem.IO.Ports.Native.a
+    artifacts/bin/native/net11.0-Linux-Release-arm/libSystem.IO.Ports.Native.so
+    artifacts/bin/native/net11.0-Linux-Release-arm/libSystem.IO.Ports.Native.so.dbg
+    artifacts/bin/native/net11.0-Linux-Release-arm/libSystem.Native.a
+    artifacts/bin/native/net11.0-Linux-Release-arm/libSystem.Native.so
+    artifacts/bin/native/net11.0-Linux-Release-arm/libSystem.Native.so.dbg
+    artifacts/bin/native/net11.0-Linux-Release-arm/libSystem.Net.Security.Native.a
+    artifacts/bin/native/net11.0-Linux-Release-arm/libSystem.Net.Security.Native.so
+    artifacts/bin/native/net11.0-Linux-Release-arm/libSystem.Net.Security.Native.so.dbg
+    artifacts/bin/native/net11.0-Linux-Release-arm/libSystem.Security.Cryptography.Native.OpenSsl.a
+    artifacts/bin/native/net11.0-Linux-Release-arm/libSystem.Security.Cryptography.Native.OpenSsl.so
+    artifacts/bin/native/net11.0-Linux-Release-arm/libSystem.Security.Cryptography.Native.OpenSsl.so.dbg
+
+    $ file artifacts/bin/native/net11.0-linux-release-arm/libSystem.Native.so
+    artifacts/bin/native/net11.0-linux-release-arm/libSystem.Native.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, BuildID[sha1]=5f6f6f9c4012dffed133624867adf32ac2af130d, stripped
 
 
 Compile managed runtime libraries on Linux
@@ -88,7 +88,7 @@ Note that by default ILLinker trimming is enabled and libraries built above for
 
     $ ./build.sh libs.sfx --arch arm --librariesConfiguration Release /p:ILLinkTrimAssembly=false
 
-Build artifacts can be found in `artifacts/bin/microsoft.netcore.app.runtime.<TargetOS>-<BuildArch>/<BuildType>/runtimes/<TargetOS>-<BuildArch>/lib/net10.0/`. For more details on the build configurations see [project-guidelines](/docs/coding-guidelines/project-guidelines.md).
+Build artifacts can be found in `artifacts/bin/microsoft.netcore.app.runtime.<TargetOS>-<BuildArch>/<BuildType>/runtimes/<TargetOS>-<BuildArch>/lib/net11.0/`. For more details on the build configurations see [project-guidelines](/docs/coding-guidelines/project-guidelines.md).
 
 Both native and managed runtime libraries can be built at the same time with:
 

diff --git a/docs/workflow/ci/triaging-failures.md b/docs/workflow/ci/triaging-failures.md
@@ -23,7 +23,7 @@ and for libraries runs is defined [here](../../../eng/pipelines/libraries/helix-
 
 Many test runs use a non-default product configuration, to allow re-using existing test assets to stress various aspects of the system.
 Determine the precise test configuration under which the test has failed. This might be evident from the test job name. For example,
-`net10.0-windows-Release-x86-CoreCLR_checked-jitstress1-Windows.10.Amd64.Open` is a libraries test run on Windows with a Release x86 libraries
+`net11.0-windows-Release-x86-CoreCLR_checked-jitstress1-Windows.10.Amd64.Open` is a libraries test run on Windows with a Release x86 libraries
 build, Checked coreclr build, and setting the `DOTNET_JitStress=1` configuration setting, in the `Windows.10.Amd64.Open` Helix queue.
 
 You need to be careful when reproducing failures to set all the correct environment variables. In the above example, if you look at the

diff --git a/docs/workflow/debugging/coreclr/debugging-runtime.md b/docs/workflow/debugging/coreclr/debugging-runtime.md
@@ -55,7 +55,7 @@ Visual Studio's capabilities as a full IDE provide a lot of help making the runt
 5. Set `Command=$(SolutionDir)\..\..\..\..\bin\coreclr\windows.$(Platform).$(Configuration)\corerun.exe`. This points to the folder where the built runtime binaries are present.
 6. Set `Command Arguments=<managed app you wish to run>` (e.g. HelloWorld.dll).
 7. Set `Working Directory=$(SolutionDir)\..\..\..\..\bin\coreclr\windows.$(Platform).$(Configuration)`. This points to the folder containing CoreCLR binaries.
-8. Set `Environment=CORE_LIBRARIES=$(SolutionDir)\..\..\..\..\bin\runtime\<target-framework>-windows-$(Configuration)-$(Platform)`, where '\<target-framework\>' is the target framework of current branch: `net10.0`. A few notes on this step:
+8. Set `Environment=CORE_LIBRARIES=$(SolutionDir)\..\..\..\..\bin\runtime\<target-framework>-windows-$(Configuration)-$(Platform)`, where '\<target-framework\>' is the target framework of current branch: `net11.0`. A few notes on this step:
 
 * This points to the folder containing core libraries except `System.Private.CoreLib`.
 * This step can be skipped if you are debugging CLR tests that reference only `System.Private.CoreLib`. Otherwise, it's required to debug a real-world application that references anything else, including `System.Runtime`.
@@ -85,7 +85,7 @@ Steps 1-9 only need to be done once as long as there's been no changes to the CM
         },
         {
           "name": "CORE_LIBRARIES",
-          // for example net10.0-windows-debug-x64
+          // for example net11.0-windows-debug-x64
           "value": "${cmake.installRoot}\\..\\..\\runtime\\<tfm>-windows-<configuration>-<arch>\\"
         }
       ],

diff --git a/docs/workflow/testing/host/testing.md b/docs/workflow/testing/host/testing.md
@@ -66,12 +66,12 @@ If all tests have not been previously run, make sure the [test context](#test-co
 
 Tests from a specific test project can be run using [`dotnet test`](https://learn.microsoft.com/dotnet/core/tools/dotnet-test) targeting the built test binary. For example:
 ```
-dotnet test artifacts/bin/HostActivation.Tests/Debug/net10.0/HostActivation.Tests.dll --filter category!=failing
+dotnet test artifacts/bin/HostActivation.Tests/Debug/net11.0/HostActivation.Tests.dll --filter category!=failing
 ```
 
 To filter to specific tests within the test library, use the [filter options](https://learn.microsoft.com/dotnet/core/tools/dotnet-test#filter-option-details) available for `dotnet test`. For example:
 ```
-dotnet test artifacts/bin/HostActivation.Tests/Debug/net10.0/HostActivation.Tests.dll --filter "DependencyResolution&category!=failing"
+dotnet test artifacts/bin/HostActivation.Tests/Debug/net11.0/HostActivation.Tests.dll --filter "DependencyResolution&category!=failing"
 ```
 
 The `category!=failing` is to respect the [filtering traits](../libraries/filtering-tests.md) used by the runtime repo.

diff --git a/docs/workflow/testing/libraries/testing.md b/docs/workflow/testing/libraries/testing.md
@@ -177,4 +177,4 @@ If you change code, you'd need to remove `/p:testnobuild=true` from the command
 
 ### Viewing XUnit logs
 
-It's usually sufficient to see the test failure output in the console. There is also a test log file, which you can find in a location like `...\runtime\artifacts\bin\System.Text.RegularExpressions.Tests\Debug\net10.0\testResults.xml`. It can be helpful, for example, to grep through a series of failures, or to see how long a slow test actually took.
+It's usually sufficient to see the test failure output in the console. There is also a test log file, which you can find in a location like `...\runtime\artifacts\bin\System.Text.RegularExpressions.Tests\Debug\net11.0\testResults.xml`. It can be helpful, for example, to grep through a series of failures, or to see how long a slow test actually took.
Original file line number	Diff line number	Diff line change
Expand Up		@@ -177,4 +177,4 @@ If you change code, you'd need to remove `/p:testnobuild=true` from the command

		### Viewing XUnit logs

		It's usually sufficient to see the test failure output in the console. There is also a test log file, which you can find in a location like `...\runtime\artifacts\bin\System.Text.RegularExpressions.Tests\Debug\net10.0\testResults.xml`. It can be helpful, for example, to grep through a series of failures, or to see how long a slow test actually took.
		It's usually sufficient to see the test failure output in the console. There is also a test log file, which you can find in a location like `...\runtime\artifacts\bin\System.Text.RegularExpressions.Tests\Debug\net11.0\testResults.xml`. It can be helpful, for example, to grep through a series of failures, or to see how long a slow test actually took.