Aspire Client Integrations util project

[aaronpowell]

Description

To address part of #6807 I've created a new project for client integrations to reference, Aspire.Client, that contains the shared code for health checks, connection string validation and generating config schemas (which would start to unblock #3309). This would result in a new NuGet package being shipped that all client integrations would reference (at least, those in the Aspire repo would reference).

The PR contains the new project, and the refactoring required to remove the shared files and update the references.

I think there's an additional step that I need to do for the new project to build, since it's reporting that it's not part of any NuGet feeds. There may also need to be some updates to either the Package.targets or src/Components/Directory.Build.targets to skip the step that tries to generate the config schema JSON file (since it's not relevant here).

Checklist

• Is this feature complete?
  • Yes. Ready to ship.
  • No. Follow-up changes expected.
• Are you including unit tests for the changes and scenario tests if relevant?
  • Yes
  • No
• Did you add public API?
  • Yes
    • If yes, did you have an API Review for it?
      • Yes
      • No
    • Did you add <remarks /> and <code /> elements on your triple slash comments?
      • Yes
      • No
  • No
• Does the change make any security assumptions or guarantees?
  • Yes
    • If yes, have you done a threat model and had a security review?
      • Yes
      • No
  • No
• Does the change require an update in our Aspire docs?
  • Yes
    • Is this introducing a breaking change?
      • Yes
        • Link to aspire-docs issue (please use this breaking-change template):
      • No
        • Link to aspire-docs issue (please use this doc-idea template):
  • No

Microsoft Reviewers: Open in CodeFlow

[eerhardt]

Thank you for making this proposal, @aaronpowell.

We intentionally haven't made a "common"/"util" project for client integrations.

1. The APIs being exposed here aren't really meant to be public. They are more "internal helper" APIs that we want to be able to modify in the future as we need to.
2. There can be some confusion to app authors whether they should reference this library directly or not. Either way, they will see these public APIs whenever referencing an Aspire client integration library, since the Aspire.Client package is transitively referenced.

Looking over the proposed APIs, the 2 attributes: ConfigurationSchemaAttribute and LoggingCategoriesAttribute are better added along with the ConfigSchemaGenerator when we create a standalone package for it (Spin off configuration schema generator as a standalone package (dotnet/aspire#3309)).

If you remove those 2 files, what's left is just 2 APIs - ValidateConnectionString (roughly 5 lines of code) and TryAddHealthCheck (roughly 5 lines of code over 2 methods). I'm not sure this justifies creating and maintaining a new library. Would it be OK to just copy those files into the CommunityToolkit?

[aaronpowell]

We already copy across the TryAddHealthCheck stuff and we should consider the ValidateConnectionString (I only noticed it the other day in the repo), so this was more about having the discussion on whether we should have a "base" package for client integrations (like Aspire.Hosting ends up as the base for hosting integrations and contains some utility types on top of its core functionality).

If we move those attributes across to the ConfigSchemaGenerator project, won't we be needing to create a reference to it in the client projects? Or is it less of a concern because it's got a more obvious use case?

As an aside, why is it failing to build the newly added project? I want to add a new project to tackle the testing items noted in #6807 but it hit the same problem and I don't know how to fix it.

[eerhardt]

If we move those attributes across to the ConfigSchemaGenerator project, won't we be needing to create a reference to it in the client projects? Or is it less of a concern because it's got a more obvious use case?

The reference will won't be visiable to consumers of the client integration packages. We will use a "PrivateAssets" PackageReference, since the ConfigSchemaGenerator project will only be needed while building the client integration library.

As an aside, why is it failing to build the newly added project? I want to add a new project to tackle the testing items noted in #6807 but it hit the same problem and I don't know how to fix it.

You need to set <EnablePackageValidation>false</EnablePackageValidation> on new libraries. We use package validation by default to ensure we don't make breaking changes from one version to the next. In order to do this, we download the previous version of the library. But since this is a new library, we can't do that until we have shipped it at least once.