VSadov/Satori
1
0
Fork 0
mirror of https://github.com/VSadov/Satori.git synced 2025-06-11 10:18:21 +09:00
Code Activity

Replace net8 with net9 under docs (#104189)

Browse source 
Fixes #104088
This commit is contained in:
Jan Kotas 2024-06-29 04:44:01 -07:00 • committed by GitHub
parent fb762d10e5
commit 99e94ce55d
Signed by: github
GPG key ID: B5690EEEBB952194
13 changed files with 247 additions and 247 deletions
Download patch file Download diff file Expand all files Collapse all files

2
docs/workflow/testing/host/using-apphost.md
View file

@ -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.

2
docs/workflow/testing/libraries/testing.md
View file

@ -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.

12
docs/workflow/testing/using-dev-shipping-packages.md
View file

@ -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

14
docs/workflow/testing/using-your-build-with-installed-sdk.md
View file

@ -36,7 +36,7 @@ To setup the nightly SDK, you can either install it to your machine or use a por
To use a portable build (check the note above though), 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 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 must be equal or greater than `8.0.100-*`.
After setting up 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 must be equal or greater than `9.0.100-*`.
<!-- TODO: It feels like this link may or may not be more appropriate elsewhere. Need to dig deeper into the documentation, so leaving it here for the time being. -->
For another small walkthrough see [Dogfooding .NET SDK](https://github.com/dotnet/runtime/blob/main/docs/project/dogfooding.md).
@ -93,7 +93,7 @@ dotnet publish --self-contained
</configuration>
```
After you publish successfully, you will find all the binaries needed to run your application under `bin\Debug\net8.0\win-x64\publish`.
After you publish successfully, you will find all the binaries needed to run your application under `bin\Debug\net9.0\win-x64\publish`.
**But we are not done yet, you need to replace the published runtime files with the files from your local build!**
@ -105,12 +105,12 @@ The publishing step described above creates a directory that has all the files n
* `System.Private.CoreLib.dll`: If you modified managed C# code, it will end up here.
* `clrjit.dll`: The JIT compiler. It is also required you copy this one to your published app.
Now, here comes the main deal to test your build. Once you have your self-contained app published, and CoreCLR built, you will replace the binaries listed above with the generated artifacts. Copy them from `artifacts/bin/coreclr/<OS>.<arch>.<configuration>/` to your app's publication directory, which by default is `your-app-folder/bin/<configuration>/net8.0/<os-code>-<arch>/publish`.
Now, here comes the main deal to test your build. Once you have your self-contained app published, and CoreCLR built, you will replace the binaries listed above with the generated artifacts. Copy them from `artifacts/bin/coreclr/<OS>.<arch>.<configuration>/` to your app's publication directory, which by default is `your-app-folder/bin/<configuration>/net9.0/<os-code>-<arch>/publish`.
In our previous example this would be:
* From: `artifacts/bin/coreclr/windows.x64.Debug/`
* To: `HelloWorld/bin/Debug/net8.0/win-x64/publish/`
* To: `HelloWorld/bin/Debug/net9.0/win-x64/publish/`
## Confirm that the app used your new runtime (Optional)
@ -129,8 +129,8 @@ Console.WriteLine($"System.Private.CoreLib.dll is located at: {typeof(object).As
That should tell you the version, and which user and machine built the assembly, as well as the _commit hash_ of the code at the time of building:
```text
Core Runtime Info: 8.0.0-dev
System.Private.CoreLib.dll is located at: /path/to/your/app/bin/Debug/net8.0/win-x64/publish/System.Private.CoreLib.dll
Core Runtime Info: 9.0.0-dev
System.Private.CoreLib.dll is located at: /path/to/your/app/bin/Debug/net9.0/win-x64/publish/System.Private.CoreLib.dll
```
What you are looking for here is that the core runtime used is labelled as `-dev`. This means it is indeed using the one you built in the runtime repo. Also, ensure that the picked _System.Private.CoreLib.dll_ is indeed the one in your `publish` folder.
@ -144,7 +144,7 @@ Here are a few very common errors you might encounter, and how to fix them.
Make sure you are running the executable directly.
```cmd
.\bin\Debug\net8.0\win-x64\publish\HelloWorld.exe
.\bin\Debug\net9.0\win-x64\publish\HelloWorld.exe
```
If you use `dotnet run` it will overwrite your custom binaries before executing the app.