launchSettings.json profiles' applicationUrl is not used

[ThibautHH]

In Aspire, an ASP.NET Core project's applicationUrl property of the launchSettings.json profile is not respected.

Project.ApiService\Properties\launchSetting.json

{
  "$schema": "http://json.schemastore.org/launchsettings.json",
  "profiles": {
    "http": {
      "commandName": "Project",
      "dotnetRunMessages": true,
      "launchBrowser": false,
      "applicationUrl": "http://localhost:5001",
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Development"
      }
    },
    "https": {
      "commandName": "Project",
      "dotnetRunMessages": true,
      "launchBrowser": false,
      "applicationUrl": "https://localhost:7001;http://localhost:5001",
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Development"
      }
    }
  }
}

The preceding launch settings for the ApiService ASP.NET Core project resource results in this situation:

Basically, the launch settings are correctly read and loaded, but the ASPNETCORE_URLS environment variable is set by Aspire, disregarding them.

This is due to code in src/Aspire.Hosting/Dcp/ApplicationExecutor.cs, inside the ApplyLaunchProfile method.

if (executableResource.DcpResource is ExecutableReplicaSet)
{
    var urls = executableResource.ServicesProduced.Select(sar =>
    {
        var url = sar.EndpointAnnotation.UriScheme + "://localhost:{{- portForServing \"" + sar.Service.Metadata.Name + "\" -}}";
        return url;
    });

    config.Add("ASPNETCORE_URLS", string.Join(";", urls));
}
else
{
    config.Add("ASPNETCORE_URLS", launchProfile.ApplicationUrl);
}

This check is flawed, because, while you indeed need to use generated portForServing when you have multiple replicas to avoid conflicts, a single replica can and should use the launch profile's applicationUrl property.

A simple fix should be to actually check this (I'll make a PR for it).

[davidfowl]

This is by design. See https://github.com/dotnet/docs-aspire/issues/232 for more information

[ThibautHH]

Ah well, that indeed makes more sense, thank you for the info.