Target net11.0 / .NET 11

[ViktorHofer]

Contributes to #118583

For reference, this was last year's PR for net10.0. #106599

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/runtime-infrastructure
See info in area-owners.md if you want to be subscribed.

[am11]

@ViktorHofer, does it depend on dotnet/dotnet#2271?

[ViktorHofer]

Not necessarily but it would be better to get that in first. I included the branding update in this PR (see eng/Versions.props changes).

[ViktorHofer]

D:\a_work\1\s.dotnet\sdk\10.0.100-rc.2.25502.107\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.TargetFrameworkInference.targets(188,5): error NETSDK1045: The current .NET SDK does not support targeting .NET 11.0. Either target .NET 10.0 or lower, or use a version of the .NET SDK that supports .NET 11.0. Download the .NET SDK from https://aka.ms/dotnet/download [D:\a_work\1\s\src\installer\tests\Assets\Projects\HostApiInvokerApp\HostApiInvokerApp.csproj]

Need this property: https://github.com/dotnet/runtime/blob/69310d88a431951addcc65ad093ea59528f80c48/Directory.Build.targets#L56C6-L56C30

[steveisok]

<AppendTargetFrameworkToOutputPath>true does make a difference:

@am11 good suggestion (as usual)

[ericstj]

My guess is that the Assemblies parameter is missing a path to corelib. Look further upstream to see where that comes from.

It looks to me like something in https://github.com/dotnet/runtime/blob/main/src/mono/wasm/build/WasmApp.Common.targets is failing to publish the runtime bits. Was talking to @steveisok offline and it could be due to no runtime pack being available. It looks like in 10.0 we had 10.0 runtime packs available by the time we were retargeting but we don't have that right now. I'm not certain if this is the problem, but it seems plausible.

[ericstj]

/native/managed/cdac/ --> Unable to find package Microsoft.AspNetCore.App.Runtime.linux-riscv64. No packages exist with this id in source(s) - @steveisok

Hitting this for linux-riscv64, linux-loongarch64, and freebsd-x64. They aren't connected to live runtime packs. Frankly I don't understand why these components need runtime packs at all since they don't appear to be applications. I discussed with @steveisok and he will follow up to get understanding.

WasmBuildTests --> You must install or update .NET to run this application - @lewing

The helix tests are provisioning an older runtime (RC1) than the test assembly was built with (RC2). Tests could be updated to install a matching one. Or we could wait for the GA SDK to land, in which case we'd be depending on the same runtime for both.

HostActivation.Tests "hanging" on MacOS - likely unrelated - @agocke

https://helixr1107v0xdeko0k025g8.blob.core.windows.net/dotnet-runtime-refs-pull-121853-merge-1e74acd73de14be18f/HostActivation.Tests/1/console.4278473c.log

Looks to me like a normal test execution that happened to run into a 5 minute timeout. I see tests progressing and approaching the 5 minute mark. It could be that these are slower for some reason, but 5 minutes seems to me to be too low given the number of tests here. I had a look and do see other PRs hitting a similar timeout, like @elinor-fung's here https://helixr1107v0xdeko0k025g8.blob.core.windows.net/dotnet-runtime-refs-pull-122212-merge-7cbc8ba20b1342dd81/HostActivation.Tests/1/console.e1ce42ad.log (build, PR)

[am11]

Hitting this for linux-riscv64, linux-loongarch64, and freebsd-x64. They aren't connected to live runtime packs.

They are the community supported platforms using bootstrapping mechanism (aka from-scratch build): https://github.com/dotnet/runtime/blob/3e44f568cb24aa68f863d925b67fa5408b734d54/docs/workflow/building/coreclr/cross-building.md#building-coreclr-with-bootstrapping. First pass builds minimal subsets: shared framework and tools, second pass moves them in artifacts/bootstrap and uses that path to find apphost, nativeaot/crossgen2 runtime packs, RID graph etc. for the full build. So they use a different type of live packs.

Frankly I don't understand why these components need runtime packs at all since they don't appear to be applications. I discussed with @steveisok and he will follow up to get understanding.

They need it to publish packages with executables during the build like Microsoft supported platforms.

[ericstj]

They need it to publish packages with executables during the build like Microsoft supported platforms.

Are they applications that actually ship the runtime? These looked to me like libraries that would depend on something else to bring the runtime. If they don't need runtime packs, they shouldn't restore them (change properties that are making the SDK restore these). If they do need the runtime packs, we need to plumb the live ones.

[am11]

Yes, all tools which are in linux-arm64 SDK are included in SDKs for those RIDs, e.g. https://github.com/filipnavara/dotnet-riscv/releases/tag/10.0.100.

[steveisok]

They need it to publish packages with executables during the build like Microsoft supported platforms.

I think it might be easier to skip the cdac subsets on the community legs for now and bring it back once we have an 11 sdk and packs.

[am11]

@steveisok, could you please add AppendTargetFrameworkToOutputPath prop in src/native/managed/cdac/Directory.Build.props: #121853 (comment). If that doesn't work, then lets disable cdac.

[steveisok]

@steveisok, could you please add AppendTargetFrameworkToOutputPath prop in src/native/managed/cdac/Directory.Build.props: #121853 (comment). If that doesn't work, then lets disable cdac.

I moved it out and it still made no difference. I had that in mscordaccore_universal.csproj from an earlier commit that fixed packaging. I'll disable cdac on community targets for now and file an issue with the intent of restoring after we get an 11 SDK / packs.

[am11]

--- a/src/native/managed/cdac/Directory.Build.props
+++ b/src/native/managed/cdac/Directory.Build.props
@@ -1,5 +1,11 @@
 <Project>
     <Import Project="..\Directory.Build.props" />
+
+    <PropertyGroup>
+      <AppendTargetFrameworkToOutputPath>false</AppendTargetFrameworkToOutputPath>
+      <AppendTargetFrameworkToOutputPath Condition="'$(BuildingInsideVisualStudio)' == 'true'">true</AppendTargetFrameworkToOutputPath>
+    </PropertyGroup>
+
     <ItemGroup>
       <AssemblyAttribute Include="System.Diagnostics.CodeAnalysis.ExperimentalAttribute">
         <_Parameter1>NETCDAC0001</_Parameter1>

[am11]

I didn't asked to move it out, I meant to add it in cDAC 🙂

[steveisok]

I didn't asked to move it out, I meant to add it in cDAC 🙂

Bad use of words - meant the same thing.

[am11]

I didn't find that change pushed in this PR. Did you tried it locally on some community platform? Could you show the command (or just push to branch so we can see the error in CI).

[steveisok]

I didn't find that change pushed in this PR. Did you tried it locally on some community platform? Could you show the command (or just push to branch so we can see the error in CI).

I tried it locally on cross building freebsd. Same exact restore error.

[am11]

I tested this patch am11@1cfe520 and built:

• freebsd-x64: https://github.com/am11/CrossRepoCITesting/actions/runs/19975712524
  using /runtime/build.sh -ci -arch x64 -os freebsd -cross -s clr+libs+host+packs -c Debug -rc Checked --keepnativesymbols true --bootstrap

• linux-riscv64: https://github.com/am11/CrossRepoCITesting/actions/runs/19975681090
  using /runtime/build.sh -ci -arch riscv64 -cross -s clr+libs+host+packs+tools.cdac -c Debug -rc Checked --keepnativesymbols true --bootstrap

both passed the restore and cDAC package build and later failing at ApiCompat stage.

The reason why I was asking you for the command or pushing the change because just like my workflow, runtime CI is also using --bootstrap for community platform along --cross arg and that's the only supported combination for community platform these days. It's documented by @jkoritzinsky in the link I shared above.

[elinor-fung]

HostActivation.Tests "hanging" on MacOS - likely unrelated

Yep, unrelated: #122171 (comment)

[jkoritzinsky]

Looking at the patch, I believe @am11's patch is the right solution for the cDAC problem.

[steveisok]

both passed the restore and cDAC package build and later failing at ApiCompat stage.

I tried it both locally and I see @lewing pushed a change. Neither work.

The TargetFramework part of the change produces Ahead-of-time compilation is not supported for the target runtime identifier 'freebsd-x64'. That is a different message, but it's still tanking on restore.

[lewing]

#122258 has sdk branding flow which will make it easier to solve the remaining workload issues here but we will keep both up to date. dotnet/sdk#52031 is in progress for the sdk
.