Bumping dependency versions and updating Configuration Schema for components

[joperezr]

In preparation for our 8.0.2 release, this change is updating all¹ of our package dependencies to latest versions out in Nuget.org

cc: @eerhardt can you please review and make sure dependencies look correct?

FYI: @radical @danmoseley @DamianEdwards @davidfowl @maddymontaquila This is in preparation of our 8.0.2 release later this week.

Microsoft Reviewers: Open in CodeFlow

Footnotes

1. With the exception of Azure.Open.AI package as that one is still in beta and new version has breaking changes that require more risk than what we want in this servicing. ↩

[danmoseley]

Worth describing the process you used here? Eg link to the script.

[joperezr]

Worth describing the process you used here? Eg link to the script.

Sure, I did the following:

# from the root of the repo
./build.cmd -restore # to ensure that we start off from a good point and dotnet-outdated can traverse dependencies.
dotnet new nugetconfig --force # to override the the NuGet.config with one that only has NuGet.org as the source
dotnet outdated --no-restore -u .\Aspire.sln # to perform the update of packages
git checkout -- NuGet.config # to undo the change to nuget.config file

## At this point the update is done, now we need to check if anything else needs updating (code or configuration schemas)
./build.cmd -restore -build # to validate things are working and if there are failures, then fix case-by-case.
                                           # When configurationschema files need an update, the build will fail and the command needed to
                                           # update them will be printed in the console.

If you don't have dotnet-outdated tool install yet, you can get it by following the steps on their repo: https://github.com/dotnet-outdated/dotnet-outdated

[eerhardt]

LGTM. Thanks!

[danmoseley]

Sure, I did the following:

Ah, that's exactly what I was doing. sounds good

[danmoseley]

do we want to pull any testing improvements from main into release/8.0 too? if they are separable and worthwhile. we have the playwright stuff, testcontainers stuff.

[joperezr]

I think that most of that actually depends on a lot of infrastructure that is also only on main, and given the fact that we don't really plan on shipping from the release/8.0 branch, I'm not sure if it's worth the effort. For this particular servicing, I've already reached out to @balachir to have his team do a round of validation with 8.0.2 build to ensure things look great.

I do agree that moving forward, we'll want to more heavily rely on automation for coverage and not just our CTI team.