Unable to reference another project's target port

[davidfowl]

Follow up from https://github.com/Azure/azure-dev/pull/3735

When referencing another project's target port property, we end up replacing it with the expression to resolve the current target port if that target port is being inferred from continer builds. The below shows 2 projects api0 and api. When API tries to get a handle on api0's target port, it instead resolves its own target port.

var builder = DistributedApplication.CreateBuilder(args);

var api0 = builder.AddProject<Projects.WebApplication1>("api0")
                  .WithHttpEndpoint(name:"http");

builder.AddProject<Projects.WebApplication2>("api")
      .WithEnvironment(context =>
      {
          context.EnvironmentVariables["API0_TP"] = api0.GetEndpoint("http").Property(EndpointProperty.TargetPort);
      });

builder.Build().Run();

api/manifests/containerApp.tmpl.yaml

  template:
    containers:
    - image: {{ .Image }}
      name: api
      env:
      - name: AZURE_CLIENT_ID
        value: {{ .Env.MANAGED_IDENTITY_CLIENT_ID }}
      - name: API0_TP
        value: '{{ targetPortOrDefault 0 }}'
      - name: ASPNETCORE_FORWARDEDHEADERS_ENABLED
        value: "true"
      - name: OTEL_DOTNET_EXPERIMENTAL_OTLP_EMIT_EVENT_LOG_ATTRIBUTES
        value: "true"
      - name: OTEL_DOTNET_EXPERIMENTAL_OTLP_EMIT_EXCEPTION_LOG_ATTRIBUTES
        value: "true"
      - name: OTEL_DOTNET_EXPERIMENTAL_OTLP_RETRY
        value: in_memory

We should fix this or make it throw. This only happens for unspecified target ports.

[davidfowl]

Turns out this doesn't work at runtime either.

[rajeshkamal5050]

Turns out this doesn't work at runtime either.

Mean with Azure provisioning packages/features for local/dev resources?

[davidfowl]

Even for containers when running locally. I'd make this low priority as a result since it doesn't work regardless.