Switch to non-incremental servicing and update ApiCompatNetCoreAppBaselineVersion to 9.0.0

[carlossanlop]

Fixes #106598

[carlossanlop]

I see ApiCompat failures @ViktorHofer

[ViktorHofer]

The failures will go away when we forward port #109316 into main (or into this PR).

[carlossanlop]

The failures will go away when we forward port #109316 into main (or into this PR).

In that case, I'll reset your sign-off and will bring those changes into this PR. There was a conflict when attempting the automatic backport.

[carlossanlop]

@ericstj @ViktorHofer after bringing the 9.0 changes to switch to non-incremental servicing, I hit some api-compat failures in my local machine. I am not confident on what to do about them, they seem very similar to the ones that already exist in ApiCompatBaseline.NetCoreAppLatestStable.xml, but with different left and right values. Also, running the allconfigurations command with /p:ApiCompatGenerateSuppresionFile=true is creating new files with completely unrelated suppressions for coreclr and mono, not the ones reported in the errors.

I pushed the changes so the ApiCompat failure shows up in the CI.

[ViktorHofer]

You are missing updating ApiCompat.proj's suppression file(s). That's a manual task:

.\dotnet.cmd build src/libraries/apicompat/ApiCompat.proj /p:ApiCompatGenerateSuppressionFile=true

They should become either empty or really small.

[carlossanlop]

@ViktorHofer I pushed a commit with the result of running that command.

[ViktorHofer]

Hmm those files aren't what I was expecting to get produced by that command. https://github.com/dotnet/runtime/blob/main/src/libraries/apicompat/ApiCompatBaseline.NetCoreAppLatestStable.xml should have got updated.

Isn't that the case?

[carlossanlop]

Hmm those files aren't what I was expecting to get produced by that command. https://github.com/dotnet/runtime/blob/main/src/libraries/apicompat/ApiCompatBaseline.NetCoreAppLatestStable.xml should have get updated.

Isn't that the case?

That's exactly what I meant in my previous comment. There were no updates to ApiCompatBaseline.NetCoreAppLatestStable.xml, which is what I was expecting:

they seem very similar to the ones that already exist in ApiCompatBaseline.NetCoreAppLatestStable.xml, but with different left and right values.

running the allconfigurations command with /p:ApiCompatGenerateSuppresionFile=true is creating new files with completely unrelated suppressions for coreclr and mono

The command you provided updated fewer files actually. The allconfigurations command updated mono files too.

[ViktorHofer]

Very weird. Something is wrong. Let me debug offline.

[ViktorHofer]

I only get the netstandard2.0 and the netstandard2.1 suppression files printed onto the console but not the ApiCompatBaseline.NetCoreAppLatestStable.xml one. That's weird indeed.

C:\git\runtime4> dotnet.cmd build src\libraries\apicompat\ApiCompat.proj --no-restore --no-dependencies /p:ApiCompatGenerateSuppressionFile=true /bl

  ApiCompat -> Comparing net10.0 reference assemblies against .NETStandard 2.x and .NETCoreApp 9.0.0...
  Successfully wrote compatibility suppressions to 'C:\git\runtime4\src\libraries\apicompat\ApiCompatBaseline.netstanda
  rd2.1.xml'.
  Successfully wrote compatibility suppressions to 'C:\git\runtime4\src\libraries\apicompat\ApiCompatBaseline.netstanda
  rd2.0.xml'.

[ViktorHofer]

The net9.0 <-> net10.0 step runs successfully but doesn't re-generate the suppression file:

But the other two subsequent steps (netstandard2.0 and netstandard2.1) do re-generate the suppression file correctly:

No idea why. I would need to debug with APICompat.

[ViktorHofer]

OK that's an APICompat bug. Submitted dotnet/sdk#44965

But it's not blocking this PR in any way. I just pushed a commit that updates the suppression file.