Restore trimming test projects serially

[wtgodbe]

Should fix the last flavor of #61178. Trimming tests are built by BuildAfterTargetingPack.csproj, which first calls Restore serially, then calls Test in parallel. But the trimming test projects were overwriting Restore with a no-op target, so the actual restoring was happening in parallel, in PublishTrimmedProjects, which gets called in the target chain for Test. If we have Restore actually restore, it'll happen serially like we want.

[Copilot]

Pull request overview

Adds a conditional restore retry in linker trimming tests to work around intermittent NuGet restore races (notably on Windows) when multiple trimming test projects restore shared TestConsoleApps concurrently.

Changes:

• Allows the initial Restore MSBuild invocation to continue after failure.
• Adds a second Restore invocation that runs only if the first restore failed.
• Documents the rationale and links the tracked issue.

[wtgodbe]

/backport to release/10.0

[github-actions]

Started backporting to release/10.0 (link to workflow run)

[wtgodbe]

That clearly didn't work. Trying something else

[wtgodbe]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).

[wtgodbe]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).

[wtgodbe]

/backport to release/10.0

[github-actions]

Started backporting to release/10.0 (link to workflow run)

[wtgodbe]

/backport to release/10.0

[github-actions]

Started backporting to release/10.0 (link to workflow run)

[OvesN]

@wtgodbe I received a reported pipeline failure with highly parallelized MSBuild that looks similar to what this PR is trying to fix. From my understanding, parallel Build phases each trigger a fallback Restore that recursively
walks into the same shared dependencies, causing concurrent writes of project.assets.json to the same obj/
directories, which crashes on MoveFile because the file already exists from the other process.

In the binlog I did not see the property SkipTrimmingProjectsRestore being set at all. It looks like the
BuildDelayedProjects target in BuildAfterTargetingPack.csproj restores the projects serially, but then builds them
in parallel without passing SkipTrimmingProjectsRestore=true, so each project's PublishTrimmedProjects triggers a
redundant restore that can race.

Should SkipTrimmingProjectsRestore=true also be passed in the Build call to complete this fix?

[wtgodbe]

@OvesN ah, yes, nice catch! Do you want to submit a PR for that?

[OvesN]

@wtgodbe
I'll leave this to aspnetcore team since you know better which build paths are always guaranteed to have Restore completed before reaching PublishTrimmedProjects. The Build call is clearly safe since Restore runs right above it in the same
target, but for Test and VSTest I'm not sure if Restore is always guaranteed to have run beforehand.

Do you want me to submit an issue?