There was a conflict in the PR branch when flowing source from https://github.com/nuget/nuget.client/tree/eb38c4a6cccfce5ee9415da1a930fc6534194b2b
Files conflicting with the head branch:

• Directory.Packages.props - 🔍 View in nuget/nuget.client / 🔍 View in VMR

Updates from this subscription will be blocked until the conflict is resolved, or the PR is merged

There was a conflict in the PR branch when flowing source from https://github.com/nuget/nuget.client/tree/eb38c4a6cccfce5ee9415da1a930fc6534194b2b
Files conflicting with the head branch:

• Directory.Packages.props - 🔍 View in nuget/nuget.client / 🔍 View in VMR

Updates from this subscription will be blocked until the conflict is resolved, or the PR is merged

/__w/1/s/eng/finish-source-only.proj(134,5): error : 2 new packages used not in baseline! See report at /__w/1/s/artifacts/log/Release/baseline-comparison.xml for more information. Package IDs are:
/__w/1/s/eng/finish-source-only.proj(134,5): error : Microsoft.AspNetCore.App.Ref.6.0.36
/__w/1/s/eng/finish-source-only.proj(134,5): error : Microsoft.NETCore.App.Ref.6.0.36

The source-build failure is due to dotnet/sdk#49543. @dotnet/source-build & @tmat PTAL asap. Partners teams are waiting for a new SDK with these dotnet/sdk updates.

Any reason why that project TFM needs to be built when building from source?

This is something source build needs to fix. We need to build this code against net6.0 and @mmitche said it is ok to retarget.
dotnet-watch is part of SDK and has to be source-buildable. You can use net10 SDK to run net6.0+ apps with dotnet-watch. Hence we need to target net6.0

Source build only supports the X.0.0 versions of the previous targeting packs. By default the SDK looks for the most recent servicing version. Can TargetingPackVersion be set to 6.0.0 for this scenario?

What does TargetingPackVersion do?

Btw, if this is urgent to fix we can temporarily revert dotnet/sdk#49543.

What does TargetingPackVersion do?

It indicates what targeting pack version to use for the current tfm. The SDK had this embedded to look for the most recent version - right now it is 6.0.36. SB only provides 6.0.0. This is why the 6.0.36 targeting packs are being used and is the source of the reported prebuilts.

I see, so if we set TargetingPackVersion to 6.0.0 for the net60 target, it should work?

Yes I believe so. Not sure if @ViktorHofer or @mmitche have a better more elegant solution.

dotnet/sdk#49637

Can you please make the change directly in this PR for validation.

Sure.

There was a conflict in the PR branch when flowing source from https://github.com/nuget/nuget.client/tree/eb38c4a6cccfce5ee9415da1a930fc6534194b2b
Files conflicting with the head branch:

• Directory.Packages.props - 🔍 View in nuget/nuget.client / 🔍 View in VMR

Updates from this subscription will be blocked until the conflict is resolved, or the PR is merged

That doesn't seem to work.

Not sure if relevant, but note that in this payload of the sdk we finally removed the aspire workload from the sdk, meaning there is no longer a need for the VMR to build the aspire repo at all. @ViktorHofer let me know if there is any help needed for removing aspire from the VMR.

Not sure if relevant, but note that in this payload of the sdk we finally removed the aspire workload from the sdk, meaning there is no longer a need for the VMR to build the aspire repo at all. @ViktorHofer let me know if there is any help needed for removing aspire from the VMR.

Yes we talked about this offline. After this PR is merged we will submit another one that removes aspire from the VMR. No help needed for that. Thanks for removing Aspire from the .NET SDK.

This is something source build needs to fix. We need to build this code against net6.0 and @mmitche said it is ok to retarget.
dotnet-watch is part of SDK and has to be source-buildable. You can use net10 SDK to run net6.0+ apps with dotnet-watch. Hence we need to target net6.0

@tmat @MichaelSimons I'm not positive on that. .NET 6 reached end of life 8 months ago. I don't think that the product should target out-of-support TFMs (especially not in main). We discussed that in Tactics multiple times and agreed on avoiding that. One goal of source-build is to target latest. Even if that's not always possible, we shouldn't go lower than the minimum in-support version which is .NET 8 (net8.0).

We have a similar requirement in another tool in dotnet/sdk: https://github.com/dotnet/sdk/blob/1e96b3ec2f52d396d50001af1b3616efa81ca204/src/BuiltInTools/BrowserRefresh/Microsoft.AspNetCore.Watch.BrowserRefresh.csproj#L19-L23. That uses net8.0 as the minimum TFM.

@tmat @MichaelSimons I'm not positive on that. .NET 6 reached end of life 8 months ago. I don't think that the product should target out-of-support TFMs (especially not in main). We discussed that in Tactics multiple times and agreed on avoiding that. One goal of source-build is to target latest. Even if that's not always possible, we shouldn't go lower than the minimum in-support version which is .NET 8 (net8.0).

That make sense, but a goal is to keep MSFT and SB build differences to a minimum.

/__w/1/s/src/scenario-tests/artifacts/obj/generatedtests/SdkTemplateTestsAot_Web_CSharp/SdkTemplateTestsAot_Web_CSharp.csproj : error NU1101: Unable to find package Microsoft.NETCore.App.Runtime.NativeAOT.centos.10-x64. No packages exist with this id in source(s): /__w/1/s/artifacts/obj/extracted-dotnet-sdk/library-packs, dotnet-eng, dotnet-libraries, dotnet-public, dotnet-tools, dotnet10 [/__w/1/s/src/scenario-tests/src/Microsoft.DotNet.ScenarioTests.SdkTemplateTests/Microsoft.DotNet.ScenarioTests.SdkTemplateTests.csproj] [/__w/1/s/repo-projects/scenario-tests.proj]

@jkoritzinsky - ok another sync issue. The change got dropped for whatever reason...

There was a conflict in the PR branch when flowing source from https://github.com/nuget/nuget.client/tree/dd5a0230dafb3f56845efa3670eb441641df9341
Files conflicting with the head branch:

• Directory.Packages.props - 🔍 View in nuget/nuget.client / 🔍 View in VMR

Updates from this subscription will be blocked until the conflict is resolved, or the PR is merged

@dotnet/dotnet-cli / @baronfel please take a look at the sdk failure

Having a hard time getting a build going, but my suspicion is that we have accidental double-addition of the Info option due to repeated calls to WorkloadCommandParser.GetCommand. We should move the info and version option registration in that method down into the ConstructCommand method like all of the rest of the command initialization to prevent double-addition, since GetCommand is called on several code paths in the SDK.

Uuuh now we have

    [FAIL] Microsoft.DotNet.ScenarioTests.SdkTemplateTests.SdkTemplateTests.VerifyWinformsTemplate(language: VB)
    System.InvalidOperationException : Failed to execute D:\a\_work\1\s\artifacts\obj\extracted-dotnet-sdk\dotnet.exe new globaljson --sdk-version 10.0.100-ci
    Exit code: 1
    
    System.TypeInitializationException: The type initializer for 'Microsoft.DotNet.Cli.Parser' threw an exception.
     ---> System.TypeInitializationException: The type initializer for 'Microsoft.DotNet.Cli.Commands.Workload.WorkloadCommandParser' threw an exception.
     ---> System.NullReferenceException: Object reference not set to an instance of an object.