Migrate Aspire.Hosting.Dapr to the Community Toolkit

[aaronpowell]

As discussed in CommunityToolkit/Aspire#349 the Community Toolkit will take ownership of the Aspire.Hosting.Dapr integration. The plan for how deprecation of the Aspire-shipped package will be tackled can be seen in my comment here: CommunityToolkit/Aspire#349 (comment)

I've created CommunityToolkit/Aspire#375 to track the work in the Community Toolkit repo, but there's (obviously) some work needing to be done here, so I'll see if I can capture it all:

• Change the Aspire.Hosting.Dapr package to forward calls across to CommunityToolkit.Aspire.Hosting.Dapr (there's a dependency on that package shipping). The types and members should be marked as Obsolete, pointing people to use the Community Toolkit package directly, but not fail the build.
• Mark the types and members of the Aspire.Hosting.Dapr as Obsolete (but as warning not error).
• Remove the Aspire.Hosting.Dapr.Tests project.
• Remove the Dapr playground project.
• Deprecate the package on NuGet.

I think that covers everything that'll be needed.

[aaronpowell]

A critical point for this will be the timeline that we want to ship it in, and aligning that across the Aspire release schedule and the Community Toolkit.

Does it seem possible that this could be done for the 9.1 release of Aspire, or should we target 9.2?

[davidfowl]

Change the Aspire.Hosting.Dapr package to forward calls across to CommunityToolkit.Aspire.Hosting.Dapr (there's a dependency on that package shipping). The types and members should be marked as Obsolete, pointing people to use the Community Toolkit package directly, but not fail the build.

Why not just lift the code and have no dependency?

[davidfowl]

Does it seem possible that this could be done for the 9.1 release of Aspire, or should we target 9.2?

We can do it in 9.1.

[aaronpowell]

Change the Aspire.Hosting.Dapr package to forward calls across to CommunityToolkit.Aspire.Hosting.Dapr (there's a dependency on that package shipping). The types and members should be marked as Obsolete, pointing people to use the Community Toolkit package directly, but not fail the build.

Why not just lift the code and have no dependency?

My thinking was that by having the Aspire.Hosting.Dapr package just being a wrapper around the CT version for a release people are able to refactor their code across without having to add a new dependency until at least the following release.

[davidfowl]

Nah, just lift the code. It’s not that much. We don’t touch this package at all.