Only build BuildAfterTargeting pack on win-x64

[wtgodbe]

Fixes #60530. This project just produces some .nupkg's, and doesn't build anything for the sharedFx/Ref pack. We can be certain that it never will, because by definition it builds after the targeting pack.

BuildAfterTargetingPack.csproj introduces flakiness into the build because it sometimes causes a race condition that leads to file conflicts - therefore we should build it as infrequently as possible (only on win-x64).

Test build: https://dev.azure.com/dnceng/internal/_build/results?buildId=2652111&view=results

[Copilot]

Copilot reviewed 1 out of 1 changed files in this pull request and generated no comments.

[Copilot]

Copilot reviewed 1 out of 1 changed files in this pull request and generated no comments.

[wtgodbe]

There was a publishing failure in the VMR build - I don't think it's related, but not sure. Waiting to hear back from some VMR folks

Edit: The failure is unrelated

[ViktorHofer]

What packages does this produce? In the VMR, we prefer every vertical to produce rid agnostic packages as upstream consumers might depend on it.

[wtgodbe]

What packages does this produce? In the VMR, we prefer every vertical to produce rid agnostic packages as upstream consumers might depend on it.

Microsoft.AspNetCore.Grpc.JsonTranscoding & Microsoft.AspNetCore.Grpc.Swagger are the two shipping packages produced by this project (they have to build after the targeting pack because they use Swashbuckle.AspNetCore, which has a FrameworkReference to Microsoft.Aspnetcore.App in order to resolve Microsoft.Aspnetcore.Routing)

[ViktorHofer]

Did you double check that none of these packages are used in upstream repos like sdk? This change feels like a workaround to a build infrastructure issue to me but if diagnosing the actual issue isn't feasible or wouldn't help short-term, I'm fine with it as-is.

[wtgodbe]

Did you double check that none of these packages are used in upstream repos like sdk? This change feels like a workaround to a build infrastructure issue to me but if diagnosing the actual issue isn't feasible or wouldn't help short-term, I'm fine with it as-is.

Yeah, the gRPC packages are not referenced by SDK. I agree this is a hack, but I'm bothered enough by the build reliability hit that I think it warrants doing something in the short term. Long-term I want to get rid of all of our custom reference resolution stuff, which should improve issues like this one