Update previous netcoreapp version to run API Compat against 6.0 ref pack

[safern]

We are still running API Compat for the ref pack against the 5.0 ref pack rather than the 6.0 one on main. Now that the 6.0 is released we can do that.

[ghost]

Tagging subscribers to this area: @Anipik, @safern, @ViktorHofer
See info in area-owners.md if you want to be subscribed.

Issue Details

---

We are still running API Compat for the ref pack against the 5.0 ref pack rather than the 6.0 one on main. Now that the 6.0 is released we can do that.

Author:	safern
Assignees:	-
Labels:	area-Infrastructure-libraries
Milestone:	-

[safern]

It seems like we are hitting some package validation now that the baseline versions changed. I will look into them and see why.

[safern]

I need to check these runtime net6.0 assets vs lib assets.

[safern]

Ok, so I was able to figure these out. The package doesn't have a ref folder, and this is comparing runtimes/* as the contract, VS the ridless lib (the compile asset), and it seems like the ref is not exposing these APIs. It seems like that is by design. As we even have this: https://github.com/dotnet/runtime/blob/main/src/libraries/System.Data.Odbc/src/MatchingRefApiCompatBaseline.txt

[ericstj]

A couple look like real failures due to TFMs being removed.

Do we have a way to suppress the removed TFMs and avoid any member-specific noise about them, while still getting coverage for newer TFMs?

[safern]

Do we have a way to suppress the removed TFMs and avoid any member-specific noise about them, while still getting coverage for newer TFMs?

Not yet, this is what I was mentioning here: #61437 (comment)

We need a way to specify tmfs to ignore via an item or something like that.

[safern]

@ericstj I've replied to your feedback, could you take another look to get this unblocked?

[joperezr]

Changes look good in general. It would be good to investigate those new ODBC ones as I wouldn't expect those either. Also, a NIT, but it might be worth adding a comment on all of the suppressions that are expected due to a drop of a TFM from the current package, that is what we did before 6.0 shipped so we should probably do that as well in this PR.

[ericstj]

So long as we're certain those suppressions aren't real issues that will be hit for supported frameworks I'm OK with this.

[safern]

I've validated the diffs and they all make sense.