[release/9.0-rc1] Update versions for latest .NET release

[eerhardt]

Backport of #6194 to release/9.0-rc1

/cc @eerhardt

Customer Impact

Our .NET Aspire 9.0-rc1 builds are still using the 9.0-rc1 builds of .NET - specifically EF Core. Customers will be using month old versions if we don't update to 9.0 rc2.

Also, System.Text.Json 8.0.4, which we depend on, was marked vulnerable. So updating to the new version of that important so users don't get vulnerable warnings.

Testing

Automated tests in repo.

Risk

Low. These are new versions of .NET that were released publicly. Getting more test coverage on them is helpful.

Regression?

No

[sebastienros]

Failed twice on elasticsearch, potentially true positive.

[joperezr]

Similar comment to your PR in main, but should we avoid using properties and instead spell out the versions here? This is the reasoning behind my question: Next time that we are bumping dependencies, if the version bump that I see is under this section of Pinned for CG, then I'd likely undo the change, as the long term goal is to remove these as opposed to continue bumping them (once the direct dependency updates the transitive dependency version). If the update is in Versions.props in a property, I'm unlikely to make that link and decide not to update, causing is to always be pinning this transitive dependency.

[eerhardt]

I honestly don't know when we are supposed to be doing logic in Directory.Packages.props and when we are supposed to be doing it in Versions.props. I was just following how we did the split with EF based on TFMs. See #6190 (comment)

[joperezr]

Not a blocker, but in reality we probably should be also editing Version.details.xml as part of these updates to signal which version of a component we actually depend on.

[joperezr]

These two are getting bumped from an 8.0-era package to a 9.0-era package, which will need to be undone in main anyway. Just as FYI.

[joperezr]

In fact, given this is an RC release, this might even be considered as a breaking change when we make the right change in GA

[eerhardt]

which will need to be undone in main anyway

why?

given this is an RC release, this might even be considered as a breaking change when we make the right change in GA

I am not understanding this point.

When you are targeting net8.0, you get the 8.0.x versions of these packages. This line only applies to our packages that target net9.0 (3 of them - the EF libraries). And for those, this change must happen or else we get build errors saying that we are downgrading System.Text.Json and System.Formats.Asn1. EF v9 depends on the 9.0 versions of these packages. Since we are using Central Package Management, we can't say we depend on the 8.0 versions in the net9 build of the EF packages. So we have to update this version in our build for those 3 packages.

[eerhardt]

Failed twice on elasticsearch, potentially true positive.

It passed in main. So I'm confused if it is truly a true positive.

[sebastienros]

Maybe Elastic is just really flaky. We had issues by the past and there is already a specific timeout AFAIR.

[eerhardt]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[joperezr]

Talked offline, we need to take this. Approved.