Replace net8 with net9 under docs (dotnet#104189)

Fixes dotnet#104088

docs/coding-guidelines/adding-api-guidelines.md

@@ -24,8 +24,8 @@ the implementation without compat concerns in future releases.
 
 ### Determine target framework
 
-`net8.0` is the target framework version currently under development and the new apis
-should be added to `net8.0`. [More Information on TargetFrameworks](https://learn.microsoft.com/dotnet/standard/frameworks)
+`net9.0` is the target framework version currently under development and the new apis
+should be added to `net9.0`. [More Information on TargetFrameworks](https://learn.microsoft.com/dotnet/standard/frameworks)
 
 ## Making the changes in repo
 

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. net8.0`
+- `$(BuildTargetFramework) -> Any .NETCoreApp or .NETFramework TFM, e.g. net9.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: `net8.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: `net9.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).

docs/design/coreclr/jit/viewing-jit-dumps.md

@@ -109,7 +109,7 @@ For example, for Windows x64 machine, the project file is:
     <Project Sdk="Microsoft.NET.Sdk">
       <PropertyGroup>
         <OutputType>Exe</OutputType>
-        <TargetFramework>net8.0</TargetFramework>
+        <TargetFramework>net9.0</TargetFramework>
         <RuntimeIdentifier>win-x64</RuntimeIdentifier>
       </PropertyGroup>
     </Project>

docs/workflow/building/coreclr/nativeaot.md

@@ -27,7 +27,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 8.0.0-dev` to add the local package reference to your project.
+* Run `dotnet add package Microsoft.DotNet.ILCompiler -v 9.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

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 `net8.0` (currently the latest .NET version) or `net48` (the latest .NET Framework version). (msbuild property `BuildTargetFramework`)
+- `-framework|-f` identifies the target framework for the build. Possible values include `net9.0` (currently the latest .NET version) or `net48` (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`)

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/net8.0-<TargetOS>-<BuildArch>-<BuildType>/`:
-
-    $ ls artifacts/bin/native/net8.0-Linux-Release-arm/*
-    artifacts/bin/native/net8.0-Linux-Release-arm/libSystem.Globalization.Native.a
-    artifacts/bin/native/net8.0-Linux-Release-arm/libSystem.Globalization.Native.so
-    artifacts/bin/native/net8.0-Linux-Release-arm/libSystem.Globalization.Native.so.dbg
-    artifacts/bin/native/net8.0-Linux-Release-arm/libSystem.IO.Compression.Native.a
-    artifacts/bin/native/net8.0-Linux-Release-arm/libSystem.IO.Compression.Native.so
-    artifacts/bin/native/net8.0-Linux-Release-arm/libSystem.IO.Compression.Native.so.dbg
-    artifacts/bin/native/net8.0-Linux-Release-arm/libSystem.IO.Ports.Native.a
-    artifacts/bin/native/net8.0-Linux-Release-arm/libSystem.IO.Ports.Native.so
-    artifacts/bin/native/net8.0-Linux-Release-arm/libSystem.IO.Ports.Native.so.dbg
-    artifacts/bin/native/net8.0-Linux-Release-arm/libSystem.Native.a
-    artifacts/bin/native/net8.0-Linux-Release-arm/libSystem.Native.so
-    artifacts/bin/native/net8.0-Linux-Release-arm/libSystem.Native.so.dbg
-    artifacts/bin/native/net8.0-Linux-Release-arm/libSystem.Net.Security.Native.a
-    artifacts/bin/native/net8.0-Linux-Release-arm/libSystem.Net.Security.Native.so
-    artifacts/bin/native/net8.0-Linux-Release-arm/libSystem.Net.Security.Native.so.dbg
-    artifacts/bin/native/net8.0-Linux-Release-arm/libSystem.Security.Cryptography.Native.OpenSsl.a
-    artifacts/bin/native/net8.0-Linux-Release-arm/libSystem.Security.Cryptography.Native.OpenSsl.so
-    artifacts/bin/native/net8.0-Linux-Release-arm/libSystem.Security.Cryptography.Native.OpenSsl.so.dbg
-
-    $ file artifacts/bin/native/net8.0-Linux-Release-arm/libSystem.Native.so
-    artifacts/bin/native/net8.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/net9.0-<TargetOS>-<BuildArch>-<BuildType>/`:
+
+    $ ls artifacts/bin/native/net9.0-Linux-Release-arm/*
+    artifacts/bin/native/net9.0-Linux-Release-arm/libSystem.Globalization.Native.a
+    artifacts/bin/native/net9.0-Linux-Release-arm/libSystem.Globalization.Native.so
+    artifacts/bin/native/net9.0-Linux-Release-arm/libSystem.Globalization.Native.so.dbg
+    artifacts/bin/native/net9.0-Linux-Release-arm/libSystem.IO.Compression.Native.a
+    artifacts/bin/native/net9.0-Linux-Release-arm/libSystem.IO.Compression.Native.so
+    artifacts/bin/native/net9.0-Linux-Release-arm/libSystem.IO.Compression.Native.so.dbg
+    artifacts/bin/native/net9.0-Linux-Release-arm/libSystem.IO.Ports.Native.a
+    artifacts/bin/native/net9.0-Linux-Release-arm/libSystem.IO.Ports.Native.so
+    artifacts/bin/native/net9.0-Linux-Release-arm/libSystem.IO.Ports.Native.so.dbg
+    artifacts/bin/native/net9.0-Linux-Release-arm/libSystem.Native.a
+    artifacts/bin/native/net9.0-Linux-Release-arm/libSystem.Native.so
+    artifacts/bin/native/net9.0-Linux-Release-arm/libSystem.Native.so.dbg
+    artifacts/bin/native/net9.0-Linux-Release-arm/libSystem.Net.Security.Native.a
+    artifacts/bin/native/net9.0-Linux-Release-arm/libSystem.Net.Security.Native.so
+    artifacts/bin/native/net9.0-Linux-Release-arm/libSystem.Net.Security.Native.so.dbg
+    artifacts/bin/native/net9.0-Linux-Release-arm/libSystem.Security.Cryptography.Native.OpenSsl.a
+    artifacts/bin/native/net9.0-Linux-Release-arm/libSystem.Security.Cryptography.Native.OpenSsl.so
+    artifacts/bin/native/net9.0-Linux-Release-arm/libSystem.Security.Cryptography.Native.OpenSsl.so.dbg
+
+    $ file artifacts/bin/native/net9.0-Linux-Release-arm/libSystem.Native.so
+    artifacts/bin/native/net9.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/net8.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/net9.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:
 

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,
-`net8.0-windows-Release-x86-CoreCLR_checked-jitstress1-Windows.10.Amd64.Open` is a libraries test run on Windows with a Release x86 libraries
+`net9.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

docs/workflow/debugging/coreclr/debugging-runtime.md

@@ -54,7 +54,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; for example `net6.0`, `net7.0` or `net8.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; for example `net6.0`, `net8.0` or `net9.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`.
@@ -84,7 +84,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 net8.0-windows-Debug-x64
+          // for example net9.0-windows-Debug-x64
           "value": "${cmake.installRoot}\\..\\..\\runtime\\<tfm>-windows-<configuration>-<arch>\\"
         }
       ],

docs/workflow/testing/host/using-apphost.md

@@ -27,4 +27,4 @@ Alternatives to this method include copying the desired apphost to the appropria
 
 For a [framework-dependent application](https://learn.microsoft.com/dotnet/core/deploying/#publish-framework-dependent), you can set the `DOTNET_ROOT` environment variable to point at a local .NET layout.
 
-The [libraries tests](../libraries/testing.md) construct and use such a layout based on your local runtime, host, and libraries build as part of the `libs.pretest` subset. To use that layout, set `DOTNET_ROOT=<repo_root>/artifacts/bin/testhost/net8.0-<os>-<configuration>-<arch>` and then run the .NET application.
+The [libraries tests](../libraries/testing.md) construct and use such a layout based on your local runtime, host, and libraries build as part of the `libs.pretest` subset. To use that layout, set `DOTNET_ROOT=<repo_root>/artifacts/bin/testhost/net<version>-<os>-<configuration>-<arch>` and then run the .NET application.

docs/workflow/testing/libraries/testing.md

@@ -178,4 +178,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\net8.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\net9.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.

docs/workflow/testing/using-dev-shipping-packages.md

@@ -46,7 +46,7 @@ To setup the nightly SDK, you can either install it to your machine or use a por
 
 To use a portable build (recommended way), first extract somewhere the _zip/tar.gz_ you downloaded at the beginning of this section. Then, you can either add the path where you extracted it to your `PATH` environment variable, or always fully qualify the path to the `dotnet` you extracted (e.g. `/path/to/nightly/build/dotnet`).
 
-After setting up the new dotnet you can verify you are using the newer version by issuing the `dotnet --version` command on it. At the time of writing, the version ought to be equal or greater than `8.0.100-*`.
+After setting up the new dotnet you can verify you are using the newer version by issuing the `dotnet --version` command on it. At the time of writing, the version ought to be equal or greater than `9.0.100-*`.
 
 ## Creating and running the app with your build
 
@@ -94,12 +94,12 @@ Once we have your `NuGet.Config` file ready, we have to make our project aware t
 
 ```xml
 <ItemGroup>
-  <!-- At the time of writing, '8.0.0-dev' is the version of the runtime repo's shipping packages. -->
-  <FrameworkReference Update="Microsoft.NETCore.App" RuntimeFrameworkVersion="8.0.0-dev" />
+  <!-- At the time of writing, '9.0.0-dev' is the version of the runtime repo's shipping packages. -->
+  <FrameworkReference Update="Microsoft.NETCore.App" RuntimeFrameworkVersion="9.0.0-dev" />
 </ItemGroup>
 ```
 
-If you're unsure of what version your packages are, it is included as part of their filenames. For example, pick the `nupkg` file that will be used with your app from your shipping folder (`artifacts/packages/<configuration>/Shipping`). It's name is something like `Microsoft.NETCore.App.Runtime.win-x64.8.0.0-dev.nupkg`, depending on the current version and your target platform.
+If you're unsure of what version your packages are, it is included as part of their filenames. For example, pick the `nupkg` file that will be used with your app from your shipping folder (`artifacts/packages/<configuration>/Shipping`). It's name is something like `Microsoft.NETCore.App.Runtime.win-x64.9.0.0-dev.nupkg`, depending on the current version and your target platform.
 
 ### Write a small test
 
@@ -126,8 +126,8 @@ Adjust the `win-x64` to match your machine's OS and architecture.
 Running this little app should yield an output like the following:
 
 ```text
-Hello World from .NET 8.0.0-dev
-The location of System.Private.CoreLib.dll is '/path/to/your/app/bin/Debug/net8.0/win-x64/publish/System.Private.CoreLib.dll'
+Hello World from .NET 9.0.0-dev
+The location of System.Private.CoreLib.dll is '/path/to/your/app/bin/Debug/net9.0/win-x64/publish/System.Private.CoreLib.dll'
 ```
 
 ## Making Changes and Consuming Updated Packages