Making PathNormalizer a public class from Aspire.Hosting.Utils

[aaronpowell]

Description

When creating an integration that works with the local file system, it'd be ideal to use the PathNormalizer utility class so that custom integrations can behave consistently with Aspire "core" integrations. Currently, this class is internal and the only workaround is to copy it into your own codebase - which is not ideal.

This PR makes the class public, documents it, adds it to the unshipped API file, and removes the shared include from integrations that relied on it.

Contributes to #6807

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

[davidfowl]

err, do we need to make this public? It's like 4 lines of code.

[aaronpowell]

I think it's better that integrations don't have to copy code out of the Aspire repo to have consistent behaviour.

Yes, it's four lines of code, but it's four LOC here, a handful there, and you keep having to come back to grab stuff.

[davidfowl]

I can’t approve this one, doesn’t feel like something we need to expose. Use shared source in the community toolkit.

[eerhardt]

Is there a way we can build a source-only NuGet package in dotnet/aspire that includes a bunch of random internal helper classes.

Then in the community toolkit, we extract that NuGet package into the individual .cs files, and each community toolkit library can pick and choose individual files they want to include? Then the source wouldn't need to be duplicated, and when we updated these internal helper classes, the toolkit could update to the new version as well.

Like a "transport pack" for source files.