I have tested this by building this PR version of NuGet and inserting into a boostrap version of MSBuild that I also built myself.

I've verified that the two new properties work as expected when passing via command-line: /p:EmbedDGSpecInBinlog=false.

However I've found that setting EmbedDGSpecInBinlog to false in Directory.Build.props doesn't work when restoring a solution, because it doesn't get imported during Restore. Here are the files imported during Restore of the .sln.metaproj:

I did find that it works as expected when I create a Directory.Solution.props at the root of the repo:

<Project>
    <PropertyGroup>
        <EmbedDGSpecInBinlog>false</EmbedDGSpecInBinlog>
    </PropertyGroup>
</Project>

It then gets imported during Restore:

It also does work as expected when restoring a specific .csproj, Directory.Build.props does get imported in that case.

Another thing I've learned is that even if you set EmbedRestoreFilesInBinlog to false, .nuget.g.props and .nuget.g.targets files will be embedded anyway by virtue of all projects being imported automatically being embedded. We also still embed project.assets.json files by virtue of this logic:

https://github.com/dotnet/sdk/pull/16840/files

I've verified that EmbedProjectAssetsFile still works fine to control that embedding.

So technically to turn off embedding project.assets.json you need to set both EmbedRestoreFilesInBinlog as well as EmbedProjectAssetsFile, because they are now embedded from two separate places. I think this is fine for now, and we can later perhaps just delete the logic from dotnet/sdk#16840.

However this PR works fine for the main goal: to be able to turn off .dgspec files specifically and keep other files, which is the behavior I want for those large binlogs.

Another minor unexpected thing is that setting properties in Directory.Solution.props will only affect the solution restore. Setting EmbedProjectAssetsFile in Directory.Solution.props will have no effect as it won't be imported by individual project builds.

This PR has been automatically marked as stale because it has no activity for 7 days. It will be closed if no further activity occurs within another 90 days of this comment. If it is closed, you may reopen it anytime when you're ready again, as long as you don't delete the branch.

@jeffkl this continues to be super painful for us, my proposal is to merge something in to get us unblocked for the next release, and if you like, we can still find the proper nice solution later. I'm worried we'll miss the next train and I'll have to live with 900 MB binlogs for another several months.

@NuGet/nuget-client I have pushed a commit to update this pull request based on a conversation I had with the author. Please review.

e of the following?

I think this feature is only useful for us when a customer is reporting a problem and we need the dgspec. We would have them restore again with /p:RestoreEmbedFilesInBinlog=2 and then the binlog would contain more files. The dgspec isn't really useful for users and only for us. The assets file is already being embedded by the .NET SDK and the .g.props and g.targets are also being embedded automatically if the exist since they are imported. I'm going to send a follow-up PR to MSBuild to turn that off for restore because the files that get embedded are what are already on disk and not what NuGet generates.

But my opinion is that we don't need to document it at this time since its really only on when you enable the binary logger and these files have already been embedded by default for 2+ years.

OMG this makes me so happy! I can’t wait to consume this! Thanks!