You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This improves scheduling the inner repos and with that reduces the overall build time by getting runtime (which is on the hot path) to start to build earlier. Additionally, this makes the VMR build more aligned with the rest of the product by using P2Ps to build dependencies.
NuGet is responsible for calculating transitive project references in general. A project's project.assets.json file contains a node for the transitive p2ps. At build time a target then runs that reads that information and adds the transitive p2ps to an item group so that transitives are also getting built as part of the ResolveProjectReferences target. That's how the product works.
In the VMR we weren't defining P2P for the repo projects and therefore we never had that information available in the "default" way. Instead we had a custom target that retrieved that information. My PR basically removes that custom target and gets us onto the common path. Of course with some additional complexity... mostly because of BuildPass stuff.
The PR also removes the BuildRepoReferences target as we now build RepositoryReference items as P2Ps directly and rely on the ResolveProjectReferences SDK target.
This one is ready. Failures are unrelated (dry run signing issue in aspnetcore and android leg that times out)
ViktorHofer
changed the title
Use P2Ps transitive calcuation (from project.assets.json) instead of …
Build RepositoryReferences as P2Ps and use NuGet's transitive P2P calcuation
Jun 3, 2025
ViktorHofer
changed the title
Build RepositoryReferences as P2Ps and use NuGet's transitive P2P calcuation
Build RepositoryReferences as P2Ps and use NuGet's transitive P2P calculation
Jun 3, 2025
I trust you but given we haven't tested the later build passes here and you're touching them, mind running an official build (with signing disabled) to validate it?
I trust you but given we haven't tested the later build passes here and you're touching them, mind running an official build (with signing disabled) to validate it?
I ran the dotnet-unified-build-full pipeline in this PR and inspected the win-x64 BuildPass2 binlog. I couldn't find any regressions. The last two commits are just clean-up (adding comments and removing non necessary code) and shouldn't affect execution.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Continuation of 1801a22
This improves scheduling the inner repos and with that reduces the overall build time by getting runtime (which is on the hot path) to start to build earlier. Additionally, this makes the VMR build more aligned with the rest of the product by using P2Ps to build dependencies.
NuGet is responsible for calculating transitive project references in general. A project's project.assets.json file contains a node for the transitive p2ps. At build time a target then runs that reads that information and adds the transitive p2ps to an item group so that transitives are also getting built as part of the
ResolveProjectReferencestarget. That's how the product works.In the VMR we weren't defining P2P for the repo projects and therefore we never had that information available in the "default" way. Instead we had a custom target that retrieved that information. My PR basically removes that custom target and gets us onto the common path. Of course with some additional complexity... mostly because of BuildPass stuff.
The PR also removes the
BuildRepoReferencestarget as we now build RepositoryReference items as P2Ps directly and rely on theResolveProjectReferencesSDK target.