Aspire: services.<name>.apiVersion is never propagated to synthesized services — #6092's documented workaround is unreachable for Aspire apps (BindingType 'Auto' unmarshal)

[codingoutloud]

• Make sure you've installed the latest version using instructions

Output from azd version
azd version 1.25.5 (also reproduced on 1.25.2)

Describe the bug

This is the Aspire-specific half of #6092. When a container app's stored state contains bindingType: 'Auto' (the ACA-recommended way to declare custom domains in IaC, per microsoft/azure-container-apps#796), azd deploy fails its post-apply read:

ERROR: getting container app: unmarshalling type *armappcontainers.ContainerApp: ... struct field BindingType: json: cannot unmarshal number into Go value of type armappcontainers.BindingType
Suggestion: set 'apiVersion' on your service in azure.yaml to match the API version in your IaC

For non-Aspire services the suggested services.<name>.apiVersion workaround works (#6092). For Aspire AppHost apps it does not: the Aspire importer synthesizes one service per Aspire resource and never copies ApiVersion onto them, so the custom api-version policy never reaches the failing GET.

Source pointers (main as of 2026-06-10):

• cli/azd/pkg/project/dotnet_importer.go — every synthesized ServiceConfig{...} (three construction sites) omits ApiVersion; the file contains zero references to it, even where the parent azure.yaml service config (svcConfig) is in scope.
• cli/azd/pkg/project/service_target_dotnet_containerapp.go — does consume serviceConfig.ApiVersion (two ContainerAppOptions{ApiVersion: ...} sites), so the plumbing exists on both sides of the gap; only the copy is missing.
• Root cause of the unmarshal itself: cli/azd/go.mod pins armappcontainers/v3 v3.1.0, whose default api-version predates Auto (introduced 2024-10-02-preview); the RP then returns bindingType as a number, which the SDK's string-typed enum rejects.

To Reproduce

1. Aspire AppHost app deployed to ACA via azd, with a module bicep declaring ingress.customDomains: [{ name: '<host>', bindingType: 'Auto' }] at Microsoft.App/containerApps@2025-02-02-preview (or any version ≥ 2024-10-02-preview).

2. Add the suggested workaround to azure.yaml:

   services:
     app:
       language: dotnet
       project: ./src/My.AppHost/My.AppHost.csproj
       host: containerapp
       apiVersion: 2025-02-02-preview

3. azd deploy → the service's bits and bicep apply successfully, then the post-apply read fails with the unmarshal error above, and the remaining services in the run are cancelled.

We reproduced this twice (with and without the apiVersion pin) on a three-service Aspire app; live ARM state confirmed the deployments themselves had fully applied each time — only azd's read-back fails, which makes the failure particularly misleading.

Expected behavior

Either of:

1. dotnet_importer.go copies ApiVersion from the azure.yaml service onto each synthesized ServiceConfig (appears to be a one-line fix per construction site), or
2. armappcontainers is bumped to ≥ v4 so Auto round-trips without a custom api-version.

Workaround we're using

Deploy per service and treat only this exact post-apply signature as a soft failure, with outcome gates (a /version-vs-tag assertion + an outside-in TLS check) arbitrating real success:

for svc in svc-a svc-b svc-c; do
  if azd deploy "$svc" --no-prompt 2>&1 | tee "/tmp/azd-$svc.log"; then
    echo "$svc: deployed"
  elif grep -q "cannot unmarshal number into Go value of type armappcontainers.BindingType" "/tmp/azd-$svc.log"; then
    echo "$svc: known Auto-binding read bug; deployment applied — downstream gates verify"
  else
    exit 1
  fi
done

Environment
GitHub Actions ubuntu-latest (Azure/setup-azd@v2, latest) and macOS 15; Aspire 13.1.0 AppHost; materialized infra (azd infra gen + hand-maintained modules); Microsoft.App/containerApps@2025-02-02-preview.

Related: #6092 (non-Aspire report + workaround), #5109 (api-version mismatch design), microsoft/azure-container-apps#796 (Auto binding type), microsoft/azure-container-apps#1652 (platform-side Auto regression history).