@dotnet/nuget-team can you have a look a the failures here?

I see the following error:

D:\a_work\1\s\src\sdk\src\Layout\redist\targets\Crossgen.targets(144,5): error : Potentially missed crossgen for 'D:\a_work\1\s\src\sdk\artifacts\bin\redist\Release\dotnet-installer\sdk\10.0.100-ci\Sdks\NuGet.Build.Tasks.Pack\CoreCLR', directory does not exist [D:\a_work\1\s\src\sdk\src\Layout\redist\redist.csproj]

NuGet removed the SDKs NuGet.Build.Tasks.Pack folder in RC2.

Not really sure what's going on here and why it'd be looking for it there.

cc @zivkan

Oh I actually see that PR is in this changeset.
Given that it works in 10.0.1xx, I'm guessing there are some other changes that were needed that somehow didn't get backported?

I feel like there's some changes that haven't flown properly into main.

https://github.com/dotnet/sdk/pull/50902/files is not in https://github.com/dotnet/dotnet/blame/main/src/sdk/src/Tasks/Microsoft.NET.Build.Tasks/Microsoft.NET.Build.Tasks.csproj

In fact, it's seemingly more than 1 commit behind.

SDKs main has this: https://github.com/dotnet/sdk/blob/main/src/Tasks/Microsoft.NET.Build.Tasks/Microsoft.NET.Build.Tasks.csproj#L58-L60.

Originally I thought #3123 should solve it, but it seems like it contains only newer changes. #3123

I don't really know how those are supposed to flow, and you all probably understand it better than me, but it does make me concerned what other changes haven't flowed properly.

We can wait for #3123 to merge and then merge main here

Based on those changes, I'm not sure that'd be enough.

This the state of that file in the commit that's being added in that PR.

https://github.com/dotnet/sdk/blob/6a6992f5fc42dbd06cd24f3a7db40013035d3965/src/Tasks/Microsoft.NET.Build.Tasks/Microsoft.NET.Build.Tasks.csproj#L58-L59

@dotnet/nuget-team I cherry-picked the missing commits from #2126 into this PR so that this isn't dependent on the sdk PR getting merged first.

dotnet/sdk uses the inter-branch-merge flow so that changes automatically move forward from i.e. 1xx to 2xx and 2xx to main but many repos don't have that. Our recommendation is that any changes made directly in the VMR (like in the above linked PR) should get manually forward ported into other applicable branches. The VMR itself doesn't have any inter-branch-merge flow.

Spectre.Console.0.54.0

New prebuilt. I think this one was already discussed in Tactics for 1xx / 2xx and approved? @zivkan @dotnet/source-build

Source-build currently has Spectre.Console/0.52.0 in SBRP: https://github.com/dotnet/source-build-reference-packages/blob/1c0ba39805434d3be12679eb7fe5deb9a221e32c/eng/Versions.props#L22

We would need to update that to 0.54.0. Is the version update intentional?

We would need to update that to 0.54.0. Is the version update intentional?

I think that was an oversight when dotnet/source-build-reference-packages#1482 was created. The version property was not updated. It looks like we are building 0.54.0 but versioning it as 0.52.0

dotnet/sdk uses the inter-branch-merge flow so that changes automatically move forward from i.e. 1xx to 2xx and 2xx to main but many repos don't have that. Our recommendation is that any changes made directly in the VMR (like in the above linked PR) should get manually forward ported into other applicable branches. The VMR itself doesn't have any inter-branch-merge flow.

I'm trying to understand the action for us here.
What change did NuGet make in the VMR that needs ported manually?

I see there's some Spectre.Console changes here, those are not changes we made ourselves.

I see there's some Spectre.Console changes here, those are not changes we made ourselves.

NuGet/NuGet.Client@8e2579a. This one introduces the new dependency and therefore needs source-build / SBRP support. The expectation is that your team (potentially with the help from the source-build team) avoids the prebuilt that is currently flagged in the build. Looks like @MichaelSimons is already helping here.

I'm trying to understand the action for us here.
What change did NuGet make in the VMR that needs ported manually?

Mentioned above. The manual commits from #2126.

Ah, I see now.
Thanks for the clarification.

So basically, Andy merged a changed, that flowed from 10.0.1xx in the VMR to 10.0.1xx in .NET SDK.
https://github.com/dotnet/sdk/blob/release/10.0.1xx/src/Layout/redist/targets/BundledSdks.targets
dotnet/sdk@2601c34

That flowed on September 4th, so it seems like after September 4th the SDK has not merged 10.0.1xx into main which is the root cause here, but that change has flowed into 10.0.2xx since it probably just rollover when it was created from the 10.0.2xx branch.

It seems like the last backflow from 10.0.1xx into main was done on dotnet/sdk#50545.

Does anyone know if there was some sort of 10.0.1xx backflow into main in the .NET SDK repo that didn't happen?

cc @marcpopMSFT for help.

I know sometimes backflows stop, but we've never had to worry, since all we've done is insert, but this particular change that @zivkan made actually needed coordination between .NET SDK and NuGet and unfortunately the VMR being the intermediate repo kind of made things harder in some ways instead of easier. It just introduced more variables where things could be missed like they were here.

fwiw, I'm sure there's some learnings here, especially around the bidirectional flow which honestly can be really tricky.
Changes that don't require multi-repo coordination are likely fine but these pack changes just made the growing pains of adopting the VMR much worse than they probably would've been if we had been doing the VMR for for say like a year.

@MichaelSimons

D:\a_work\1\s\src\sdk\artifacts\tmp\Release\ContainerSigning\5116\filKfCbiryVdxoR5a7tURrFBG4G9RA/Spectre.Console.dll' with Microsoft certificate 'MicrosoftDotNet500'. The library is considered 3rd party library due to its copyright

OK that error got fixed later in sdk by adding to Signing.props. We can either cherry-pick that change into here or wait for yet another sdk PR to get merged into the VMR: #3754