🚀 Dogfood this PR with:

⚠️ WARNING: Do not do this without first carefully reviewing the code of this PR to satisfy yourself it is safe.

curl -fsSL https://raw.githubusercontent.com/dotnet/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 14254

Or

• Run remotely in PowerShell:

iex "& { $(irm https://raw.githubusercontent.com/dotnet/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 14254"

Breaking change no?

As the other interface inherits it, I wouldn't think so. I can't see the unit tests here in GitHub Actions right now and won't be near a PC before Monday. If they still work, it shouldn't be breaking.

Breaking change no?

Ok, now I understand what you meant. It's not clashing with IResourceWithServiceDiscovery but with IResourceWithConnectionString. I will rename it to WithEndpoints to avoid issues but still give users some way to use it for simple cases.

I sadly don't get it to compile locally on macOS with Docker Desktop following https://github.com/dotnet/aspire/blob/main/docs/machine-requirements.md

Neither through DevContainers nor natively as protoc always gives an error 139. So have to rely on the CI to see if it's working now.

I think offering WithEndpoints should be a sufficient workaround until the next breaking change, but I would love to have WithReference be adjusted to only use IResourceWithEndpoints and have the check to offer the ReferenceEnvironmentInjectionFlags.ServiceDiscovery done by pattern matching against IResourceWithServiceDiscovery (as already done). I therefore prepared it in a way, that allows for adjusting the existing WithReference method on 14.x :)

https://dev.azure.com/dnceng-public/public/_build/results?buildId=1276039&view=results seems to hint that no tests have been executed by the CI, is that normal?

@davidfowl Should be non-breaking now.