Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Target .NET 10 / net10.0 #106599

Merged
merged 71 commits into from
Sep 25, 2024
Merged
Show file tree
Hide file tree
Changes from 68 commits
Commits
Show all changes
71 commits
Select commit Hold shift + click to select a range
d481d3c
Update dotnet10 feeds
ViktorHofer Aug 18, 2024
a1baec6
Update hardcoded old TFM values
ViktorHofer Aug 18, 2024
dd5f56e
More hardcode updates and TFM checks
ViktorHofer Aug 18, 2024
0f4766e
Updates and delete duplicate file in Bcl.Numerics
ViktorHofer Aug 18, 2024
5b9a4dc
Linker stays on net9.0
ViktorHofer Aug 19, 2024
0bcc0f4
Fix .NET SDK max supported version
ViktorHofer Aug 19, 2024
937ccf8
Update apicompat sfx apicompat baseline file
ViktorHofer Aug 19, 2024
b453c2b
Update Microsoft.NET.WebAssembly.Threading APICompat settings
ViktorHofer Aug 19, 2024
2f160d7
Fix DiagnosticSource build
ViktorHofer Aug 19, 2024
0e61f08
Update SDK to RC1 for needed GetAlternateLookup API
ViktorHofer Aug 19, 2024
1c62be9
Fix APICompat runtime regex pattern
ViktorHofer Aug 19, 2024
b97af84
Suppress Bcl.Memory compatibility error for dropped framework
ViktorHofer Aug 19, 2024
99dd974
Fix BinaryFormatter tests regex pattern for version subsitution
ViktorHofer Aug 19, 2024
696ea04
Update BinaryFormatterTests.cs
ViktorHofer Aug 19, 2024
c8c6a06
Pin SdkVersionForWorkloadTesting to the version in global.json
lewing Aug 19, 2024
128991c
Treat net9 and net10 as current for now
lewing Aug 19, 2024
dcfacd5
Bump MicrosoftDotNetILCompilerVersion
jtschuster Aug 19, 2024
8db7ff5
Update BinaryFormatterTests.cs
ViktorHofer Aug 20, 2024
e654638
Update System.Resources.Extensions
ViktorHofer Aug 20, 2024
2328a9a
Update AutoImports as well
lewing Aug 20, 2024
7019aee
Fix ImporterTests.cs
akoeplinger Aug 21, 2024
4932351
Merge branch 'main' into RetargetToNet10
ViktorHofer Aug 22, 2024
a6dba9f
Block failing SignalRClientTests
ilonatommy Aug 22, 2024
56ce3f7
Merge branch 'main' into RetargetToNet10
ViktorHofer Aug 26, 2024
d061b76
Merge branch 'main' into RetargetToNet10
lewing Aug 27, 2024
0c22069
Update XmlSerialzation Schema Import tests.
StephenMolloy Aug 27, 2024
bd7a2b9
Merge branch 'main' into RetargetToNet10
lewing Aug 28, 2024
de24bfa
Update Versions.props
ViktorHofer Aug 30, 2024
20b88b8
Merge remote-tracking branch 'upstream/main' into RetargetToNet10
akoeplinger Sep 2, 2024
2bed3a0
Update CompatibilitySuppressions.xml for System.Numerics.Tensors
akoeplinger Sep 2, 2024
a0555f4
Merge remote-tracking branch 'upstream/main' into RetargetToNet10
akoeplinger Sep 3, 2024
9b87210
Merge remote-tracking branch 'upstream/main' into RetargetToNet10
akoeplinger Sep 4, 2024
274061c
Merge remote-tracking branch 'upstream/main' into RetargetToNet10
akoeplinger Sep 6, 2024
378fab6
Merge remote-tracking branch 'upstream/main' into RetargetToNet10
akoeplinger Sep 6, 2024
015cf19
Don't set EnableDefaultCompileItems, it doesn't work since we set Ena…
akoeplinger Sep 6, 2024
48d6e62
Update regex in legacy BinaryFormatterTests.cs too
akoeplinger Sep 6, 2024
fc95296
Hardcode BinaryFormatter test assembly version to 9.0
akoeplinger Sep 9, 2024
839e08a
Merge remote-tracking branch 'origin/main' into RetargetToNet10
akoeplinger Sep 10, 2024
6e92f4b
Fix typo
akoeplinger Sep 10, 2024
e7b323e
Fix issue in Microsoft.NET.Workload.Mono.Toolchain.Current.Manifest.p…
akoeplinger Sep 10, 2024
91b3e6d
Replace ForceNet8Current in a few more places
akoeplinger Sep 10, 2024
eb58088
Fix wasi workload
akoeplinger Sep 10, 2024
898ccdb
Fix TreatAsCurrent for 10.0
akoeplinger Sep 11, 2024
4e4d6bb
Add net9 workload manifests
akoeplinger Sep 11, 2024
efcf09d
Merge remote-tracking branch 'origin/main' into RetargetToNet10
akoeplinger Sep 11, 2024
918039d
Update PackageId in icrosoft.NET.Runtime.WebAssembly.Templates.csproj
akoeplinger Sep 11, 2024
f2645c9
Merge branch 'main' into RetargetToNet10
akoeplinger Sep 12, 2024
cc89414
Merge branch 'main' into RetargetToNet10
akoeplinger Sep 13, 2024
19839ec
Update ApiCompatBaseline.NetCoreAppLatestStable.xml
akoeplinger Sep 13, 2024
c281480
Merge remote-tracking branch 'origin/main' into RetargetToNet10
akoeplinger Sep 13, 2024
0af3c96
Remove duplicate dotnet10 feeds from nuget.config
akoeplinger Sep 13, 2024
d0426a6
Merge branch 'main' into RetargetToNet10
lewing Sep 15, 2024
79e0864
Update Versions.props
lewing Sep 16, 2024
8d55945
Fake SDK band version for now
lewing Sep 17, 2024
14020f0
Update Versions.props
lewing Sep 17, 2024
e96b1bb
Update the SDK band versions for real
lewing Sep 17, 2024
8d8f2e7
Update the dotnet/sdk dependencies
lewing Sep 17, 2024
395c3d8
Update emsdk to net10 workloads
lewing Sep 18, 2024
7f569c1
Install a 9.0 runtime for workload tests too
lewing Sep 18, 2024
4534dd7
Update the compat tasks
lewing Sep 18, 2024
5aff8c4
Merge branch 'main' into RetargetToNet10
lewing Sep 18, 2024
9b97d78
Merge in changes from net10-manifests
lewing Sep 19, 2024
bf019f3
Tmp: Trying out @am11's branch.
ilonatommy Sep 20, 2024
5cf5d66
Tmp2: Trying out @am11's branch.
ilonatommy Sep 20, 2024
9b320bd
Tmp3: Replace the last usage of main in clone action.
ilonatommy Sep 20, 2024
57931b1
Merge branch 'main' into RetargetToNet10
lewing Sep 20, 2024
0c32862
Merge branch 'main' into RetargetToNet10
lewing Sep 21, 2024
1da1b90
Merge branch 'main' into RetargetToNet10
lewing Sep 23, 2024
19c2269
Update eng/pipelines/coreclr/templates/build-perf-bdn-app.yml
lewing Sep 24, 2024
6a51ac6
Update eng/pipelines/coreclr/templates/perf-job.yml
lewing Sep 24, 2024
cc1f480
Update eng/pipelines/runtime-wasm-perf.yml
lewing Sep 24, 2024
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 7 additions & 7 deletions Directory.Build.props
Original file line number Diff line number Diff line change
@@ -1,4 +1,5 @@
<Project>

<PropertyGroup>
<!-- For non-SDK projects that import this file and then import Microsoft.Common.props,
tell Microsoft.Common.props not to import Directory.Build.props again. -->
Expand Down Expand Up @@ -86,18 +87,16 @@

<!-- The TFMs to build and test against. -->
<PropertyGroup>
<NetCoreAppCurrentVersion>9.0</NetCoreAppCurrentVersion>
<NetCoreAppCurrentVersion>10.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. -->
<NetCoreAppPreviousVersion>8.0</NetCoreAppPreviousVersion>
<!-- For the .NET 9 release, set NetCoreAppPrevious to empty as NuGet has issues
with duplicate TFMs (when using both NetCoreAppPrevious and NetCoreAppMinimum). -->
<NetCoreAppPrevious />
<NetCoreAppPrevious>net9.0</NetCoreAppPrevious>
<NetCoreAppPrevious Condition="'$(DotNetBuildSourceOnly)' == 'true'">$(NetCoreAppCurrent)</NetCoreAppPrevious>

<!-- The minimum supported .NET version. -->
<NetCoreAppMinimum>net8.0</NetCoreAppMinimum>
Expand All @@ -122,8 +121,9 @@
<NetFrameworkCurrent Condition="'$(DotNetBuildSourceOnly)' == 'true'" />

<!-- Important: Set this to the GA version (or a close approximation) during servicing and adjust the TFM property below. -->
<ApiCompatNetCoreAppBaselineVersion>8.0.0</ApiCompatNetCoreAppBaselineVersion>
<ApiCompatNetCoreAppBaselineTFM>net8.0</ApiCompatNetCoreAppBaselineTFM>
<!-- TODO: Update to 9.0.0 when .NET 9 is generally available. https://github.com/dotnet/runtime/issues/106598 -->
<ApiCompatNetCoreAppBaselineVersion>9.0.0-preview.7.24405.7</ApiCompatNetCoreAppBaselineVersion>
<ApiCompatNetCoreAppBaselineTFM>net9.0</ApiCompatNetCoreAppBaselineTFM>
</PropertyGroup>

<PropertyGroup Label="CalculateConfiguration">
Expand Down
2 changes: 1 addition & 1 deletion Directory.Build.targets
Original file line number Diff line number Diff line change
Expand Up @@ -39,7 +39,7 @@
Define this here (not just in Versions.props) because the SDK resets it
unconditionally in Microsoft.NETCoreSdk.BundledVersions.props.
-->
<NETCoreAppMaximumVersion>$(MajorVersion).$(MinorVersion)</NETCoreAppMaximumVersion>
<NETCoreAppMaximumVersion>$(NetCoreAppCurrentVersion)</NETCoreAppMaximumVersion>
<!-- SDK sets product to assembly but we want it to be our product name -->
<Product>Microsoft%AE .NET</Product>
<!-- Use the .NET product branding version for informational version description -->
Expand Down
2 changes: 1 addition & 1 deletion NuGet.config
Original file line number Diff line number Diff line change
Expand Up @@ -16,8 +16,8 @@
<add key="dotnet-tools" value="https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-tools/nuget/v3/index.json" />
<add key="dotnet-eng" value="https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-eng/nuget/v3/index.json" />
<add key="dotnet-libraries" value="https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-libraries/nuget/v3/index.json" />
<!-- Required for System.CommandLine SB intermediate -->
<add key="dotnet-libraries-transport" value="https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-libraries-transport/nuget/v3/index.json" />
<!-- TODO: Remove dotnet9 feeds when all dependencies moved to the dotnet10 feeds. https://github.com/dotnet/runtime/issues/106593 -->
<add key="dotnet9" value="https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet9/nuget/v3/index.json" />
<add key="dotnet9-transport" value="https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet9-transport/nuget/v3/index.json" />
<add key="dotnet10" value="https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet10/nuget/v3/index.json" />
Expand Down
4 changes: 2 additions & 2 deletions docs/coding-guidelines/adding-api-guidelines.md
Original file line number Diff line number Diff line change
Expand Up @@ -24,8 +24,8 @@ the implementation without compat concerns in future releases.

### Determine target framework

`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)
`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)

## Making the changes in repo

Expand Down
6 changes: 3 additions & 3 deletions docs/coding-guidelines/libraries-packaging.md
Original file line number Diff line number Diff line change
Expand Up @@ -150,13 +150,13 @@ In order to mitigate design-time/build-time performance issues with source gener
### NETStandard Compatibility Error infrastructure
For libraries that support .NETStandard, the _.NETStandard Compatibility packaging infrastructure_ makes sure that out-of-support target frameworks like _netcoreapp3.1_ or _net461_ are unsupported by the produced package. That enables library authors to support .NETStandard but explicitly not support unsupported .NETStandard compatible target frameworks.

The infrastructure generates a targets file that throws a user readable Error when msbuild invokes a project with an unsupported target framework. In addition to the targets file, placeholder files `_._` are placed into the minimum supported .NETStandard compatible target framework's package folder (as time of writing `net6.0` and `net462`), so that the generated targets files don't apply for that and any newer/compatible target framework. Example:
The infrastructure generates a targets file that throws a user readable Error when msbuild invokes a project with an unsupported target framework. In addition to the targets file, placeholder files `_._` are placed into the minimum supported .NETStandard compatible target framework's package folder (as time of writing `net8.0` and `net462`), so that the generated targets files don't apply for that and any newer/compatible target framework. Example:

```
buildTransitive\net461\Microsoft.Extensions.Configuration.UserSecrets.targets <- This file is generated and throws an Error
buildTransitive\net462\_._
buildTransitive\netcoreapp2.0\Microsoft.Extensions.Configuration.UserSecrets.targets <- This file is generated and throws an Error
buildTransitive\net6.0\_._
buildTransitive\net8.0\_._
```

Whenever a library wants to author their own set of props and targets files (i.e. for source generators) and the above mentioned infrastructure kicks in (because the library targets .NETStandard), such files **must be included not only for the .NETStandard target framework but also for the specific minimum supported target frameworks**. The _.NETStandard Compatibility packaging infrastructure_ then omits the otherwise necessary placeholder files. Example:
Expand All @@ -166,7 +166,7 @@ buildTransitive\netstandard2.0\Microsoft.Extensions.Configuration.UserSecrets.ta
buildTransitive\net461\Microsoft.Extensions.Configuration.UserSecrets.targets <- This file is generated and throws an Error
buildTransitive\net462\Microsoft.Extensions.Configuration.UserSecrets.targets <- This file is hand authored and doesn't throw an error
buildTransitive\netcoreapp2.0\Microsoft.Extensions.Configuration.UserSecrets.targets <- This file is generated and throws an Error
buildTransitive\net6.0\Microsoft.Extensions.Configuration.UserSecrets.targets <- This file is hand authored and doesn't throw an error
buildTransitive\net8.0\Microsoft.Extensions.Configuration.UserSecrets.targets <- This file is hand authored and doesn't throw an error
```

The above layout is achieved via the following item declaration in the project file. In that case, the hand authored msbuild props and/or targets files are located in a buildTransitive folder in the project tree. Note that the trailing directory separators are required.
Expand Down
6 changes: 3 additions & 3 deletions docs/coding-guidelines/project-guidelines.md
Original file line number Diff line number Diff line change
Expand Up @@ -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. net9.0`
- `$(BuildTargetFramework) -> Any .NETCoreApp or .NETFramework TFM, e.g. net10.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]`
Expand Down Expand Up @@ -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: `net9.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: `net10.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).
Expand Down Expand Up @@ -163,7 +163,7 @@ In the src directory for a library there should be only **one** `.csproj` file t

All libraries should use `<Reference Include="..." />` for all their references to libraries that compose the shared framework of the current .NETCoreApp. That will cause them to be resolved against the locally built targeting pack which is located at `artifacts\bin\microsoft.netcore.app.ref`. The only exception to that rule right now is for partial facades which directly reference System.Private.CoreLib and thus need to directly reference other partial facades to avoid type conflicts.

Other target frameworks than .NETCoreApp latest (i.e. `netstandard2.0`, `net462`, `net6.0`) should use ProjectReference items to reference dependencies.
Other target frameworks than .NETCoreApp latest (i.e. `netstandard2.0`, `net462`, `net8.0`) should use ProjectReference items to reference dependencies.

### src\ILLink
Contains the files used to direct the trimming tool. See [ILLink files](../workflow/trimming/ILLink-files.md).
Expand Down
10 changes: 5 additions & 5 deletions docs/project/dogfooding.md
Original file line number Diff line number Diff line change
Expand Up @@ -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. 'net9.0' -->
<TargetFramework>net9.0</TargetFramework>
<!-- Ensure that the target framework is correct e.g. 'net10.0' -->
<TargetFramework>net10.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>
Expand All @@ -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. 'net9.0' -->
<TargetFramework>net9.0</TargetFramework>
<!-- Ensure that the target framework is correct e.g. 'net10.0' -->
<TargetFramework>net10.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>
Expand All @@ -159,7 +159,7 @@ make it self-contained by adding a RuntimeIdentifier (RID).
```
$ dotnet restore
$ dotnet publish
$ bin\Debug\net9.0\win-x64\publish\App.exe
$ bin\Debug\net10.0\win-x64\publish\App.exe
```

### Daily builds table
Expand Down
2 changes: 1 addition & 1 deletion docs/project/glossary.md
Original file line number Diff line number Diff line change
Expand Up @@ -49,7 +49,7 @@ terminology.
| SPCL | `System.Private.CoreLib` - the lowest managed assembly in the libraries stack that contains `System.Object`, `String`, etc. |
| SuperPMI | JIT component test framework (super fast JIT testing - it mocks/replays EE in EE-JIT interface) - see [SuperPMI details](https://github.com/dotnet/runtime/blob/main/src/coreclr/tools/superpmi/readme.md). |
| SVR | The CLR used to be built as two variants, with one called "mscorsvr.dll", to mean the "server" version. In particular, it contained the server GC implementation, which was intended for multi-threaded apps capable of taking advantage of multiple processors. In the .NET Framework 2 release, the two variants were merged into "mscorwks.dll". The WKS version was the default, however the SVR version remained available. |
| TFM | [Target Framework Moniker](https://learn.microsoft.com/dotnet/standard/frameworks) such as `net6.0` or `netstandard2.0`. |
| TFM | [Target Framework Moniker](https://learn.microsoft.com/dotnet/standard/frameworks) such as `net8.0` or `netstandard2.0`. |
| TPA | Trusted Platform Assemblies used to be a special set of assemblies that comprised the platform assemblies, when it was originally designed. As of today, it is simply the set of assemblies known to constitute the application. |
| URT | Universal Runtime. Ancient name for what ended up being .NET, is used in the WinError facility name FACILITY_URT. |
| UTC | [Universal Tuple Compiler](https://blogs.msdn.microsoft.com/vcblog/2013/06/12/optimizing-c-code-overview/). The Microsoft C++ optimizer back-end that starts by converting the information from the FrontEnd into tuples – a binary stream of instructions. |
Expand Down
4 changes: 2 additions & 2 deletions docs/workflow/building/coreclr/nativeaot.md
Original file line number Diff line number Diff line change
Expand Up @@ -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 9.0.0-dev` to add the local package reference to your project.
* Run `dotnet add package Microsoft.DotNet.ILCompiler -v 10.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
Expand Down Expand Up @@ -62,7 +62,7 @@ Typical workflow for working on the compiler:
* Open `ilc.sln` in Visual Studio
* Set "ILCompiler" project in solution explorer as your startup project
* Set Working directory in the project Debug options to your test project directory, e.g. `C:\test`
* Set Application arguments in the project Debug options to the response file that was generated by regular native aot publishing of your test project, e.g. `@obj\Release\net6.0\win-x64\native\HelloWorld.ilc.rsp`
* Set Application arguments in the project Debug options to the response file that was generated by regular native aot publishing of your test project, e.g. `@obj\Release\net8.0\win-x64\native\HelloWorld.ilc.rsp`
* Build & run using **F5**

## Convenience Visual Studio "repro" project
Expand Down
2 changes: 1 addition & 1 deletion docs/workflow/building/libraries/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -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 `net9.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 `net10.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`)
Expand Down
Loading
Loading