You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* Update dotnet10 feeds
* Update hardcoded old TFM values
* More hardcode updates and TFM checks
* Updates and delete duplicate file in Bcl.Numerics
* Linker stays on net9.0
* Fix .NET SDK max supported version
* Update apicompat sfx apicompat baseline file
* Update Microsoft.NET.WebAssembly.Threading APICompat settings
* Fix DiagnosticSource build
* Update SDK to RC1 for needed GetAlternateLookup API
to be able to build System.Text.Json on net9.0.
* Fix APICompat runtime regex pattern
* Suppress Bcl.Memory compatibility error for dropped framework
* Fix BinaryFormatter tests regex pattern for version subsitution
* Update BinaryFormatterTests.cs
* Pin SdkVersionForWorkloadTesting to the version in global.json
* Treat net9 and net10 as current for now
* Bump MicrosoftDotNetILCompilerVersion
* Update BinaryFormatterTests.cs
* Update System.Resources.Extensions
* Update AutoImports as well
* Fix ImporterTests.cs
* Block failing SignalRClientTests
* Update XmlSerialzation Schema Import tests.
* Update Versions.props
* Update CompatibilitySuppressions.xml for System.Numerics.Tensors
* Don't set EnableDefaultCompileItems, it doesn't work since we set EnableDefaultItems=false higher up
* Update regex in legacy BinaryFormatterTests.cs too
* Hardcode BinaryFormatter test assembly version to 9.0
This allows us to not change the majority of the tests
* Fix typo
* Fix issue in Microsoft.NET.Workload.Mono.Toolchain.Current.Manifest.pkgproj
* Replace ForceNet8Current in a few more places
* Fix wasi workload
* Fix TreatAsCurrent for 10.0
* Add net9 workload manifests
* Update PackageId in icrosoft.NET.Runtime.WebAssembly.Templates.csproj
* Update ApiCompatBaseline.NetCoreAppLatestStable.xml
Changes from #107758
* Remove duplicate dotnet10 feeds from nuget.config
* Update Versions.props
* Fake SDK band version for now
* Update Versions.props
* Update the SDK band versions for real
* Update the dotnet/sdk dependencies
* Update emsdk to net10 workloads
* Install a 9.0 runtime for workload tests too
* Update the compat tasks
* Merge in changes from net10-manifests
* Tmp: Trying out @am11's branch.
* Tmp2: Trying out @am11's branch.
* Tmp3: Replace the last usage of main in clone action.
* Update eng/pipelines/coreclr/templates/build-perf-bdn-app.yml
Co-authored-by: Adeel Mujahid <3840695+am11@users.noreply.github.com>
* Update eng/pipelines/coreclr/templates/perf-job.yml
Co-authored-by: Adeel Mujahid <3840695+am11@users.noreply.github.com>
* Update eng/pipelines/runtime-wasm-perf.yml
Co-authored-by: Adeel Mujahid <3840695+am11@users.noreply.github.com>
---------
Co-authored-by: Larry Ewing <lewing@microsoft.com>
Co-authored-by: Jackson Schuster <36744439+jtschuster@users.noreply.github.com>
Co-authored-by: Alexander Köplinger <alex.koeplinger@outlook.com>
Co-authored-by: Ilona Tomkowicz <itomkowicz@microsoft.com>
Co-authored-by: Steve Molloy <smolloy@microsoft.com>
Co-authored-by: Adeel Mujahid <3840695+am11@users.noreply.github.com>
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.
152
152
153
-
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:
153
+
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:
154
154
155
155
```
156
156
buildTransitive\net461\Microsoft.Extensions.Configuration.UserSecrets.targets <- This file is generated and throws an Error
157
157
buildTransitive\net462\_._
158
158
buildTransitive\netcoreapp2.0\Microsoft.Extensions.Configuration.UserSecrets.targets <- This file is generated and throws an Error
159
-
buildTransitive\net6.0\_._
159
+
buildTransitive\net8.0\_._
160
160
```
161
161
162
162
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:
buildTransitive\net461\Microsoft.Extensions.Configuration.UserSecrets.targets <- This file is generated and throws an Error
167
167
buildTransitive\net462\Microsoft.Extensions.Configuration.UserSecrets.targets <- This file is hand authored and doesn't throw an error
168
168
buildTransitive\netcoreapp2.0\Microsoft.Extensions.Configuration.UserSecrets.targets <- This file is generated and throws an Error
169
-
buildTransitive\net6.0\Microsoft.Extensions.Configuration.UserSecrets.targets <- This file is hand authored and doesn't throw an error
169
+
buildTransitive\net8.0\Microsoft.Extensions.Configuration.UserSecrets.targets <- This file is hand authored and doesn't throw an error
170
170
```
171
171
172
172
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.
Copy file name to clipboardexpand all lines: docs/coding-guidelines/project-guidelines.md
+3-3
Original file line number
Diff line number
Diff line change
@@ -25,7 +25,7 @@ Below is a list of all the various options we pivot the project builds on:
25
25
## Individual build properties
26
26
The following are the properties associated with each build pivot
27
27
28
-
-`$(BuildTargetFramework) -> Any .NETCoreApp or .NETFramework TFM, e.g. net9.0`
28
+
-`$(BuildTargetFramework) -> Any .NETCoreApp or .NETFramework TFM, e.g. net10.0`
29
29
-`$(TargetOS) -> windows | linux | osx | freebsd | ... | [defaults to running OS when empty]`
30
30
-`$(Configuration) -> Debug | Release | [defaults to Debug when empty]`
31
31
-`$(TargetArchitecture) - x86 | x64 | arm | arm64 | [defaults to x64 when empty]`
@@ -59,7 +59,7 @@ A cross-targeting project which targets specific platform with `$(NetCoreAppCurr
59
59
A full or individual project build is centered around BuildTargetFramework, TargetOS, Configuration and TargetArchitecture.
60
60
61
61
1.`$(BuildTargetFramework), $(TargetOS), $(Configuration), $(TargetArchitecture)` can individually be passed in to change the default values.
62
-
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`.
62
+
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`.
63
63
3. When building an individual project (either from the CLI or an IDE), all target frameworks are built.
64
64
65
65
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).
@@ -163,7 +163,7 @@ In the src directory for a library there should be only **one** `.csproj` file t
163
163
164
164
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.
165
165
166
-
Other target frameworks than .NETCoreApp latest (i.e. `netstandard2.0`, `net462`, `net6.0`) should use ProjectReference items to reference dependencies.
166
+
Other target frameworks than .NETCoreApp latest (i.e. `netstandard2.0`, `net462`, `net8.0`) should use ProjectReference items to reference dependencies.
167
167
168
168
### src\ILLink
169
169
Contains the files used to direct the trimming tool. See [ILLink files](../workflow/trimming/ILLink-files.md).
@@ -147,8 +147,8 @@ make it self-contained by adding a RuntimeIdentifier (RID).
147
147
```XML
148
148
<PropertyGroup>
149
149
<OutputType>Exe</OutputType>
150
-
<!-- Ensure that the target framework is correct e.g. 'net9.0' -->
151
-
<TargetFramework>net9.0</TargetFramework>
150
+
<!-- Ensure that the target framework is correct e.g. 'net10.0' -->
151
+
<TargetFramework>net10.0</TargetFramework>
152
152
<!-- modify build in this line with version reported by `dotnet --info` as above under ".NET runtimes installed" -> Microsoft.NETCore.App -->
153
153
<!-- 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 -->
Copy file name to clipboardexpand all lines: docs/project/glossary.md
+1-1
Original file line number
Diff line number
Diff line change
@@ -49,7 +49,7 @@ terminology.
49
49
| SPCL |`System.Private.CoreLib` - the lowest managed assembly in the libraries stack that contains `System.Object`, `String`, etc. |
50
50
| 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). |
51
51
| 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. |
52
-
| TFM |[Target Framework Moniker](https://learn.microsoft.com/dotnet/standard/frameworks) such as `net6.0` or `netstandard2.0`. |
52
+
| TFM |[Target Framework Moniker](https://learn.microsoft.com/dotnet/standard/frameworks) such as `net8.0` or `netstandard2.0`. |
53
53
| 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. |
54
54
| URT | Universal Runtime. Ancient name for what ended up being .NET, is used in the WinError facility name FACILITY_URT. |
55
55
| 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. |
Copy file name to clipboardexpand all lines: docs/workflow/building/coreclr/nativeaot.md
+2-2
Original file line number
Diff line number
Diff line change
@@ -27,7 +27,7 @@ The paths to major components can be overridden using `IlcToolsPath`, `IlcSdkPat
27
27
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:
28
28
29
29
* Add the package directory to your `nuget.config` file. For example, add `<add key="local" value="C:\runtime\artifacts\packages\Release\Shipping" />`
30
-
* Run `dotnet add package Microsoft.DotNet.ILCompiler -v 9.0.0-dev` to add the local package reference to your project.
30
+
* Run `dotnet add package Microsoft.DotNet.ILCompiler -v 10.0.0-dev` to add the local package reference to your project.
31
31
* 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.
32
32
33
33
## High Level Overview
@@ -62,7 +62,7 @@ Typical workflow for working on the compiler:
62
62
* Open `ilc.sln` in Visual Studio
63
63
* Set "ILCompiler" project in solution explorer as your startup project
64
64
* Set Working directory in the project Debug options to your test project directory, e.g. `C:\test`
65
-
* 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`
65
+
* 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`
Copy file name to clipboardexpand all lines: docs/workflow/building/libraries/README.md
+1-1
Original file line number
Diff line number
Diff line change
@@ -76,7 +76,7 @@ The libraries build has two logical components, the native build which produces
76
76
77
77
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:
78
78
79
-
-`-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`)
79
+
-`-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`)
80
80
-`-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`)
81
81
-`-configuration|-c Debug|Release` controls the optimization level the compilers use for the build. It defaults to `Debug`. (msbuild property `Configuration`)
82
82
-`-arch` identifies the architecture for the build. It defaults to `x64` but possible values include `x64`, `x86`, `arm`, or `arm64`. (msbuild property `TargetArchitecture`)
0 commit comments