[release/8.0] Backport MSBuild 17.8.3

[ericstj]

@mthalman @ViktorHofer @MichaelSimons
Not sure if this is enough, but giving it a try.

[ericstj]

@ViktorHofer this is still failing with a pre-built for Microsoft.VisualStudio.Setup.Configuration.Interop but I see all the references are commented out. Is that just because it's downloading the packages for these right now since they aren't yet in the build and the official packages still have the dependency?

[ViktorHofer]

Installed Microsoft.Build.Utilities.Core 17.8.3 from https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-public/nuget/v3/index.json with content hash ex8Sjx02q0FmForLRFItB82sJx5s2JRWIpJgYDW1g7xLUoFlKLoNp67UwS5xN8YcYBkT7vRxXeYx/dQ96KaWtg==.

The problem here is that when restoring Microsoft.Build.Tasks.Core, the dependent Microsoft.Build.Utilities.Core project gets restored from dotnet-public instead of from the local source-built-upstream-cache directory.

@NikolaMilosavljevic @MichaelSimons could this be related to the change in NuGet.Client that made you switch to package source mappings in the VMR?

[mthalman]

Installed Microsoft.Build.Utilities.Core 17.8.3 from https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-public/nuget/v3/index.json with content hash ex8Sjx02q0FmForLRFItB82sJx5s2JRWIpJgYDW1g7xLUoFlKLoNp67UwS5xN8YcYBkT7vRxXeYx/dQ96KaWtg==.

The problem here is that when restoring Microsoft.Build.Tasks.Core, the dependent Microsoft.Build.Utilities.Core project gets restored from dotnet-public instead of from the local source-built-upstream-cache directory.

@NikolaMilosavljevic @MichaelSimons could this be related to the change in NuGet.Client that made you switch to package source mappings in the VMR?

You're exactly right. The change to use package source mappings was only done for the VMR orchestrator, not for the source build implementation of Arcade that runs for each individual repo. I'm honestly surprised this hasn't exposed more issues in other repos.

[ViktorHofer]

I think this only impacts release/8.0 because main is still on an SDK that doesn't have the underlying NuGet change:

source-build-reference-packages/global.json

Line 3 in da7ec4b

"dotnet": "9.0.100-preview.1.24101.2"

My guess is that as soon as we update the SDK in main, source-build will start failing non-deterministically in the repo source-build legs.

[MichaelSimons]

This is easier to solve here. All of the feeds in the NuGet.config are not necessary for the source-build. They are only needed for the generate tooling. The build should only be using the CurrentRepoSourceBuiltNupkgCacheDir.

[mthalman]

I think this only impacts release/8.0 because main is still on an SDK that doesn't have the underlying NuGet change

I'm confused. Why is this behavior occurring at all? This is using 8.0 SDK which shouldn't have the change in NuGet that added the indeterminism.

[MichaelSimons]

Taking a step back and looking at the PR, I don't think this is valid. The new reference packages are targeting the current TFM (net 8.0) and are bringing in the 8.0 targeting pack which we don't want. The 8.0 branch should not target net8.0. I conjecture, for source-build runtime should be picking up the latest/n-1.

[ViktorHofer]

I'm confused. Why is this behavior occurring at all? This is using 8.0 SDK which shouldn't have the change in NuGet that added the indeterminism.

AFAIK NuGet double inserts into main and 8.0.

[ericstj]

I only opened this because you said it was needed in dotnet/runtime#100595 (comment). Seems like that's no longer the case. I'll close this for now and we can discuss what the best solution is in that other PR.