Revert "Pack: reuse existing evaluations instead of forcing BuildProjectReferences=false (#7541)"

[kartheekp-ms]

Bug

This reverts commit ca0a648 related to the below NuGet issues.

• [Bug]: Pack target is causing unnecessary project evaluations which noticeably slows down a project's build Home#11530
• dotnet pack --include-source now includes build-generated source files (AssemblyInfo, AssemblyAttributes) in the symbols package Home#14998

Description

NuGet forward flow PR into dotnet VMR is failing with the below error.

/__w/_temp/previously-source-built-sdk/sdk/11.0.100-ci/NuGet.Build.Tasks.Pack.targets(232,5): error : An item with the same key has already been added. Key: /__w/1/s/src/aspnetcore/src/Security/Authorization/Core/src/Microsoft.AspNetCore.Authorization.csproj [/__w/1/s/src/aspnetcore/src/Components/Authorization/src/Microsoft.AspNetCore.Components.Authorization.csproj]
##[error]/mnt/vss/_work/_temp/previously-source-built-sdk/sdk/11.0.100-ci/NuGet.Build.Tasks.Pack.targets(232,5): error : An item with the same key has already been added. Key: /__w/1/s/src/aspnetcore/src/Security/Authorization/Core/src/Microsoft.AspNetCore.Authorization.csproj

Another VMR PR build failed with the same error: dotnet/dotnet#7907

I am not 100% sure yet but I am guessing ca0a648 commit might be the cause.

This failure is blocking @martinrrm from making progress on SDK side changes for NuGet/Home#6279 issue.

cc @baronfel

PR Checklist

• Meaningful title, helpful description and a linked NuGet/Home issue
• Added tests
• Link to an issue or pull request to update docs if this PR changes settings, environment variables, new feature, etc.

[baronfel]

@kartheekp-ms before this revert goes in, is there a binlog that I can reference in the future to investigate further and root cause?

[kartheekp-ms]

@kartheekp-ms before this revert goes in, is there a binlog that I can reference in the future to investigate further and root cause?

@Nigusu-Allehu Is there a way to obtain binlog from VMR builds? I checked the artifacts published for 1 failed build but couldn't locate the binlog for the failed job.

[nkolev92]

Remember to reopen the issues.

[kartheekp-ms]

@kartheekp-ms before this revert goes in, is there a binlog that I can reference in the future to investigate further and root cause?

@Nigusu-Allehu Is there a way to obtain binlog from VMR builds? I checked the artifacts published for 1 failed build but couldn't locate the binlog for the failed job.

@baronfel - I found binlogs in VMR build.

cc @Nigusu-Allehu

[Nigusu-Allehu]

@kartheekp-ms before this revert goes in, is there a binlog that I can reference in the future to investigate further and root cause?

@Nigusu-Allehu Is there a way to obtain binlog from VMR builds? I checked the artifacts published for 1 failed build but couldn't locate the binlog for the failed job.

I think this binlog might be helpful in the source build artifact

[baronfel]

Thanks folks! I'll dig in tomorrow to understand more.

[baronfel]

Summarizing the findings here -

Reusing the existing evaluations and associated project state meant that the supposed-to-be-private Item name _ProjectPathWithVersion from NuGet's own Pack Targets collided with the aspnetcore repo's own _ProjectPathWithVersion Item, which they also use for packaging related activities that are unrelated to NuGet's Pack implementation. Renaming either repo's Item type would sidestep the issue while not re-introducing the double-evaluation cost that resulted in so much re-work. Longer term, if MSBuild has a concept of namespacing or privacy, NuGet's and aspnetcore's 'internal' names for concepts could be whatever they wanted and not escape scope and collide.