[main] Update dependencies from dotnet/msbuild

[dotnet-maestro]

This pull request updates the following dependencies

From https://github.com/dotnet/msbuild

• Subscription: 51256791-e30b-4b96-f2b9-08daf1d75f3f
• Build: 20240829.1
• Date Produced: August 29, 2024 5:02:23 PM UTC
• Commit: 01e53f4161996ce73408117d012f24c2c1737e58
• Branch: refs/heads/main

• Updates:
  • Microsoft.SourceBuild.Intermediate.msbuild: from 17.12.0-preview-24428-06 to 17.12.0-preview-24429-01
  • Microsoft.Build: from 17.12.0-preview-24428-06 to 17.12.0-preview-24429-01
  • Microsoft.Build.Localization: from 17.12.0-preview-24428-06 to 17.12.0-preview-24429-01

[Forgind]

@dotnet/kitten @maridematte

I noticed on this line that you changed the name of a constraint on a public type. It looks like it's in the M.B.Experimental namespace, so I don't think the change needs to be reverted, but it seems to be causing trouble with the VMR build:

/vmr/.dotnet/sdk/9.0.100-preview.7.24380.2/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.ApiCompat.ValidatePackage.targets(39,5): error CP0021: (NETCORE_ENGINEERING_TELEMETRY=Build) Cannot remove constraint 'T:Microsoft.Build.Experimental.BuildCheck.AnalysisData' on type parameter 'T' of 'Microsoft.Build.Experimental.BuildCheck.BuildCheckDataContext<T>'.

What do we need to do to resolve that?

[maridematte]

We renamed our BuildCheck structure from Analyzers to Check, and since it is a public class we would like to keep the consistency with the CheckData name. What I'm wondering is why this is just coming up on the SDK insertion and nowhere else.

[dsplaisted]

@dotnet/source-build-internal It looks like MSBuild has some API changes in its experimental namespace, and this is failing an API compatibility check in the VMR build. Is it possible to an exception for those APIs for the compat check?

[MichaelSimons]

@dotnet/source-build-internal It looks like MSBuild has some API changes in its experimental namespace, and this is failing an API compatibility check in the VMR build. Is it possible to an exception for those APIs for the compat check?

The source-build leg appears to be passing. This is a unified build question is better suited for @dotnet/product-construction

[ViktorHofer]

From what I can tell, this did show up in the PR which is why this file got checked in by @JanKrivanek: dotnet/msbuild@600c4a6

We need to figure out why the suppression isn't honored in the VMR build.

[ViktorHofer]

Ah i know why. This is a new compatibility analysis rule that was added to APICompat / Package Validation in the .NET 9 timeframe. The MSBuild repo is still on an 8.0 SDK. But inside the VMR, we build everything with a .NET 9 SDK.

When you update your repo to a .NET 9 SDK you will see the error. I recommend to update the suppression file and add these new errors.

dotnet pack src\Build /p:ApiCompatGenerateSuppressionFile=true with a .NET 9 SDK (ideally the latest released one, P7)

[dsplaisted]

Ah i know why. This is a new compatibility analysis rule that was added to APICompat / Package Validation in the .NET 9 timeframe. The MSBuild repo is still on an 8.0 SDK. But inside the VMR, we build everything with a .NET 9 SDK.

When you update your repo to a .NET 9 SDK you will see the error. I recommend to update the suppression file and add these new errors.

dotnet pack src\Build /p:ApiCompatGenerateSuppressionFile=true with a .NET 9 SDK (ideally the latest released one, P7)

If I'm understanding correctly, this needs to be done in MSBuild. /cc @dotnet/kitten

[ViktorHofer]

Correct

[rainersigwald]

I think dotnet/msbuild#10484 will have taken care of this. @MichalPavlik is anything blocking that?

[akoeplinger]

should we add a VMR patch in the meantime?

[MichalPavlik]

I think dotnet/msbuild#10484 will have taken care of this. @MichalPavlik is anything blocking that?

IIRC dotnet/arcade#14991 needs to be resolved. @f-alizada has more info.

[f-alizada]

Hello. The PR is in progress: dotnet/msbuild#10484
The conflicts and PR reviews are being addressed at the moment.
I would say that the completion % is 95

[dsplaisted]

should we add a VMR patch in the meantime?

It sounds like the VMR patch would just need to be the updated suppression file from the MSBuild PR. On the other hand it sounds like the MSBuild PR itself is close to being merged.

[rainersigwald]

The .NET 9 PR is in but required a couple of changes on the SDK side in #43078. We either need to port them or wait for the merge #43065.

cc 🐈 @MichalPavlik (today)/ @maridematte (next month)

[f-alizada]

The .NET 9 PR is in but required a couple of changes on the SDK side in #43078. We either need to port them or wait for the merge #43065.

I was not aware of that, my bad. Could you please point to the changes you are refering to? I was looking at the:

sdk/src/Cli/Microsoft.DotNet.Cli.Utils/Microsoft.DotNet.Cli.Utils.csproj

Lines 26 to 29 in 048b371

	<!-- We explicitly reference an older version of MSBuild here to support VS
	for Mac and other VS scenarios. During source-build, we only have access to
	the latest version, which targets NetCurrent. -->
	<PropertyGroup>

projects description.
Is it expected that the targeted framework to be .net8 for the project?

[rainersigwald]

No, that's a change that needs to be pulled here--we don't have to support VSMac as of tomorrow :)