Cannot access the "public" URL of a resource when using the `dev.localhost` applicationUrls

[ctolkien]

We have a scenario where we have a frontend browser based application which calls a Backend API. The backend API needs to be configured with CORS rules for which frontend clients are able to call this API, which is driven from environment variables. So we need to know what the public URLs are that requests will be coming in from.

When using the dev.localhost "vanity" hostname system in Aspire, the actual hostname you will be accessing the frontend via is resourceName-appname.dev.localhost:XXXX, however it does not appear that we have a way to get this endpoint from a resource to pass this through.

resource.GetEndpoint("https", KnownNetworkIdentifiers.LocalhostNetwork); <- this will return localhost:XXXX. There doesn't seem to be a means of getting the *.dev.localhost:XXXX hostname that is presented in the Aspire dashboard.

[IEvangelist]

Some source-level context on why this happens today, to help scope a fix.

There are two distinct code paths that produce a *.dev.localhost URL, and they behave very differently:

1. Explicit target host (recoverable). When an endpoint's EndpointAnnotation.TargetHost is itself a .localhost TLD, the vanity value is preserved and reconstructable. EndpointHostHelpers.GetUrlWithTargetHostAsync rebuilds {scheme}://{targetHost}:{port} from it.

2. Auto-vanity (the case in this issue). When the dashboard is running on *.dev.localhost, ApplicationOrchestrator.ProcessResourceUrlCallbacks (fired on ResourceEndpointsAllocatedEvent) synthesizes a per-resource URL of the form:

{scheme}://{resource-name}-{subdomain-suffix}.dev.localhost:{port}

The important detail: in path 2 the endpoint's TargetHost is never updated — it stays "localhost". The vanity hostname only exists as a display-oriented ResourceUrlAnnotation on the resource, with no IValueProvider/expression tied to it.

That's why the workaround in the issue doesn't work:

• resource.GetEndpoint("https", KnownNetworkIdentifiers.LocalhostNetwork) resolves through EndpointReference → allocated address → localhost:XXXX.
• Even the internal GetUrlWithTargetHostAsync returns localhost:XXXX here, because IsLocalhostTld("localhost") is false.
• The synthesized *.dev.localhost:XXXX string lives in a ResourceUrlAnnotation that has no public, referenceable accessor, so it can't flow into another resource's environment variable (the CORS scenario) via the normal endpoint-reference expression machinery.

Relevant source:

• src/Aspire.Hosting/Orchestrator/ApplicationOrchestrator.cs — ProcessResourceUrlCallbacks (synthesizes the *.dev.localhost URL as a ResourceUrlAnnotation)
• src/Aspire.Hosting/ApplicationModel/EndpointHostHelpers.cs — GetUrlWithTargetHostAsync / IsLocalhostTld (only handles path 1)
• src/Aspire.Hosting/ApplicationModel/EndpointReference.cs — endpoint resolution (returns the allocated localhost address)
• src/Aspire.Hosting/ApplicationModel/ResourceUrlAnnotation.cs — where the vanity URL is stored

Suggested direction: to support the CORS use case the auto-vanity URL needs to be first-class and referenceable — e.g. an expression/value-provider that resolves to the vanity origin (reusing the same dashboard-derived suffix + allocated port), or a public API to enumerate a resource's ResourceUrlAnnotations so the value can flow into WithEnvironment. There's also a lifecycle ordering wrinkle (these URLs are generated at endpoint-allocation time), which is itself an argument for a proper API rather than a hand-rolled workaround.

Loosely related: #13130 (HostUrl remapping of *.dev.localhost).