Fix NuGet.Build.Tasks.Console package

[jeffkl]

Bug

Fixes: NuGet/Home#9267
Regression: No

• Last working version:
• How are we preventing it in future:

Fix

• Remove NuGet.RestoreEx.targets from NuGet.Build.Tasks package
• Add NuGet.RestoreEx.targets to NuGet.Build.Tasks.Console package under runtimes\any\native
• Package NuGet.Build.Tasks.Console.dll in lib instead of contentFiles\any

Testing/Validation

Tests Added: No
Reason for not adding tests: Package layout
Validation: Manual

NuGet.Build.Tasks

NuGet.Build.Tasks.Console

[ViktorHofer]

@jeffkl a test failed, flaky or related?

[jeffkl]

Flaky, I'll restart it

[nkolev92]

FYI @NuGet/nuget-client
I'll merge this as soon as it's green because we want to get this in, in our next insertion this week.

[ViktorHofer]

When you say inseration, you are talking about the VS side here, right? Official builds should be flowing on daily basis to dotnet/sdk so we should be able to consume that change further.

[nkolev92]

When you say inseration, you are talking about the VS side here, right? Official builds should be flowing on daily basis to dotnet/sdk so we should be able to consume that change further.

We do all of them at the same time. So we only promote builds when we insert.
We wanted more fine grained control over what we insert.

In the 3.x days with the separate repos, NuGet insertions into the SDK were painful.
You'd need to insert CLI, insert SDK with the new CLI built from the insertion and then insert the SDK with the new NuGet bits back into the CLI.

[ViktorHofer]

We do all of them at the same time. So we only promote builds when we insert.
We wanted more fine grained control over what we insert.

I might be missing something here. Aren't we flowing all official builds (which I assume are just batched per commit rolling builds in internal) live to dotnet/sdk? How is that connected to build promotion?

[nkolev92]

There's probably something lost in translation as I don't understand the arcade infra and all the terminology around it so I'll explain what we do.

1. Each official build we publish to the build registry and we upload the manifest.
   

   NuGet.Client/build/vsts_build.yaml

   Lines 531 to 548 in d39e857

   	- task: CmdLine@2
   	displayName: "Publish the packages to the .NET Core build asset registry (BAR)"
   	inputs:
   	script: dotnet msbuild ..\build\publish.proj /t:PublishPackagesToBuildAssetRegistry /p:NuGetClientNupkgsDirectoryPath=$(Build.Repository.LocalPath)\artifacts\$(NupkgOutputDir) /p:FeedUrl=$(DotNetFeedUrl) /p:BuildId=$(Build.BuildNumber) /p:RepoBranch=$(Build.SourceBranchName) /p:RepoCommit=$(Build.SourceVersion) /p:RepoUri=$(Build.Repository.Uri) /p:ManifestFilePath=$(ManifestFilePath) /p:AccountKey=$(dotnetfeed-storage-access-key-1)
   	workingDirectory: cli
   	failOnStderr: true
   	env:
   	DOTNET_SKIP_FIRST_TIME_EXPERIENCE: true
   	DOTNET_MULTILEVEL_LOOKUP: true
   	condition: " and(succeeded(),eq(variables['PublishArtifactsToDotNetBuildAssetRegistry'], 'true'), eq(variables['BuildRTM'], 'false')) "
   	- task: PowerShell@1
   	displayName: "Upload the build manifest file as a build artifact"
   	inputs:
   	scriptType: "inlineScript"
   	inlineScript: |
   	Write-Host "##vso[task.uploadfile]$(ManifestFilePath)"
   	condition: " and(succeeded(),eq(variables['PublishArtifactsToDotNetBuildAssetRegistry'], 'true'), eq(variables['BuildRTM'], 'false')) "

2. When we insert(once a week), we use darc add-build-to-channel to add the certain build in the ingestion pipeline.

[ViktorHofer]

When we insert(once a week), we use darc add-build-to-channel to add the certain build in the ingestion pipeline.

Thanks a lot, that was the missing piece. I believed that the NuGet dependency was stale as I didn't see any auto-updates.