Notification for subscribed users from https://github.com/dotnet/dotnet:

@dotnet/product-construction

Action requested: Please take a look at this failing automated dependency-flow pull request's checks; failures may be related to changes which originated in your repo.

• This pull request contains changes from your source repo (https://github.com/dotnet/dotnet) and seems to have failed checks in this PR. Please take a peek at the failures and comment if they seem relevant to your changes.
• If you're being tagged in this comment it is due to an entry in the related Maestro Subscription of the Build Asset Registry. If you feel this entry has added your GitHub login or your GitHub team in error, please update the subscription to reflect this.
• For more details, please read the Arcade Darc documentation

@NuGet/nuget-client there's a NuGet Audit vulnerability warning for Microsoft.Build.Tasks.Core/17.12.6. Should this version get upgraded to something newer?

I see the version hardcoded here:

Unrelated but it looks like all versions referenced in that file are marked as vulnerable. Shouldn't all of them get updated?

We build against 17.11 in non-source build scenarios.

We can probably use 17.12 in general.

We basically need to match whatever https://learn.microsoft.com/en-us/dotnet/core/porting/versioning-sdk-msbuild-vs#targeting-and-support-rules says the min version is.

We'd need to figure out what the min msbuild version of the next version of the SDK before updating.

Any idea why this isn't a problem in the main build? IOW why are those vulnerable dependencies not showing up anywhere?

@ViktorHofer we might have fixed this in #6488, can this PR be rebased?

[PR Review] @jeffkl would you please work with @ViktorHofer in understanding how to review this and how to move it forward?

@premun we are still getting eng/common updates into NuGet backflow PRs. Is this intentional?

Yes, until we decide how to solve this (dotnet/dotnet#1054)

I'm not sure what you mean by decide. Until nuget-client onboards to Arcade (which isn't funded), we need to exclude eng/common updates.

But we need to figure out the "how". The service always flows these things in a bundle and even if we wanted to hardcode this, it's not as simple as one if statement somewhere.

I still don't understand why we can't have the files checked in. There is already some eng/common in the repo.

Submitted dotnet/arcade-services#4994 to be able to pin the .NET SDK to a specific version.

@jeffkl @nkolev92 can you help with the NuGet.Client-PrivateDev pipeline failure? Otherwise, this PR should now be ready. It contains:

• "Recent" changes that were made in the VMR that backflow into this repository
• The "/eng/common" layout which will be needed for onboarding to Arcade and partially needed for onboarding to OneLocBuild localization (related to @mmitche's work around using xlf localization).
• The "tools.pinned" attribute in global.json which prevents Maestro (the service that opens these PRs) from updating the .NET SDK version as NuGet intentionally stays on 9.0.300.

Gentle ping. We need to get this in so that the sync into and from the VMR is correctly working.