why is it trying to restore the linux-x64 runtime pack and not the centos.10-x64 which was produced by the build? I think this is the real issue and we were just masking it before.

The reason for this stems from https://github.com/dotnet/dotnet/pull/3123/files#diff-b3a09e242d3219b910364fa94d2654b8ec17d19a5f79a924eba97da538fba4a0R707. Source-build dynamically adds the current RID to NetCoreAppHostRids, NetCoreRuntimePackRids, and AspNetCoreRuntimePackRids here because those are the packs it builds. Because the 10 known framework reference was updated to Net100RuntimePackRids, it no longer get the current rid added.

The other problem is that all of the Known references for 10 aren't reference the 10.0 versions - example. Updating this to 10 introduces other issues in tests because the 10 runtime is not installed with the 11 SDK. It feels like these issues all stem from the templates not being updated to 11 yet.

I don't think that is something to fix in this PR. My recommendation is to disable the source-build web scenario test until the templates have been updated and log a tracking issue to re-enable them.

Hmm this is blocking the rebranding work to some degree. We can workaround it (by making changes directly there) but no dependency flow from sdk into the VMR for over 6 weeks is tragic. cc @marcpopMSFT

Doesn't look like there's much work left here? Some assembly that fails to get invoked via dotnet in the fsharp repo.

In the bootstrap of fsharp of source build stage 2, it's trying to reference Microsoft.NETCore.App.Runtime.linux-x64 (the portable package) when it should be using microsoft.netcore.app.runtime.centos.10-x64 (non-portable).

/__w/1/s/src/fsharp/buildtools/fslex/fslex.fsproj error NU1100: Unable to resolve 'Microsoft.NETCore.App.Runtime.linux-x64 (= 10.0.0-ci)' for 'net10.0'. PackageSourceMapping is enabled, the following source(s) were not considered: /__w/1/s/.dotnet/library-packs, /__w/1/s/.dotnet/sdk/10.0.100-ci/FSharp/library-packs, prebuilt, previously-source-built, reference-packages, source-built-source-build-reference-packages, source-built-transport-arcade. [/__w/1/s/src/fsharp/buildtools/fslex/fslex.fsproj]

Investigating...

In the bootstrap of fsharp of source build stage 2, it's trying to reference Microsoft.NETCore.App.Runtime.linux-x64 (the portable package) when it should be using microsoft.netcore.app.runtime.centos.10-x64 (non-portable).

/__w/1/s/src/fsharp/buildtools/fslex/fslex.fsproj error NU1100: Unable to resolve 'Microsoft.NETCore.App.Runtime.linux-x64 (= 10.0.0-ci)' for 'net10.0'. PackageSourceMapping is enabled, the following source(s) were not considered: /__w/1/s/.dotnet/library-packs, /__w/1/s/.dotnet/sdk/10.0.100-ci/FSharp/library-packs, prebuilt, previously-source-built, reference-packages, source-built-source-build-reference-packages, source-built-transport-arcade. [/__w/1/s/src/fsharp/buildtools/fslex/fslex.fsproj]

Investigating...

This is caused by the same issue described in #3123 (comment), specifically this change: dotnet/sdk#51429.

It causes the KnownFrameworkReference of the built SDK to be this:

<KnownFrameworkReference Include="Microsoft.NETCore.App"
                              TargetFramework="net10.0"
                              RuntimeFrameworkName="Microsoft.NETCore.App"
                              DefaultRuntimeFrameworkVersion="10.0.0-ci"
                              LatestRuntimeFrameworkVersion="10.0.0-ci"
                              TargetingPackName="Microsoft.NETCore.App.Ref"
                              TargetingPackVersion="10.0.0-ci"
                              RuntimePackNamePatterns="Microsoft.NETCore.App.Runtime.**RID**"
                              RuntimePackRuntimeIdentifiers="linux-arm;linux-arm64;linux-musl-arm64;linux-musl-x64;linux-x64;osx-x64;tizen.4.0.0-armel;tizen.5.0.0-armel;win-arm64;win-x64;win-x86;linux-musl-arm;osx-arm64;linux-s390x;linux-loongarch64;linux-bionic-arm;linux-bionic-arm64;linux-bionic-x64;linux-bionic-x86;linux-ppc64le;freebsd-x64;freebsd-arm64;linux-riscv64;linux-musl-riscv64;linux-musl-loongarch64;android-arm64;android-x64"
                              />

This lacks the centos.10-x64 RID in RuntimePackRuntimeIdentifiers.

@akoeplinger - You mention that this could be resolved by the .NET 11 rebranding? dotnet/sdk#51429 (comment)

@akoeplinger - The rebranding changes didn't fix anything. Still getting the same error due to using the portable RID: https://dev.azure.com/dnceng-public/public/_build/results?buildId=1220819&view=logs&jobId=3d049f34-eb7f-5dcd-1393-71cd43c7f766&j=3d049f34-eb7f-5dcd-1393-71cd43c7f766&t=c7dd373c-04d4-57bb-b62b-5b0308668e5e. If dotnet/sdk#51429 has the correct changes, then what is the correct fix for this?