This basically means ingesting https://github.com/NuGet/NuGet.Client/blob/dev/src/NuGet.Core/NuGet.Build.Tasks.Console/NuGet.Build.Tasks.Console.csproj into the SDK.
We should discuss with the .NET Core team what branches they want the changes in.
fyi @jeffkl
cc @NuGet/nuget-client This is a high ROI issue. Worth picking up as soon as possible to ensure everyone can try out the restore with improved msbuild evaluation.
I'm pretty sure we need to insert the new package here: https://github.com/dotnet/toolset/blob/8a99876e947686898a5208e26cac316dfeff449a/src/redist/redist.csproj#L22
I believe the package is NuGet.Build.Tasks.Console and it works because it's just adding its stuff to any\contentFiles like the other packages.
The toolset repo has moved to dotnet/sdk. The new location is here: https://github.com/dotnet/sdk/blob/2ccaa037745ac05043ce1f9420cca121754b6e8b/src/Layout/redist/redist.csproj#L22.
Submitted https://github.com/dotnet/sdk/pull/10794
I believe the package is NuGet.Build.Tasks.Console and it works because it's just adding its stuff to any\contentFiles like the other packages.
CSC : error CS2015: 'F:\workspace_work\1\s.packages\nuget.build.tasks.console\5.6.0-preview.1.6478\contentFiles\any\netcoreapp2.1NuGet.Build.Tasks.Console.dll' is a binary file instead of a text file [F:\workspace_work\1\s\src\Layout\redist\redist.csproj]
from https://dev.azure.com/dnceng/public/_build/results?buildId=550640.
@jeffkl putting a binary into the contentFiles directory isn't allowed nor recommended. We are usually putting our executable binaries into the tools directory as recommended in the docs. Any reason why you chose contentFiles?
Thinking about this further I guess we would need to put the binary into the lib folder so that it gets copied into the output directory in redist.csproj?
Yeah I was trying to mirror what the NuGet.Build.Tasks package does but I guess I got it wrong.

Looks like the assemblies need to be in the lib folder. My intent was to have NuGet.RestoreEx.targets in this package as well since I added this condition to make it so the feature wasn't available until the insertion but that file accidentally is going into NuGet.Build.Tasks.
Should I send a PR to fix the package?
Yes please, we are desperately waiting for that feature as otherwise the no-op restore time in dotnet/runtime is far too high.
I think we should consider pulling this into .NET Core SDK 3.1.300. @dsplaisted, does that sound reasonable?
I think we should consider pulling this into .NET Core SDK 3.1.300. @dsplaisted, does that sound reasonable?
Yes please!
I wanted to start that conversation on the side as well.
It's super important to get feedback on this as it is a major rewrite.
The improvements are also drastic.
Most helpful comment
I think we should consider pulling this into .NET Core SDK 3.1.300. @dsplaisted, does that sound reasonable?